
Sixty containers on one server
One bare-metal box runs dozens to hundreds of Hoody containers. KSM and BTRFS dedup make the marginal cost near zero.
Add a hoody-cron entry that fires five minutes before the 03:00 migration job. It curls the snapshots URL and tags the artifact as the rollback point. If the migration fails, you restore in 30 seconds with a single PATCH.
{ "name": "snap-2026-05-04", "alias": "rollback-point", "created_at": "02:55:08Z" }
ONE NIGHT, FIVE EVENTS, ZERO PAGES
The cron service schedules a curl. The snapshots service does the freezing. Neither knows about the migration job that runs five minutes later, and that's the whole point.
# register the recurring snapshot job (one-time setup) curl -X POST \ cron.containers.hoody.com/users/root/entries \ -H "Content-Type: application/json" \ -d '{ "schedule": "55 2 * * *", "command": "curl -X POST $SNAP_URL -d '{\"alias\":\"rollback-point\"}'", "comment": "pre-migration snapshot" }'
# what the cron entry curls every night at 02:55 UTC curl -X POST \ api.hoody.com/api/v1/containers/$ID/snapshots \ -H "Authorization: Bearer $TOKEN" \ -d '{"alias": "rollback-point", "expiry": 7}' # response from the snapshots service → 200 OK · snap-2026-05-04 created in 8s
The cron entry is a row in a Postgres table somewhere in Hoody. The snapshots URL writes a content-addressed blob to the container's storage backend. Both are durable, both are versioned, and neither requires a long-lived process on your laptop.
Four moments, four URLs, and a five-minute gap between the safety net and the change. The migration finishes before most engineers' first alarm.
If step 03 fails, the rollback is `PATCH /snapshots/snap-2026-05-04` and you are back at 02:55:08Z. The audit timeline above is the same data, served as JSON.
Not the snapshot itself. The shape: a backup that exists before the change, addressed by a URL, with a name that includes today's date.
Most outage post-mortems start with "we forgot to take a backup." When the backup is a cron entry, you can't forget. The 02:55 snapshot is the runbook's first sentence, written in advance.
Restoring snap-2026-05-04 is a single HTTP call against api.hoody.com. The container reverts to its 02:55:08Z state in under 30 seconds. No ticket, no on-call escalation, no "who has the AWS console."
Snapshots are content-addressed and stored as deltas. A 412 MB delta on top of an unchanged base disk is what you pay for, and only for the 7-day retention window. Successful migrations leave behind almost no footprint.
What the runbook used to look like, and what it collapses into when the snapshot is named for today's date and addressable as a URL.
The new column on the right is not a tool. It is one sentence in a runbook. The sentence does not start with "first, take a backup" because the backup already exists.
The rollback plan is a URL you scheduled to exist.
The cargo-cult around pre-migration backups. Schedule the snapshot, sleep with the migration window.
The rollback plan is a URL you scheduled to exist.