Core in development · Cloud on the roadmap
Prontera manages Docker update workflows on your servers. We’re building toward private, full-stack previews that your team—or a coding agent—can request through an optional Cloud control plane.
The public Apache-2.0 Core release is planned.
Prontera Cloud is not yet available.
One private application. The whole stack.
A preview of the workflow—not a live environment.
01 /Two parts. Clear responsibilities.
Prontera Core and Prontera Cloud have different responsibilities. The Core performs local operations. Cloud is planned to coordinate projects, reviewers, and connected hosts without becoming the place your application runs.
Self-hosted · Development build
Watch container images, apply update policies, check health, and inspect the outcome from a local interface or CLI. The intended open-source release remains useful without a Cloud account.
Read the Core overviewOptional hosted service · Planned
Connect existing servers, request private previews, give reviewers access, and let coding agents request permitted operations through the same control plane used by your team.
Explore the Cloud roadmap02 /The local Core
The Core brings image checks, update policy, replacement, health validation, and recovery into one workflow.
Check OCI image identities on a schedule or when an operator requests it.
Use notification-only operation, approval modes, maintenance windows, and hooks instead of treating every new image as permission to deploy.
Evaluate the configured health gate after replacing an existing watched container.
Attempt to restore the previous captured image and runtime configuration when a health-gated update fails.
Validate, compare, apply, and export prontera.yaml configuration.
Use the CLI or embedded web interface to inspect watches, update history, and operational state through the daemon API.
These capabilities exist in the development code. Production qualification, private-registry pull authentication, and interrupted-update recovery are still being completed.
A recovery boundary: restoring a container image does not undo database migrations or application-data changes.
Planned for Prontera Cloud
Keep your coding tools and CI. Prontera’s planned preview workflow starts with their output and gives a reviewer a private application to open.
A developer or coding agent opens a change in an eligible customer repository. The agent can keep running in its existing environment.
Your CI builds the application images. Prontera verifies the repository revision, workflow, and immutable artifact identities before accepting the preview request.
An approved template defines the application, supporting services, resource limits, and lifetime. A designated customer preview node runs the stack with isolated preview data—not production database contents.
The reviewer signs in through Prontera Cloud and opens the environment on a dedicated Prontera preview domain. Access is granted to the specific environment rather than inherited from a public link.
The boundary at each step
Change
The initial native-preview model requires eligible customer-controlled revisions. Untrusted execution needs a later, separately qualified isolation path.
CI artifacts
Your existing CI builds the application images. A build alone does not establish trust: the repository, workflow, revision, and immutable artifact identities need verification.
Private preview
Approved templates define the stack and its limits. Preview data stays separate from production data, and the application runs on designated customer infrastructure.
Review
Cloud-backed reviewer identity, preview access, and the application’s own login have separate responsibilities. Sharing a review does not grant infrastructure credentials.
After review
Ordinary lifecycle
The preview expires or is removed when its pull request closes. Prontera tracks the resources it created and reports incomplete cleanup instead of silently leaving them behind.
Later Optional approved release
Review the change, request another revision, or follow a separately approved release workflow when that capability is available. A working preview does not automatically authorize a production deployment.
The preview lifecycle does not depend on promoting a release. Cleanup is required either way.
Cloud capabilities below are planned.
Bring up the frontend, API, and supporting services together using reviewed templates and synthetic development data. A successful preview should be usable for review, not simply a container marked as running.
Use Cloud-backed identity to authorize a reviewer for the right project and environment. Keep the preview session separate from infrastructure credentials and from the application’s own login.
Apply preview lifetimes and resource limits. Track cleanup across containers, networks, volumes, and routes, including when a node disconnects.
Project
a1b2c3dApplication services
Customer infrastructure · Isolated preview data
MCP interface · Planned
An agent should be able to ask for a preview, inspect a failed operation, or request a release plan without receiving unrestricted control over the host.
Prontera’s dashboard, API, CLI, and MCP interface are intended to use the same permission and operation model. Permissions will specify the projects, environments, and actions an agent may use. Production approval remains a separate decision.
No coding agent is required. The same workflow is intended for people and CI.
Scoped operations
Local execution boundary
Example request
“Request approval for this release plan.”
Illustrative request, not an implemented MCP tool.
05 /Integrations, with their status attached
Prontera starts with Docker and existing image workflows. Additional integrations follow the same rule: support must be explicit, testable, and accurately described.
Present in the development Core. Supported production combinations will be published after qualification.
Later, separately qualified runtime tracks. Docker compatibility does not establish Podman support.
OCI image discovery and ECR-specific integration code are present in development. Private-registry engine authentication still requires remediation and qualification.
Planned first Cloud workflow for eligible repositories and verified CI artifacts. Other CI systems are not automatically promised.
Selected for the planned managed preview path. This is not an existing partnership or a finished integration.
Slack, Discord, generic webhooks, and SMTP exist in the development Core. Delivery hardening is ongoing.
Development06 /The execution boundary
The local Core is the execution boundary. In the reference architecture, a constrained proxy—not the Prontera daemon—holds the Docker socket.
The Cloud design adds an outbound node connection, scoped operations, and reviewer access without requiring a publicly exposed Docker API.
Identity, scoped operations, and reviewer access.
Optional hosted coordinationPlanned · No publicly exposed Docker API
Customer-owned infrastructure
Native updates manage existing watched containers. Production qualification remains in progress.
Approved templates · Resource limits · Preview lifetime
Isolated preview data. No production database contents.
Eligible customer-controlled revisions and verified immutable artifacts are required for the planned native-preview path.
07 /The path ahead
Complete registry authentication, interrupted-operation recovery, release checks, and repeatable runtime qualification.
Add identity, node enrollment, read-only visibility, and private application previews.
Add scoped MCP actions and separately approved release workflows after their execution and recovery boundaries are qualified.
Qualify Podman and selected external execution providers against real customer needs.
08 /A simple business model
The planned public Core release will use Apache-2.0 and operate without a Cloud account. Cloud plans will cover hosted coordination, collaboration, and operational convenience—not the customer’s server bill.
We are preparing a small design-partner pilot before an invitation-only beta. Prices and usage allowances are still being evaluated.
Join the preview waitlistPublic Core release planned · Cloud is not on sale
09 /An independent project
Prontera starts with a practical problem: keeping existing Docker applications updated while making changes easier to inspect and recover from.
The planned Apache-2.0 release is intended to remain useful on its own. Prontera Cloud adds hosted coordination for people who need a shared workflow across projects, reviewers, and hosts.
Prontera is being built by Ramon Oliveira. The project is in early development, and the code repository is currently private while release preparation continues.
Before you join
The current stage, the intended workflow, and the boundaries that matter.
More about the projectNot yet. The Core has working development functionality, but production qualification and important recovery and authentication work remain. Cloud access is not available yet.
The intended public Core release is independently useful and self-hosted. Cloud is optional hosted coordination, not a required account for local operation.
The planned native workflow runs applications on your designated servers. Prontera Cloud coordinates operations and access; it is not a replacement hosting provider.
No. Agent access is an additional interface to the planned workflow. Developers and CI can use the same operations without an AI model.
That is not the product model. Planned agent access is limited to named operations and resource scopes, with separate approval where required.
Not in the initial native-preview model. The plan requires eligible customer-controlled revisions, trusted CI evidence, and approved templates. Untrusted execution needs a later, separately qualified isolation path.
No. Replacing an application image does not undo migrations or data changes. Application-data compatibility and recovery need their own plan.
Not yet as a qualified runtime. Docker is the first target. Rootful Podman, then rootless Podman, are later qualification tracks.
The design includes removal when its pull request closes or its lifetime expires. Cleanup must report incomplete work instead of implying that every resource was deleted.
No. External sandbox or microVM services may be integrated later. Prontera is not building a competing microVM deployment platform.
10 /Join us at the beginning
We are looking for developers and small teams already running containerized applications on their own servers. Join the waitlist to hear when the initial pilot and closed beta are ready.
A small design-partner pilot.
Then an invitation-only beta.