Worked example: Otto

A deployed three-service app

Otto is a job-application agent with a consolidated application repository. Its frontend, backend, and Hasura project are deployed together through Atrium.

agent-otto/
  atrium.yaml
  frontend/
  backend/
  hasura/

The useful pattern is one manifest with independently named services and one deployment workflow. You do not need Otto's internal data model or the Atrium platform repositories to use this pattern.

Service declarations

This abbreviated example illustrates the split, not Otto's complete production configuration:

apiVersion: atrium.dev/v1
kind: Agent
metadata:
  name: my-agent
  displayName: My Agent
services:
  frontend:
    type: nextjs
    path: frontend
    dockerfile: frontend/Dockerfile
    buildCommand: bun run build
    healthCheck: /api/health
  backend:
    type: python-fastapi
    path: backend
    dockerfile: backend/Dockerfile
    healthCheck: /health
  gql:
    type: hasura
    path: hasura
    healthCheck: /healthz
hosting:
  embedded: false

Otto names its Hasura service gql, so its canonical endpoint is https://gql.otto.apps.atrium.st. The starter uses database instead. Use the key in your own manifest; an HTTPS Hasura endpoint is not a PostgreSQL connection string.

Public pages and workspace work

Otto has public entry points alongside workspace-protected work. Follow App access and service URLs to declare public landing/static routes and subscription-protected application/API routes. Treat developer console access separately.

An explicit Free plan still requires enrollment. Paid plans add entitlements and quotas; the agent checks them before restricted work. Use Plans and entitlements and the Billing API rather than copying another product's prices. One-time paid credits remain subject to the availability limit documented there.

Summarize work with cases

Otto exposes case endpoints so Atrium Home can show a summary and link into the agent's own UI:

GET   /api/cases
POST  /api/cases
PATCH /api/cases/{id}

An adapter maps domain records into AgentCase. Keep it at the application boundary; your database model does not need to depend on the host's summary format. Rich editing and the full workflow stay in the agent application. See the AgentCase contract for a complete response.

Apply the pattern to your app

1. Start with atrium init --profile nextjs-fastapi-hasura or add equivalent services to your repository.
2. Confirm the database prerequisites before expecting migrations to run.
3. Add access and billing declarations, then run atrium validate.
4. Deploy from your own repository with atrium deploy.
5. Check service phases, migration/metadata results, and final URLs in Studio.
6. Test public, developer, and enrolled-customer access in the appropriate workspaces.

Keep credentials and resolved deployment identifiers outside the manifest. Use atrium status to inspect your deployment; another app's setup is not automatically provisioned for your app.