Your workloads stay on your infrastructure.

Current Core · Development

Local execution through a constrained proxy.

The daemon coordinates image watches, local update policy, health checks, and operation history. In the reference architecture, a constrained proxy holds the Docker socket and mediates the daemon’s runtime access.

The controller manages existing watched containers. Its Compose reference deployment installs Prontera and the proxy. It does not make the current controller a general-purpose application-stack provisioner.

These capabilities exist in the development code. Production qualification, private-registry pull authentication, and interrupted-update recovery are still being completed.

Restoring a container image does not undo database migrations or application-data changes.

Cloud preview workflow · Planned

A reviewed path from change to environment.

Trusted CI builds application images outside the target host. The planned handoff checks the eligible repository revision, approved workflow, and immutable artifact identities before accepting a preview request.

An approved template describes the frontend, API, supporting services, resource limits, and lifetime. A designated customer preview node runs that stack using isolated preview data. Production database contents are outside the initial preview-data model.

A node initiates its outbound connection to Cloud. The design does not require a publicly exposed Docker API. Cloudflare Tunnel is selected for the planned managed private-preview ingress path; the integration is not complete.

Cloud-backed identity grants a reviewer access to the specific environment. That preview session stays separate from infrastructure credentials and from the application’s own login.

Operations and decisions

A preview does not authorize production.

The intended dashboard, API, CLI, and MCP interfaces share an operation and permission model. Each request is limited by project, environment, and action. No coding agent is required to use the workflow.

Separately approved releases come later in the implementation sequence, after their execution and recovery boundaries are qualified. A release plan refers to exact artifacts and target state; changing those inputs requires the plan to be re-evaluated.

Preview expiry and pull-request closure trigger the planned cleanup path. Prontera must track the containers, networks, volumes, and routes it created, and show incomplete cleanup when a resource cannot be removed or a node is disconnected. Cleanup is required whether or not a release follows.

Trust and data

Container isolation has limits.

The first native-preview model excludes untrusted sources. It requires eligible customer-controlled revisions, trusted CI evidence, and approved templates. A successful sandbox build does not make arbitrary output trusted, and a container boundary alone does not make arbitrary code safe.

Stronger isolation through user-selected external execution services is later research and integration scope. Prontera is not building a competing microVM deployment platform.

The planned Cloud data model stores control-plane activity by default. Bounded diagnostics can be requested when needed. Continuous collection of application logs or source code is outside that default direction.

This website

The waitlist is a separate system.

These public pages are built with Astro as static content. The website implementation uses Cloudflare Workers Static Assets and a Worker that saves waitlist requests directly in D1. Submitting a request does not send an email. Production activation requires the actual domain, database binding, monitored contact inbox, and retention configuration.

This small website backend does not implement Prontera Cloud, its node connections, or customer deployment operations. Its processors and retention are described in the waitlist privacy notice.