Snapshots

A snapshot is a full point-in-time copy of your VM’s disk: OS, apps, app data, configs. Stored encrypted, in the EU, away from the live VM.

​

Taking a snapshot

From the Snapshots tab on the instance page:

1. Click Take snapshot.
2. Optionally name it (e.g. “before db migration”). If you leave the name blank, we use a timestamp.
3. The snapshot runs in the background. Status: uploading → ready (or error on failure).

By default a snapshot is taken cold — the VM briefly powers off so the disk image is consistent, then comes back up. Choose hot mode to snapshot the live disk with no downtime, at the cost of possibly capturing in-flight writes. For a database-heavy install where you want hot mode but absolute consistency, stop the app first, snapshot, start it back up.

​

Managed backups (+20%)

Want backups without managing them yourself? On an instance’s Backups tab, click Enable backups. These are the cloud provider’s native daily backups, distinct from snapshots:

• The provider takes one daily and keeps the latest 7, rotating automatically.
• They cost +20% of the VM’s price, billed separately on your usage (so you can see it). The charge tracks the VM, so it adjusts automatically if you resize.
• They have their own quota (7 per instance), separate from snapshots, so they never crowd out the snapshots you take by hand.
• Restore rebuilds the VM from a chosen backup (everything after it is lost), same confirm as a snapshot restore.
• The first backup appears within ~24h of enabling, in a provider-chosen window.
• Backups are deleted if you delete the VM, and disabling backups deletes the existing ones. For a copy you keep long-term, take a snapshot instead.

Snapshots vs backups, in short: snapshots are on-demand, kept until you delete them, billed per-GB; managed backups are automatic-daily, provider-managed, +20% flat, and tied to the VM.

​

Restoring

Click Restore on any ready snapshot. The VM is rebuilt from the snapshot disk; everything that came after the snapshot is lost. There’s a confirm dialog with a “type the VM name to confirm” prompt to prevent accidents. Status flow: running → restoring → running. Takes 2–5 minutes depending on disk size.

​

Retention

Snapshots count toward your monthly storage charge — small (GB-scale) but non-zero.

​

Quotas

Default: up to 10 snapshots per organization, pooled across all your instances (manual, scheduled, and termination snapshots all count). Reach the limit and new snapshots are refused (manual) or skipped (scheduled) until you delete an old one. Org admins can raise the cap on request.

​

What snapshots cover

• ✅ OS, packages, system config
• ✅ Docker images, containers, networks
• ✅ App volumes (everything under /var/lib/docker/volumes)
• ✅ Anything else on the VM’s disk
• ❌ Block-storage volumes mounted under /mnt — back those up separately
• ❌ External resources (Cloudflare tunnel ID — recreated on restore; webhooks pointed at the old subdomain still work since subdomain is unchanged)
• ❌ App operations in flight (an install or upgrade running when the snapshot was taken may run again after restore)

​

Pricing

Snapshot storage is billed monthly per GB. The exact rate is shown on the Snapshots tab and on Billing → Top up. Small VMs typically cost a few cents/month for a couple of snapshots.

​

Best practices

• Snapshot before risky changes: schema migrations, big version bumps, manual edits to system files.
• Name them clearly — “pre upgrade to v2”, not “snap1”.
• Don’t rely on a single snapshot for archival — if you need permanent backups, also export app data (e.g. pg_dump) to off-VM storage on your own schedule.
• Test restores occasionally — a snapshot you never tested is a guess, not a backup.

​

Next