forgejo: record why the runner is on vps2, rather than leaving a contradiction #153

Merged

admin_emi merged 1 commit from docs/runner-vps2-decision into dev

2026-08-01 17:00:37 +00:00

admin_emi commented

2026-08-01 16:59:34 +00:00

Owner

infra/deploy/forgejo/README.md 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 (#141). Both cannot stand — an instruction the estate visibly ignores teaches readers to ignore the next one too, which is the same failure mode as the "always-on Swarm-hosted runner" claim that hid the single point of failure for weeks.

The original objection is kept, not deleted, because it is correct on its merits: container.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 estate's only registered runner; 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 the whole estate — and the backup hangs off the same path.

The section now records the trade and the bounds actually applied (capacity: 1, --cpus=2 --memory=4g on job containers, valid_volumes: [], 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 preserves the original advice for the case it was written for: if you are adding capacity rather than redundancy, raise capacity or use a box that hosts nothing.

Documentation only — no behaviour change.

`infra/deploy/forgejo/README.md` 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 (#141). Both cannot stand — an instruction the estate visibly ignores teaches readers to ignore the next one too, which is the same failure mode as the "always-on Swarm-hosted runner" claim that hid the single point of failure for weeks. The original objection is **kept, not deleted**, because it is correct on its merits: `container.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 estate's only registered runner; 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 the whole estate — and the backup hangs off the same path. The section now records the trade and the bounds actually applied (`capacity: 1`, `--cpus=2 --memory=4g` on job containers, `valid_volumes: []`, 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 preserves the original advice for the case it was written for: if you are adding **capacity** rather than **redundancy**, raise `capacity` or use a box that hosts nothing. Documentation only — no behaviour change.

admin_emi added 1 commit 2026-08-01 16:59:35 +00:00

forgejo: record why the runner is on vps2, rather than leaving a contradiction

PR build (required check) / changes (pull_request) Successful in 6s

Details

secrets-guard / encrypted (pull_request) Successful in 5s

Details

PR build (required check) / build-backend (pull_request) Has been skipped

Details

PR build (required check) / build-frontend (pull_request) Has been skipped

Details

shell-lint / shellcheck (pull_request) Successful in 7s

Details

PR build (required check) / validate-observability (pull_request) Has been skipped

Details

PR build (required check) / gate (pull_request) Successful in 1s

Details

Sync infra to hosts / sync-beta (push) Has been skipped

Details

Sync infra to hosts / sync-prod (push) Has been skipped

Details

Sync infra to hosts / sync-dev (push) Successful in 5s

Details

Sync infra to hosts / sync-centralis (push) Has been skipped

Details

secrets-guard / encrypted (push) Successful in 4s

Details

shell-lint / shellcheck (push) Successful in 7s

Details

486a194086

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.