Capability inventory
What exists. What comes next.
Every capability has a stage. The development Core works with existing Docker containers; private full-stack previews and Cloud coordination are planned work.
Documentation reviewed . This inventory is not a fresh production qualification.
How to read the status
- Development
- Present in the reviewed development code. Qualification work remains.
- Planned
- Part of the intended product direction. Not an available capability.
- Later
- A later implementation or qualification track with scope still to resolve.
Prontera Core
The local update workflow.
Image checks, update policy, replacement, health validation, and recovery for existing watched containers.
- Watch image changesDevelopment
Check OCI image identities on a schedule or when an operator requests it.
Evidence and review
Image discovery exists in development. This does not establish authenticated deployment support for every private registry.
Development Core documentation ·
- Decide when changes runDevelopment
Use notification-only operation, approval modes, maintenance windows, and hooks instead of treating every new image as permission to deploy.
Evidence and review
Local update policy is development functionality for existing watched containers. It is not a Cloud production-approval workflow.
Development Core documentation ·
- Check the resultDevelopment
Evaluate the configured health gate after replacing an existing watched container.
Evidence and review
The health gate checks the configured update result. Production qualification is still required.
Development Core documentation ·
- Recover when an update failsDevelopment
Attempt to restore the previous captured image and runtime configuration when a health-gated update fails.
Evidence and review
Interrupted-update recovery remains incomplete. Restoring an image does not undo database migrations or application-data changes.
Development Core documentation ·
- Review configuration changesDevelopment
Validate, compare, apply, and export prontera.yaml configuration.
Evidence and review
These operations concern the local Core configuration, not full-stack preview provisioning.
Development Core documentation ·
- Inspect operations locallyDevelopment
Use the CLI or embedded web interface to inspect watches, update history, and operational state through the daemon API.
Evidence and review
The local API, CLI, and embedded web interface exist. The shared Cloud dashboard/API/CLI/MCP model is separate planned work.
Development Core documentation ·
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.
The reference installer uses Compose to install Prontera and its proxy. Current local configuration and update planning do not provision arbitrary application stacks or full-stack preview environments.
Prontera Cloud
Coordination is on the roadmap.
All Cloud capabilities below are planned. Preview creation, reviewer access, and release approval have separate responsibilities.
- Preview the complete applicationPlanned
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.
Evidence and review
Full-stack preview provisioning is not implemented in the reviewed Core checkpoint. Initial native previews require designated customer infrastructure and eligible trusted revisions.
Product decisions and specification ·
- Give reviewers specific accessPlanned
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.
Evidence and review
Cloud identity and environment-scoped reviewer access are planned. There is no public Cloud account or running preview service to join yet.
Product decisions and specification ·
- Track connected hostsPlanned
See which hosts are connected, which environments they own, and when their last observations arrived. Distinguish an offline host from a healthy application rather than treating missing data as success.
Evidence and review
Node enrollment, outbound connectivity, and Cloud host visibility are planned coordination capabilities.
Product decisions and specification ·
- Keep release decisions explicitPlanned
Plan changes against exact application artifacts and target state. Require the appropriate approval before a production operation, and re-evaluate a plan when its inputs change.
Evidence and review
Approved releases belong to a later stage of the Cloud sequence. Creating or reviewing a preview does not authorize production.
Product decisions and specification ·
- Keep temporary infrastructure temporaryPlanned
Apply preview lifetimes and resource limits. Track cleanup across containers, networks, volumes, and routes, including when a node disconnects.
Evidence and review
Cleanup is part of the planned preview lifecycle whether or not a release follows. Incomplete cleanup must remain visible.
Product decisions and specification ·
- Keep diagnostics proportionatePlanned
Store control-plane activity by default. Request bounded diagnostics when they are needed instead of continuously collecting your application’s logs or source code.
Evidence and review
This is the Cloud data-collection direction. It is not a description of an available hosted service.
Product decisions and specification ·
The first native-preview model requires eligible customer-controlled revisions, trusted CI evidence, and approved templates. Untrusted execution needs a later, separately qualified isolation path.
Integrations
Support must be explicit and testable.
A notification adapter is a way to deliver an event. It does not establish a deployment integration, runtime compatibility, or authenticated image pull support.
Runtimes and installation
- Docker Engine on LinuxDevelopment
Present in the development Core. Supported production combinations will be published after qualification.
Evidence and review
Docker is the first native runtime target.
Development Core documentation ·
- Docker Compose reference deploymentDevelopment
Present for installing Prontera and its proxy. This is not arbitrary application-stack provisioning.
Evidence and review
The reference installer uses Compose; the controller manages existing watched containers. A public downloadable release is still planned.
Development Core documentation ·
- Podman: rootful, followed by rootlessLater
Later, separately qualified runtime tracks. Docker compatibility does not establish Podman support.
Evidence and review
Rootful qualification precedes rootless qualification; neither is currently a qualified runtime.
Later compatibility qualification ·
Image discovery
- OCI registries and ECRDevelopment
OCI image discovery and ECR-specific integration code are present in development. Private-registry engine authentication still requires remediation and qualification.
Evidence and review
Discovery code does not establish qualified authenticated pulls for every private registry.
Development Core documentation ·
Notifications and email
- Slack, Discord, webhooks, and SMTPDevelopment
Present in the development Core; delivery hardening is ongoing.
Evidence and review
These are self-managed notification delivery adapters, not application deployment targets or Cloud collaboration integrations.
Development Core documentation ·
- Telegram, Gotify, ntfy, and PushoverDevelopment
Additional notification adapters present in the development Core.
Evidence and review
The full notification inventory is separate from runtime and registry qualification.
Development Core documentation ·
- Microsoft Teams through WorkflowsPlanned
Planned notification adapter using Workflows. Legacy Connector compatibility is not the intended product.
Evidence and review
The Workflows adapter remains planned work.
Product decisions and specification ·
- Managed Cloud emailPlanned
Planned convenience service. Existing self-hosted SMTP remains part of the Core.
Evidence and review
This product capability is separate from the website’s waitlist collection.
Product decisions and specification ·
Source and CI
- GitHub and trusted CI artifact handoffPlanned
Planned first Cloud workflow for eligible repositories and verified CI artifacts. Other CI systems are not automatically promised.
Evidence and review
The handoff must verify the repository revision, approved workflow, and immutable artifact identities.
Product decisions and specification ·
Human and agent interfaces
- Cloud dashboard, API, CLI, and MCPPlanned
Planned shared operations and authorization model. The local Core API, CLI, and web interface already exist in development.
Evidence and review
Planned agent permissions are limited to named operations and resource scopes. Production approval remains a separate decision.
Product decisions and specification ·
Private ingress
- Cloudflare TunnelPlanned
Selected for the planned managed preview path. This is not an existing partnership or a finished integration.
Evidence and review
This planned application-preview integration is separate from the infrastructure used to serve the Prontera website.
Product decisions and specification ·
External execution
- User-selected stronger-isolation providersLater
Later research and integration scope for external sandbox or microVM services. No working provider connector is being advertised.
Evidence and review
Prontera is not building a competing microVM deployment platform. External execution requires its own qualified isolation path.
Later compatibility qualification ·
Product names identify compatibility work or intended integrations. They do not imply endorsement, certification, or a partnership.
Qualification boundaries
Compatibility has practical limits.
Docker is the first runtime.
Production combinations are still being qualified. Podman needs explicit testing and implementation work, beginning with rootful operation and followed by a separate rootless track.
Image discovery and engine authentication are different.
Finding an OCI artifact is only part of an update. Private-registry authentication used by the runtime still needs remediation and qualification. The inventory does not promise working authenticated deployment from every private registry.
A preview is a distinct product workflow.
Running the frontend, API, supporting services, private access, and cleanup together requires the planned Cloud lifecycle. The current Core update planner does not provide that lifecycle.
Read the architecture and operational boundariesor follow the implementation sequence.
Source notes
How claims are maintained.
The homepage and this inventory share one status model. Evidence is reviewed before a capability’s status changes. The source repository remains private during release preparation, so its review references are identified here without presenting private links as public destinations.
- Development Core documentation
- README on main and docs/architecture/current-state.md at 3a24677feebd9c4f0c46e31255e2ce06b3b4f759; architecture checkpoint f9632c5075a94d4b2b12f34479d51518dacfe09f. Reviewed in the landing-page content brief, not a fresh production qualification.
- Product decisions and specification
- Decision and specification documents associated with PR #13, as recorded in the landing-page content brief. These describe intended work rather than implemented Cloud capabilities.
- Later compatibility qualification
- The runtime and external-execution sequence in the landing-page content brief. Runtime compatibility requires separate implementation and qualification.