Christian ManivongandClaude Opus 5
c40fa97cd1
The image moves off registry.netork.io. That registry is plain registry:2 with htpasswd auth, which knows nothing about repositories: every account that can log in reads and writes everything on it, including the accounts issued to customer instances. Verified -- a customer server's credentials list the whole catalogue. It keeps the images those instances are meant to pull; the marketing site is not one of them. Gitea scopes packages to their owning account, and no customer has one. netOrk #172. Login uses a REGISTRY_TOKEN secret (a Gitea token with write:package). The token Actions injects per run does not work here -- the package registry rejects it with a bare "unauthorized", which is a confusing way to spend an afternoon. The deploy job is removed rather than migrated, because it had quietly stopped being correct. It ran `docker run` against whatever runner picked the job up, which worked while exactly one runner existed. There are now several -- netork-runner-12 on .12, netork-runner-13 on .13, plus the original netork-runner -- and none of them is on 10.7.224.11, where this site runs and where the proxy-net it attaches to lives. The next push would have started a second website container on the wrong host and reported success while netork.io went on serving the old one. Nothing had failed yet; the last deploy was 2026-07-17, back when the pool was one runner. scripts/deploy.sh replaces it: it names the target, pulls before it removes anything, compares the running container's image id against what was pulled, and finishes by checking that netork.io actually answers 200. Push-to-deploy can come back by registering a runner on .11 with a label of its own and pinning `runs-on:` to it, or by giving CI an ssh key. Both decide where a credential lives, so neither was decided here. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>