Written for a fresh session with none of the session history, because the person starting the migration asked whether the CLI had this context. It does not: memory and skills carry over, and the reasoning does not. This records what changed on 2026-11-01/02 that is not obvious from the rest of the plan: inbound 25 confirmed open so outbound 25 needs no ticket; Scaleway TEM proven by real headers (spf, dkim under the UUID selector, dmarc pass at p=reject); and the trap that Listmonk still sends through the Cloudron mail app, so a newsletter must not be assumed to route through the relay. Plus the DNS wildcard shape, the credential confirmations, what remains undone, the duplicate-Synapse caution, and the steward's own fallback route.
Runbooks
Operational runbooks for the co-op's infrastructure, published so members can read them and raise problems. That review is the point: these plans are safer when more eyes have been over them before anything irreversible happens.
Comment, or open an issue. There is no separate private copy — this repository is the source.
Contents
- cloudron-server-migration.md — the plan for moving Cloudron to the new server: pre-flight, the cutover window, what must be in hand first, and how to verify a restore. The one to read if you want to find problems.
- dns-change-sheet.md — the record-by-record cutover sheet.
- migration-before-state.json — the captured pre-migration state that the restore checker compares against.
- provider-pricing/ — what our model providers charge, and when it changed.
Read the DNS sheet with this in mind
Its record counts cannot be trusted until reconciled against the registrar's panel. The zone is wildcarded, so any hostname resolves — a name that answers proves nothing about whether a record exists. At least two listed records turned out not to exist, and the real record inventory is only visible in the registrar's own list.
No secrets here
Audited 2026-11-01, including the full commit history: no credentials, tokens, keys, member emails or account identifiers. Where a runbook needs a credential to exist (a backup passphrase, an S3 key), it records where the credential is held, never the credential.