They were published to co-op/runbooks for member review, so the README's own 'Private: these contain...' line was both wrong and the first thing a reader saw. Also records the DNS sheet's wildcard caveat up front, and says explicitly that this repository is the source (no private copy).
docs.inference.coop does not exist — it resolved only because *.inference.coop answers, which is how it got into this sheet (and into the digest footer, since fixed to point at git.inference.coop/co-op/docs). Adds the consequence that matters for cutover: a resolving name proves nothing here, so reconcile against the registrar's record list rather than by resolution.
Answered the subscription question with our own SpendLogs rather than guessing: 452 requests, $4.38, essentially all in the last 30 days, against $426 lifetime gateway spend. A plan must beat ~$4.38/month; Regolo prices are not published. Their 30-day trial (1M tokens/day) would cover our ~120k/day. Also puts the 2026-11-01 change in money terms: ~$1/month, so accuracy rather than urgency.
Records the announced table, our current applied costs, and the two models we serve. apertus-70b input rises 152% and qwen3.5-122b input falls 40%; until the gateway costs are updated we under-bill apertus by ~70c/M and over-bill qwen by ~46c/M. Also documents that regolo/qwen-image prices EUR as USD with no conversion.
Measured from the agent host: setup page live on both IPs, 80/443 open on v4 (rules gap fixed), cert is a valid Let's Encrypt IP certificate (not self-signed) so no ACME exposure for the domain, no cloudron CLI on a server, and 25/465/587/993/995/4190 still closed there.
Current Cloudron serves the setup page on the server IP with a self-signed cert and takes the domain in the wizard, so cloudron-setup needs no DNS and, with the domain left unset, makes zero certificate attempts: the rate-limit risk only appears if the domain is entered while DNS still points at Hostinger. Adds the post-install checks (version >= 10.1.5, pristine, no apps) and a VPS snapshot to roll back to.
Passphrase + Vaultwarden master password confirmed off-box in the operator's KeePass vault. S3 secretAccessKey still unconfirmed - the one credential not in the co-op's own JSON. Notes that the Vault is Vaultwarden (nothing to sync with Bitwarden) and that all break-glass copies sit with a single custodian.
Backup passphrase confirmed off-box by the operator 2026-10-30 (was the blocker). Outstanding: S3 secretAccessKey (absent from the off-box JSON) and the Vault export. Announcement drafted for #updates with placeholders for the window.
Diffs the restored server against migration-before-state.json: app inventory, env var names, image tags, backup target, portal row counts, DNS, federation, mail ports, site responses. Dry run 2026-10-30: 50 pass / 1 warn / 13 fail, every failure explained by pre-cutover DNS or port 25.
Snapshot records apps/images/env-names/backup config and data fingerprints for a
post-restore diff. Also resolves an open unknown: the off-box JSON carries only
accessKeyId, so the S3 secretAccessKey must be retrieved before the window. The
restic passphrase is fine - it is on the agent host, which is not migrating.
Verified from outside: rules applied on IPv6, nothing but SSH on IPv4.
Blocked=timeout, permitted-but-idle=refused, so the state is readable
before Cloudron is installed. Inbound 25 required (Cloudron docs);
outbound 25 unnecessary with a relay, which this box has.
Mail is enabled inbound for inference.coop (platform mail server, not the
Mail app container, which is only a UI on :3000). Ports verified against
the old box. Whether mailbox CONTENTS are in the Cloudron backup is
unverified and would be silent data loss - now the highest-priority open
question.
Ubuntu 26.04 LTS is supported (docs) and the real version floor is the
PLATFORM version 10.1.5, not the CLI's 9.0.4. Provider firewall is not
Cloudron's job (80/443 dropped, 22 open), rDNS belongs to Infomaniak, and
the setup wizard is where the subscription/restore happen - so install now,
stop before the wizard.
New box: 179.237.86.116 / 2001:1600:18:206::89, 4CPU/12GB/250GB,
Ubuntu 26.04 LTS, one free snapshot slot, reverse DNS unset on both
addresses. IPv6 exists, so the 18 AAAA records are repointed rather
than deleted.
Live zone inventory: 19 A + 18 AAAA records, all TTL 3600 (the lower values
seen on some answers are cache countdowns). The AAAA scope was understated
in the runbook - it is 18 hostnames, not 3. No CAA records, so no CA
restriction to update. The /var/lib/nextcloud host mount resolves to 3 MB of
regenerable thumbnails, so it is no longer an open unknown.
Verified against live DNS, federation and backup state (no privileged commands):
- IPv6: the zone carries AAAA records (2a02:4780:6e:83fd::1, Hostinger) that the plan
never mentioned. Switching A records only leaves IPv6 clients - including other
homeservers and mail senders - on the old box. Repoint or delete; decide pre-flight.
- TTL: the runbook said 760-1642s, which was a decrementing cache countdown, not the
zone TTL (3600s). Propagation is up to an hour, which is why the next item matters.
- "Leave the old box running read-only" was undefined and dangerous: during the TTL
window a still-serving old box silently collects Matrix messages, Gitea pushes, API
spend and mail into a database that gets thrown away. Now step 3: stop the apps after
the final backup; keep the machine powered for rollback only.
- Port 25 inbound was missing from the port list (mail delivery); 8448 noted as
intentionally closed - federation is delegated to 443 via the apex .well-known,
verified live.
- DMARC is p=reject pct=100: post-restore mail misalignment means discarded mail, not
junk. DKIM TXT must be verified against the restored key; test delivery to an external
mailbox, not just that the app accepts the send.
- Post-restore federation check now includes the apex .well-known (served by the
website app), without which federation breaks while matrix.inference.coop looks fine.
- Stale text removed: the once-daily backup schedule IS applied (00 00 23 * * *,
verified), and the backup space was enlarged - newest run healthy at 4.6 GB.
Pre-flight, ordered cutover, post-restore verification, rollback, and the list of what Cloudron's backup does not cover. Written from a live inventory of the server on 2026-10-29; open unknowns are marked rather than guessed.