ADR-002 — Hosting platform
Status: Proposed · Date: 2026-06-26 · Deciders: Eng Lead, DevOps, Product · Tags: infra, deploy
Context
Phase 0 (Phase_0.md §Epic 0.E.3) requires the principal hosting choice locked so CI/CD (main.yml, release.yml) and the production topology (Phase_9.md §6) can be built. The app is a standalone Next.js 15 server + MongoDB Atlas + Redis + S3-compatible object store.
Decision
To be ratified at G0. Recommended default for v1: containerised Next.js (standalone output) on a managed container platform (e.g. AWS ECS/Fargate or Fly.io), fronted by a CDN, with MongoDB Atlas as the managed database. This keeps the door open for the blue-green / canary release strategy required at G9 and avoids serverless cold-start and connection-pool issues with MongoDB.
- Containerisation is deferred to the deployment phase — current development runs locally in dev mode only (no Docker in the repo yet). A standalone Next.js output + Dockerfile will be added when staging/prod hosting is provisioned.
- Region chosen for data residency alignment (
NFRSprivacy targets).
Alternatives considered
| Option | Pros | Cons | Why not (yet) |
|---|---|---|---|
| Managed containers (ECS/Fargate, Fly) | Blue-green, no cold start, full control | More infra to manage than Vercel | — (leading choice) |
| Vercel | Best Next.js DX, zero-config | Serverless + Mongo pooling friction; cost at scale; less control over blue-green | Reconsider for marketing site, not app |
| Kubernetes (self/managed) | Maximum control | Highest ops burden | Overkill for v1 scale |
| Render | Simple managed | Fewer release-strategy controls | Viable fallback |
Consequences
- Container path means the same image runs locally, in CI scan, staging, and prod.
- Enables the Phase 9 blue-green/canary + automatic rollback on SLO breach.
- Pairs with ADR-001 (secret store pulled at runtime, no disk plaintext).