Start with clear boundaries.

Report a concern

Contact the project directly.

Send security reports to prontera@ramonoliveira.xyz.

Include the affected version or page, a description of the impact, and enough steps to reproduce the concern. Share only the information needed to understand it, with credentials and unrelated personal data removed.

For general project questions or waitlist data requests, use the project contact or read the privacy notice.

The current Core boundary.

The local Core executes update operations. In the reference architecture, a constrained proxy holds the Docker socket and the Prontera daemon accesses the runtime through that proxy.

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

A health-gated update can attempt to restore the captured image and runtime configuration. Interrupted-operation recovery is still being completed. Restoring a container image does not undo database migrations or application-data changes.

A design boundary or development checkpoint does not establish production readiness. Qualified runtime combinations and release checks remain part of the Core qualification work.

Cloud authority is scoped by design.

The planned Cloud model uses an outbound node connection, named operations, and resource scopes. The dashboard, API, CLI, and MCP interface are intended to share those permissions. Agents do not receive unrestricted SSH or Docker access through this product model.

The initial native-preview path requires eligible customer-controlled revisions, trusted CI evidence, and approved templates. Running a build in a sandbox does not, by itself, make its output trusted. Untrusted execution needs a later, separately qualified isolation path.

Reviewer access belongs to a specific environment. Production approval is a separate decision, and preview cleanup is required whether or not a release follows.

The website waitlist.

The waitlist implementation validates input on the server, limits request size, verifies request origin, and applies rate limits. The rate-limit secret remains on the server, and temporary abuse counters use keyed hashes of network and email addresses.

Requests are stored directly without verifying control of the submitted email address. Responses avoid disclosing whether another person’s address is already registered. Removal requests are handled manually through the project contact after verifying that the requester controls the address; there is no public endpoint that deletes records by email address.

The waitlist does not collect infrastructure credentials or provision customer resources. Its data, processors, retention, and deletion limits are described in the privacy notice.