Files
rootnode-academy/infra/environments/staging
ced4568 507ac4c5d3 feat(ansible): idempotent role-based host config for both production VMs
common/firewall/docker-tls/platform/lab-host/monitoring-agent/backup roles,
orchestrated by site.yml with the ordering that matters (firewall/TLS land
before the services that depend on them). Ansible Vault for secrets, no new
tool introduced for this project's modest secret surface. Explicit
dev/staging/production environment separation, no secrets committed
(.gitignore covers vault plaintext, TLS keys, Terraform state, *.env).

Validated: ansible-playbook --syntax-check clean.
2026-08-18 17:13:01 -05:00
..

Staging environment

Same shape as production (docs/PRODUCTION_DEPLOYMENT.md applies to both — pass -e env=staging to the Ansible playbooks), lower stakes: separate database name/port, staging-tagged images, and COOKIE_SECURE only if staging actually sits behind HTTPS. See docs/CI_CD section in docs/PHASE4_PRODUCTION_INFRASTRUCTURE.md §18 for how a Gitea Actions build lands here automatically before a human promotes it to production.

Staging is designed to run either in the homelab (a couple of low-resource VMs/containers) or, once the dedicated server exists, as a resource-constrained slice of it — see docs/PHASE4_PRODUCTION_INFRASTRUCTURE.md §23 for the sizing note. It does not require a second dedicated server.

Staging acceptance = the same four things a person actually needs before promoting a build: app deploys, migrations run clean, one or two disposable Labs boot through the Gateway, and an assessment can be started and completed. See infra/scripts/staging-smoke-test.sh.