Skip to content

4.3 Environments

An environment is an isolated configuration of where our systems run. Cloud environments have separate projects, networking, data and permissions. There are four: shared, sandbox, stage and prod. Development is not a cloud environment: each developer runs every system on their own computer with Docker (Running Locally, decided 2026-11-11). Shared foundations and stage are the active managed cloud scopes; production is prepared separately.

4.3.1 The Four Environments

flowchart LR sbx[Sandbox<br/>experiments] stage[Stage<br/>approved integration releases] prod[Prod<br/>future activation] shared[Shared<br/>bootstrap, CI, registry, logs] main([Build from main]) main -- build and approved release --> stage stage -- success, tests and future approval --> prod shared -. builds and records .-> stage & prod
Environment What it is for Data it may hold How changes arrive
Shared Terraform state and CI control; other shared services only when explicitly provisioned. Current application registries belong to the stage application projects Infrastructure metadata and approved operational records; no customer datasets by default Reviewed Terraform plans; automatic infra apply is not yet activated
Sandbox Trying cloud services and our applications freely, one project per person Never real data By hand; may be wiped at any time
Stage Verify integration, releases and security boundaries before production Synthetic fixtures initially; any real-data use requires its own authorization and controls Reviewed commit, checks/build, release preparation and explicit stage rollout approval
Prod The future official environment where customers work and company data lives Real data under the product's access and retention contract Same candidate images that succeeded in stage and passed required tests, after production approval

The target workflow is described in Branching & Promotion; Application Delivery distinguishes the existing manually initiated path from automation still to enable.

4.3.2 Environments Stand Alone

An environment must never depend on another to keep running. If one disappears, the others keep serving.

This rule decides where things live:

  • Each environment owns its network and its traffic destinations. DNS records may share an externally managed authoritative zone, but stage records and permissions must be scoped so changes to stage do not change prod's records or backends. A move of authoritative DNS is a separate decision.
  • Shared holds only what builds or records the others. Losing shared stops new releases and infrastructure changes, but running services keep serving: Cloud Run keeps its own copy of every deployed image, so the registry is not needed to start a new instance.
  • No network peering between environments. Stage and prod cannot reach each other, even by mistake.
  • No data flows from prod to a lower environment except anonymized datasets produced by a reviewed export (see Data).

The one link between environments

Stage's names, stage-<system>.moonitoring.com, will point at stage's approved load-balancer frontend, not expose each backend's Cloud Run URL. DNS, certificates and routing are activated together after validation. See Network.

4.3.3 What Is the Same and What Differs

The target is to reuse the same Terraform modules and image digests for stage and prod, with explicit environment configuration and security boundaries. The stage edge is planned with the same relevant patterns as prod, but has not been certified by the current Access rollout. Read Network and the dated baseline before treating a target as deployed.

Sandbox Stage Prod
Public edge (load balancer, Cloud Armor) case-specific load balancer with IAP on every backend and the URL map path allowlist; no Cloud Armor (decided 2026-11-11, Network). IAP admits infra-admins and, on the hosts of the apps and of the systems, the stage testers' group stage-testers@moonitoring.com (decided 2026-11-12, extended to the system hosts on 2026-11-13) future target, with Cloud Armor
Database (Cloud SQL) case-specific one instance, separate databases and privileges per system future sizing/availability decision
Machine learning projects no no prod-ml-lab, prod-ml
Budget when exceeded explicit sandbox policy; not implied by a budget alert alerts; limits configured separately alerts; no automatic stop inferred from budget
Change control its authorized owner reviewed Terraform plan/apply and approved application delivery future controlled activation and release path