Skip to content

ADR-0015: Staging and production environments

  • Status: Accepted
  • Date: 2026-07-25
  • Deciders: El

Context

Once real client tenants exist, platform changes (brain logic, workflows, upgrades) cannot be tested on the infrastructure running a client's live business. We need a safe place to test the platform before it touches any client. Separately, a client may one day want their own sandbox to trial their own config changes before they hit their live automation — a different, later need.

Decision

Two environments, both operated by Octopodia: - Staging — where we build, test, break things, and de-risk any change before it reaches a client. Runs the golden templates (ADR-0016) and, later, is where every change is validated first. Octopodia's own / fake data only, never a real client's live data. - Production — where real client tenants live. Nothing untested reaches it; changes flow staging -> production only after they work in staging. Clients only ever see production. A client pilot (ADR-0013 pilot mode) is a capped tenant in production, not staging.

Separate boxes, one management system: staging and production are distinct hosts (isolated hardware — you cannot fat-finger production while working in staging), managed by a single Ansible setup — one repo, one set of roles, one inventory with staging and production groups, environment-specific values in group_vars. Same roles applied to both, so staging genuinely mirrors production.

environment is a first-class label on a tenant/host (alongside region and mode), so staging and production config can never be crossed and reconciliation can verify a tenant is where it belongs.

Sequence (C -> A): stand up the staging box first (it hosts the initial golden-template build and is the permanent workshop); stand up production as a separate box when the first real client is BOR'd and ready. Per-client sandbox/test-vs-live splits are deferred and built only if a client needs to self-manage.

Consequences

The hardening/provisioning work is used immediately on the staging box — the first real playbook run happens on throwaway hardware with no client data; two boxes cost more but guarantee testing cannot touch a live client; adds environment grouping to the existing inventory (small, no rework); per-client test/prod is not built now and needs no hooks yet.

Alternatives considered

  • Single box, staging and prod as separate stacks — rejected: testing would share hardware with real client data.
  • No staging (test in production) — rejected: cannot test changes on a client's live business.
  • Per-client sandbox now — rejected: a later sophistication; we make config changes on clients' behalf, tested in our staging.