Releases and environments

This page explains what Axiom Cloud does after axiom release uploads a contract: how it stores the artifact, which checks run, when the release becomes latest, and how the managed sandbox and project environments fit in. To create a release, see Releases and upgrades.

Cloud uses "environment" for two different things:

Local development needs neither and allocates no hosted storage. Creating one kind never provisions, fills or authorizes the other. Deleting a sandbox never deletes database data or an environment's secret values.

Immutable release identity

The server computes the SHA-256 hash of the uploaded .axiom bytes. A project and version pair is immutable:

• Uploading the exact same bytes again resolves to the existing release.
• Uploading different bytes under an existing version is rejected with a version conflict and a suggested next version.

A source URL is provenance metadata, not the stored artifact.

axiom build axiom.acore --out backend.axiom
axiom release backend.axiom --version 1.2.0

The release pipeline

Diagram source

flowchart TD
  U[uploaded] --> V[verifying]
  V --> VD[verified]
  VD --> T[testing]
  VD --> D[deployable]
  T --> D
  D --> DG[deploying]
  DG --> DD[deployed]
  U --> F[failed]
  V --> F
  VD --> F
  T --> F
  D --> F
  DG --> F

A release moves from uploaded through verification and testing to deployable. Any state before deployed can end in failed. Activation on the latest channel moves a release through deploying to deployed.

The release worker saves evidence for each stage of each attempt: artifact ingest, manifest validation, Cloud signature, semantic diff against every earlier release, policy validation, sandbox provision, contract tests and channel activation. The semantic stage also rejects a Security Mode strict release that has error findings. CI/CD Actions in the project settings shows each run and its stages. A queued or skipped stage stays visible as queued or skipped; the dashboard never shows it as a success. Retrying a failed release creates a new attempt for the same artifact. It never rewrites the earlier attempt.

deployable means the evidence and policy allow activation. deployed means the release was activated on latest. Neither claims that a backend binary or mobile application was deployed.

Release policy

Projects use this default release policy:

The latest channel

latest is a pointer to one eligible immutable release. Consumers that pull without a version get the release it points to. Before the first activation it points to nothing, and a pull without a version finds no release.

• Activation and rollback are owner operations.
• Each request carries the channel generation you reviewed, so a stale decision cannot overwrite a newer one. Repeating the same request is safe.
• Rollback moves the pointer to an earlier eligible release. It never edits either artifact.

Managed sandbox

A managed sandbox runs a synthetic mock of one verified release, so contract tests and early consumers have something to call. Each project has one live sandbox.

• Launch it from the Sandbox page with Launch from active release, or let the release pipeline start it to run declared tests. The dashboard starts a token-protected sandbox that expires after 24 hours. The API accepts expiries from 5 minutes to 7 days.
• Provisioning, health, reset, expiry and deletion are saved as lifecycle events. Saving new mock configuration while a sandbox is live deploys a new revision of the same sandbox instead of a second one.
• Protected requests need the X-Axiom-Sandbox-Key header. Maintainers and owners see the key with Reveal connection once the sandbox is ready. It stays in that page's memory only. Keep it out of logs and local storage.
• Use only synthetic or developer-safe data. A sandbox is not a production data plane.

To author the mock behavior, see Cloud mocks.

Contract tests

Declared suites run against the ready sandbox for the same immutable artifact and release attempt. Results are saved independently of the runner. The Tests page lists runs with passed, failed and skipped counts. You can also run the active signed release's suites manually. To write tests, see Contract tests.

Project environments

Alpha: the dashboard assigns a managed database to a project environment when you save database preferences. Hosted database runtime connections from Cloud Run servers are Alpha. Managed application authentication is Alpha: each environment has its own issuer, users and sessions. Secret environments keep their documented support.

Database preferences and the Secrets page share the same project environments. The environment name you enter with database preferences (default development) creates or reuses an environment. The names production and staging get those kinds, and production is always protected. Any other name becomes a development environment.

Keep environments isolated

• Environments never automatically share application users, sessions, credentials or secret values.
• Start previews from synthetic or sanitized data.
• A database branch is a separate resource. It does not automatically merge schema or data into production.
• Managed SQLite uses table and action permissions to protect authentication and migration tables. Those permissions do not replace row-ownership checks in your application. PostgreSQL uses protected schemas and restricted roles, with row policies where supported.
• Managed authentication databases must not be replicated into browsers or mobile devices. Clients use authenticated application operations.

Before you change a hosted resource, check its project, environment, profile, location and current state. Changing a subscription never silently converts the database engine or moves data across regions.

The initial allowance is one hosted environment per project. Additional environments, migration test databases and restore targets use hosting capacity even when temporary.

Next steps

• Review two releases in a contract pull request
• Author mock behavior for the sandbox
• Provision a managed database
• Store secrets for an environment