Inside the snapshot-park lifecycle
Here is a bill nobody reads closely: a powered-off cloud VM still charges you. The provider keeps your CPU, RAM, and disk reserved. To actually stop paying, you have to destroy the machine — and that is only practical if bringing it back takes minutes and loses nothing.
comcon's answer is snapshot-park: treat the entire disk as the state.
What hibernate does
hibernate.sh --yes- User containers stop cleanly.
- The droplet powers off gracefully.
- The whole disk becomes a DigitalOcean snapshot; older snapshots are pruned to the newest two.
- The droplet is destroyed. Compute billing: $0/hr. Snapshot storage: ~$1–2/mo.
Because the disk is the state, there is nothing to reconstruct — no user tables to replay, no image pulls to repeat, no ordering bugs between a database restore and a file sync. The class of resume-fidelity bugs that plagues piecemeal backup schemes is eliminated by making the restore unit the whole machine.
What warmup does
warmup.shA fresh droplet boots from the snapshot, DNS updates (or a reserved IP was already pointing at it), and every container comes back via --restart always. Unix users, Podman images, Caddy routes, the identity database, home directories, logs — all byte-identical. Same URLs, same browser sessions, same Zellij layouts. A few minutes, not a rebuild.
The non-DigitalOcean path
On any other host — SSH server, local machine, WSL — the same commands take the portable route: rclone syncs /srv to S3-compatible object storage on park, and warmup pulls it back and recreates each container at its recorded ports. hibernate.sh --archive adds that off-site copy even on DigitalOcean, so the snapshot strategy and the portable backup are complementary, not either/or.
Why not just leave it running?
Because the whole point of a point-in-time engine is that the expensive part — the compute — exists only while it computes. Parked should mean parked: a couple of dollars of snapshot storage, zero dollars of reserved silicon, and a warm-up measured in minutes.