Atrium platform docs
Local dev loop
How validate, dev, env, logs, sync, and deploy fit together while building an Atrium agent.
The loop
Use this loop while changing an agent:
atrium validate
atrium dev
atrium status
atrium logs frontend --lines 100
atrium deploy
The manifest is desired state. Commands that need platform details ask the control plane for resolved state.
atrium dev
atrium dev validates the manifest, asks the control plane for development
bootstrap data, and starts the local service commands.
atrium deploy
atrium deploy sends desired state to the control plane and relies on
platform build machinery to resolve credentials.
The backend currently records a deployment request. If
ATRIUM_DEPLOY_WEBHOOK_URL is configured, the API dispatches to that worker.
Without a webhook, deployment status can remain queued.
atrium env
atrium env frontend
Use env to inspect read-only resolved values for one service. These values
can include platform-injected API URLs and database credentials. Do not copy
them into atrium.yaml; the validator rejects platform-owned env fields.
atrium logs
atrium logs frontend --lines 100
atrium logs frontend --follow
Recent log reads are backed by Cloud Logging. Streaming follow=true is not
implemented on the backend yet, so the CLI polls client-side for now.
atrium sync
sync pulls control-plane desired YAML down to the local checkout when the
dashboard or another workflow has changed the manifest. It should never push
local changes silently. If local and remote desired state disagree, the user
should see that disagreement.