Atrium
platform docsDeployments

Atrium platform docs

Deployments

How agent deploy requests, web app releases, Cloud Run services, and queued deployment status fit together.

Updated 2026-08-30

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.