Atrium
platform docsManifest lifecycle

Atrium platform docs

Manifest lifecycle

Understand local desired state, deployment state, Studio listing edits, and explicit synchronization.

Updated 2026-09-22

Keep desired state in your repository

atrium.yaml describes services, access policy, billing catalog, and other supported configuration. Commit it with the source it describes. Secrets and resolved platform values do not belong in that file. See the manifest reference.

atrium validate checks the local manifest. Server validation checks the submitted contract too; local acceptance alone does not guarantee that a deployment will succeed.

Deploy a reviewed source snapshot

atrium deploy previews the request and asks for confirmation before uploading local source. Eligible uncommitted changes are part of that snapshot. Review them before confirmation, particularly when another developer or process uses the same checkout.

The deployment records requested configuration and source information. atrium status reports resolved app state; history and detail describe individual requests. See Deployments for build, database, and service-update stages.

Studio listing edits are separate

Studio supports app management. Listing fields autosave through the editor API; this does not write a commit or pull request to your repository. The Source tab is not a connected source-code editor. Do not rely on Studio listing edits to update your local manifest, or on a deploy to reconcile every listing field automatically.

If you manage pricing both in the manifest and Studio, review the manifest before the next deploy: catalog synchronization can update published pricing. See Plans and entitlements.

Pull stored desired state explicitly

atrium sync

sync pulls the stored desired manifest into the local manifest path. Review the confirmation and resulting diff. It is not a bidirectional source sync and does not recover application source files. Preserve local changes before accepting an overwrite.

Read resolved values separately

atrium status --format json
atrium env backend --format env

Use your actual service key. Environment output can contain credentials; keep it out of tickets, screenshots, build logs, and source control. A returned value does not prove that the corresponding service is healthy or provisioned.

See Studio for listing/deployment management and Local development for temporary session environments.