Deployment
Deployment
Section titled “Deployment”Atlas runs the same way as the rest of the TypeScript tier: a Hono API service, a pg-boss worker, and a PostgreSQL database with row-level security.
Topology
Section titled “Topology”- API service — serves the HTTP surface (
/v1/*,/healthz,/readyz). - Worker — runs ingest reconciliation off the pg-boss queue.
- PostgreSQL — canonical entities, cross-references, mappings, and the ingest log, all under RLS.
Deployment modes
Section titled “Deployment modes”Set via configuration and reported in GET /v1/contract as deployment_mode:
saas— multi-tenant, behind platform auth + billing.standalone— single-tenant self-host; runs with no platform reachable.dev— local development.
Database & RLS
Section titled “Database & RLS”All tenant-scoped access goes through a withTenant(db, tenantId, fn) wrapper
that sets the RLS GUC before each query; the app role is NOBYPASSRLS. Migrations
are advisory-locked so parallel replicas don’t race. See Security.
Auth (managed)
Section titled “Auth (managed)”In saas mode, platform is the auth authority. It mints short-lived
per-tenant JWTs; Atlas verifies them via JWKS. Tenant → workspace mapping is
provisioned lazily on first use. The ingest plane is separate — it
uses per-endpoint HMAC secrets, not the JWT.
Self-host
Section titled “Self-host”For standalone, run the API + worker against your own PostgreSQL with your own
object storage for any referenced bytes (Atlas references trove/S3 assets; it
does not store bytes itself). No platform is required.
Environment
Section titled “Environment”| Variable | Purpose |
|---|---|
ATLAS_DEPLOYMENT_MODE | saas / standalone / dev. |
DATABASE_URL | PostgreSQL connection (RLS-enforcing role). |
ATLAS_JWKS_URL | JWKS endpoint for verifying platform-minted JWTs (saas). |
See Integration for the consumer-side
(ATLAS_BASE_URL, ATLAS_AUTH_TOKEN, ATLAS_INGEST_*) variables.