archy/.planning/todos/pending/2026-08-02-migrate-vps2-ip-to-domain-in-registry-references.md

created, title, area, severity, files

created	title	area	severity	files
2026-08-02T12:30:00.000Z	Migrate VPS2 IP (146.59.87.168) to its domain across registry references	infra	major	apps/*/manifest.yml (the bulk — every `image:` line) .gitmodules .github/workflows/*.yml (both) app-catalog/catalog.json (signed — changing it forces a re-sign) Android/**/FipsPreferences.kt, Android/**/PartyScreen.kt (compiled constants)

Problem

98 operational files still carry the bare IP 146.59.87.168. The domain (source.archipelago-foundation.org) was only ever adopted for the git remote — the IP is still baked into every container registry reference, which is a different thing entirely:

image: 146.59.87.168:3000/lfg2025/gatewayd:v0.10.0

Plus .gitmodules, both CI workflow files, app-catalog/catalog.json, and the Android companion (FipsPreferences.kt, PartyScreen.kt). A further 117 hits live in .planning/ docs — those are historical records and must stay as they are.

An IP in every manifest is exactly the kind of thing that bites when the VPS moves. It is also conspicuous in a public repo, so the open-source-readiness work will want it done (see docs/OPEN-SOURCE-READINESS-PLAN.md).

Why this is not a find-and-replace

1. The registry has to actually answer on the domain. source.archipelago-foundation.org currently serves Gitea over HTTPS on 443, while images are pulled from :3000 over plain HTTP. Podman treats host:3000 and domain as different registries, so changing the string means every node re-pulls every image under the new name — and any node that cannot resolve or trust the new host fails to pull at all.
2. It invalidates the signed catalog. app-catalog/catalog.json carries image references, so changing them breaks the signature and forces a regenerate-and-re-sign — which needs the release mnemonic, same as a release.
3. The Android companion ships compiled constants, so it needs its own APK rebuild to follow.

Solution

Its own plan with a real rollout order — not something to slip into a release:

1. Registry serving on the domain (TLS, and a decision on whether images move to 443 or the domain also exposes :3000)
2. Manifests
3. Catalog regenerate + re-sign (mnemonic ceremony)
4. APK rebuild

Sequencing matters because steps 2–4 are useless — and actively breaking — until step 1 holds.

Notes

Analysis produced by the concurrent companion/release agent on 2026-08-02 before its session ended; recorded here so it is not lost. It had not touched any of the work.