Production Deployment (Vercel, Fly, and FORJD)
Chapter 22: Production Deployment (Vercel, Fly, and FORJD)
The ultimate crucible for any software architecture is its transition from a controlled local development environment into the hostile, chaotic reality of the public internet. The "it works on my machine" paradigm is an unacceptable failure of engineering discipline. To guarantee that my platform performs with absolute consistency and resilience, deployment cannot be treated as a discrete, manual event. It must be codified, automated, and treated as a seamless extension of my Continuous Integration pipeline.
Primary production hosts are fixed for the product:
| Surface | Host | Public hostname (typical) |
|---|---|---|
| Angular product UI | Vercel (deml) |
https://deml.app |
| Django BFF / control plane | Fly.io deml-backend |
https://backend.deml.app |
| FORJD API + engine + Dragonfly | FORJD on Fly + Supabase | https://backend.forjd.co |
DEML owns identity, billing, consent, learning, and BFF adapters. FORJD owns sealed ingest, streams, projections, status pages, analytics, ML, SIEM/SOAR, and reports. Firebase Authentication terminates at Django; Firebase carries no product data (no Firestore, Storage, or Cloud Functions for telemetry). Operator checklists: docs/PRODUCTION_DEPLOY.md, docs/PRODUCTION_CHECKLIST.md, docs/VERCEL.md, docs/FLY.md.
This topology scales surgically. Vercel distributes Angular assets globally; Fly scales deml-backend for control-plane load; FORJD scales the sealed pipeline and projections independently so a traffic spike on the product UI never forces DEML to invent local stream workers. Cross-site URLs remain the env-driven trio (FRONTEND_URL, BACKEND_URL, MARKETING_URL); FORJD_API_URL is configured separately and must never replace BACKEND_URL.
CI/CD splits by surface: merge to main deploys Angular on Vercel and Django on Fly when their paths change; FORJD deploys from its own repository and Fly apps. Distroless multi-stage images remain the packaging standard for Django (and for alternate container hosts). Google Cloud Run (Appendix C) and AWS Lightsail/Fargate (Chapter 23) are supported alternate control-plane topologies when an organization requires those residencies—they are not the primary shipping model.
Infrastructure & Compute Resource Allocation
To maintain a highly efficient, cost-optimized deployment footprint, the platform is designed to run extremely lean on the DEML control plane while FORJD owns data-plane capacity.
| Service / host | Typical sizing | Justification |
|---|---|---|
| deml (Vercel Angular) | Serverless / edge | CSR product UI; no DEML stream plane |
| deml-backend (Fly Django) | 1–4 vCPU / 1–4 GB | Auth, billing, consent, learning, FORJD BFF adapters |
| DEML Postgres | Managed | Identity, billing, consent, FORJD tenant mapping (secret refs only) |
| FORJD API + engine (Fly) | Per FORJD runbooks | Sealed ingest, workflows, projections, status, analytics, ML, exports |
| Supabase / Dragonfly (FORJD) | Per FORJD runbooks | FORJD Postgres/RLS, Realtime, cache/streams |
FORJD engine and API scale independently from the DEML control plane; ML, status, and analytics capacity live on FORJD (backend.forjd.co).
Estimated Monthly Infrastructure Costs
Baseline DEML control-plane spend is dominated by Fly Django + managed Postgres + Vercel. FORJD compute, Supabase, and Dragonfly are billed on the FORJD side—not as DEML-local OLAP or broker nodes. Treat Cloud Run–style “provisioned vCPU × hours” math as an alternate-host estimate only (Appendix C); primary ops use Fly/Vercel usage meters and FORJD’s own cost model.
Note on persistent storage: DEML Postgres holds control-plane state. Sealed-event volume, projection retention, and export object storage grow on FORJD (Supabase + FORJD export store)—retain aggressively per FORJD policy, not via retired DEML rollup tables.