Developers
Deployment
Understand the cloud topology and the boundaries of offline private delivery.
Cloud and private deployments share source and protocols, but have separate artifacts, dependencies, and acceptance evidence.
Cloud topology
| Entry point or platform | Responsibility |
|---|---|
| www.example.com | Vercel: public website and documentation |
| app.example.com | Vercel: authenticated console and Web BFF |
| api.example.com | Fly.io: gateway, Control API, and module APIs |
| collab.example.com | Fly.io: collaboration connections |
| Supabase Cloud | Postgres, Auth, Storage, and optional Realtime |
| Temporal Cloud | Workflow service; business workers deploy separately |
Configure apps/www and apps/web as separate Vercel projects. The public site holds no Supabase sessions or backend secrets. The console connects to the appropriate test or production backend.
Offline private delivery
Private installations use Docker Compose, self-hosted Supabase and Temporal, separate databases, and customer workers. Deliver prebuilt images, signed manifests, offline assets, migrations, an SBOM, and recovery instructions. Do not depend on building source over the internet at installation time.
Readiness
Deployment readiness depends on evidence from the relevant environment. A successful source build does not validate cloud resources, cross-origin access, identity, recovery, or failure handling. A working demo does not establish full production acceptance.