Atrium platform docs
Manifest lifecycle
Understand local desired state, deployment state, Studio listing edits, and explicit synchronization.
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.