Atrium platform docs
Deployments
How agent deploy requests, web app releases, Cloud Run services, and queued deployment status fit together.
Agent deployments
Agent authors deploy through:
atrium deploy
The CLI validates desired state, previews a compact deploy plan, and sends a deploy request to the control plane:
POST /v0/platform/agents/{agent_id}/deploy
The CLI does not call cloud infrastructure APIs directly.
Deployment requests
The backend persists deployment requests in platform storage. If
ATRIUM_DEPLOY_WEBHOOK_URL is set, it dispatches to that worker. If no worker
URL is configured, status can remain queued.
This is intentional during bring-up. Cloud writes stay behind the control plane instead of being run directly from every CLI.
For an unregistered slug, dry-run deploy can return action: "create" with
registration.willCreate=true. The dry-run does not write the agent row. A
confirmed deploy creates the agent record, stores the manifest, and queues the
deployment request.
Resolved status
Use:
atrium status
Status should report whether the control plane accepted the desired manifest, what deployment state is known, and which platform-owned values were resolved.
Web app release path
The Atrium web monorepo also has an internal release script for the existing Cloud Run services:
source ~/py3.12/bin/activate
uv run python packages/apps/scripts/release.py --app app auth
That script builds Docker images from the web repo, pushes them to the container registry, and deploys the app and auth services to Cloud Run. It is for platform operators, not the public agent-author deploy path.
Production services
The release script currently targets:
| Service key | Cloud Run service | Public URL |
|---|---|---|
app |
atrium-app |
https://atrium.st |
auth |
atrium-auth |
https://auth.atrium.st |
otto |
atrium-otto |
https://otto.atrium.st |
All three build through Docker using the root bun.lock. The shared
@atrium-ai/ui workspace package is built before app builds.