- Status: Accepted
- Date: 2026-04-26
- Sub-project owner: Foundation
- Spec ref: Foundation §4.1
Foundation must give every contributor a reproducible dev stack — SQL, Redis, identity provider, mail capture, antivirus daemon — without committing to a specific production hosting target. The ministry's hosting decision (on-prem, gov cloud, hybrid) is out of scope for sub-project 1 and would block work indefinitely if treated as a precondition.
At the same time, "works on my laptop" is not enough: every contributor must run an equivalent stack, and CI must run something close to it.
Foundation targets local Docker Compose as the canonical dev environment. Production hosting is deferred to a later sub-project (likely 8 or a dedicated Ops cycle). All services in docker-compose.yml use container images that are also realistic for production (or have a documented prod swap).
- A single
docker compose up -dbrings the whole infra stack online; no manual SQL Server install, no per-laptop Keycloak. - Stack stays portable: same images run on macOS, Linux, and CI runners.
- Production hosting decision is unblocked from Foundation timeline.
- Container hardening (Trivy scans, image pinning) is a single, uniform exercise.
- Compose is not production: HA, secrets management, network policies, and orchestration are not modeled.
- Some services have arm64 substitutes (Azure SQL Edge, clamav-debian) that don't run in prod — see ADR-0016, ADR-0018.
- Compose remains the dev stack into sub-projects 2–9; production hosting picks up in a later cycle.
- A migration-compatibility test (sub-project 2) covers the dev-vs-prod database engine gap.
- Rejected: blocks Foundation on a ministry decision; over-models infra concerns at the wrong stage.
- Rejected: per-laptop drift; unrealistic for non-Linux contributors; no clean way to mirror in CI.