486a194086
All checks were successful
PR build (required check) / changes (pull_request) Successful in 6s
secrets-guard / encrypted (pull_request) Successful in 5s
PR build (required check) / build-backend (pull_request) Has been skipped
PR build (required check) / build-frontend (pull_request) Has been skipped
shell-lint / shellcheck (pull_request) Successful in 7s
PR build (required check) / validate-observability (pull_request) Has been skipped
PR build (required check) / gate (pull_request) Successful in 1s
Sync infra to hosts / sync-beta (push) Has been skipped
Sync infra to hosts / sync-prod (push) Has been skipped
Sync infra to hosts / sync-dev (push) Successful in 5s
Sync infra to hosts / sync-centralis (push) Has been skipped
secrets-guard / encrypted (push) Successful in 4s
shell-lint / shellcheck (push) Successful in 7s
This README said, in bold, that a runner must never go on prod or beta. A runner has been registered and running on vps2 since 2026-08-01. Both statements cannot stand: an instruction the estate visibly ignores teaches readers to ignore the next one too. The original objection is kept rather than deleted, because it is correct on its merits -- docker_host: automount hands job containers the host's Docker socket, which on vps2 is root over both the prod and beta stacks. What changed is that the alternative proved worse. The desktop was the ONLY registered runner in the estate; when it dropped on 2026-07-31 nothing merged, nothing deployed and the nightly backup did not fire for 21 hours. On a repo where every branch is protected and every change is a PR, one absent runner freezes everything, and the backup hangs off the same path. So the section now records the trade and the bounds actually applied -- capacity 1, --cpus=2/--memory=4g on job containers, valid_volumes empty, no thermograph network -- and states plainly that this is defence against accident, not against a hostile workflow author. Forgejo's database already stored VPS2_SSH_KEY, which is root on that box; what changed is that the material is now reachable by a job rather than only at rest. It also keeps the original advice for the case it was actually written for: if you are adding CAPACITY rather than REDUNDANCY, raise capacity or use a box that hosts nothing. |
||
|---|---|---|
| .. | ||
| backup | ||
| db | ||
| forgejo | ||
| migrations | ||
| openmeteo | ||
| secrets | ||
| stack | ||
| swarm | ||
| twa | ||
| Caddyfile.vps1 | ||
| Caddyfile.vps2 | ||
| deploy-dev.sh | ||
| deploy.sh | ||
| env-topology.sh | ||
| migrate-db.py | ||
| POSTGRES-MIGRATION.md | ||
| provision-agent-access.sh | ||
| provision-dev.sh | ||
| provision-mail-supervision.sh | ||
| provision-mail.sh | ||
| provision-secrets.sh | ||
| render-secrets-openbao.sh | ||
| render-secrets.sh | ||
| RUNBOOK-vps1-vps2-cutover.md | ||
| thermograph-dev.service | ||
| thermograph.env.example | ||
| thermograph.service | ||