VPS Snaps

VPS Snapshots

Snapshots that never leave your account

Pick a server, pick a schedule, and VPS Snaps calls your provider’s own snapshot API on time — creating an image inside your account that stays restorable from your provider’s console whether or not we are still in the picture.

Back up your first server free, forever. No credit card required.

We only use your email to create your account. See our Privacy Policy.

What actually happens when a run fires

Four steps, identical across all seven providers. Only the API call in step two changes.

All we keep is the snapshot ID, the name we gave it, and the outcome of the run. The image is never copied to us, never passes through us, and does not depend on us to stay where it is.

  1. The schedule fires, nothing touches your server

    A snapshot job holds no SSH key and installs no agent. When its next run is due, the request goes from us to your provider’s API — the machine being imaged is never contacted and never knows the backup happened.

  2. One API call creates the image in your account

    A DigitalOcean snapshot action, a Hetzner create_image, a Vultr snapshot, a Linode disk image, an EC2 CreateImage, a GCE machine image. The artifact is created inside the account the credentials belong to, and it stays there.

  3. We poll every 20 seconds until it lands

    Providers report image creation asynchronously, so the run stays open and polls for up to 20 minutes, writing each status change to the log as it happens. Past that ceiling the run is marked timed out rather than hanging forever.

  4. The ID is recorded, then retention runs

    On success we store the provider’s ID for the image and the name we gave it — not the image itself. Retention then prunes copies older than your window through the same API, so the stored count stops growing instead of compounding nightly.

What the run log looks like
Starting DigitalOcean snapshot for droplet 411829366
Snapshot action created: action ID 1__________, status: in-progress
Snapshot status: in-progress (attempt 1)
Snapshot status: in-progress (attempt 2)
Snapshot status: completed (attempt 3)
Snapshot completed successfully: vpssnaps-411829366-1756869606118
Deleted old snapshot 168________ from 2026-08-27 (retention policy)

Seven providers, seven different artifacts

“Take a snapshot” means something materially different on each one. A job is configured on the same screen either way — but what you get back is not the same object.

ProviderOne run producesConnect with
DigitalOceanDroplet snapshotOAuth, or a read/write API token
Hetzner CloudServer snapshotAPI token (Read & Write)
VultrInstance snapshotAPI key (plus an IP allowlist entry)
Linode (Akamai)Disk imageOAuth, or a personal access token
AWS EC2AMIIAM access key + secret + region
Google Compute EngineMachine imageGoogle OAuth + a GCP project ID
Microsoft AzureManaged disk snapshotService principal (tenant, client, secret, subscription)

Credentials are sealed with AES-256-GCM before they reach our database and are never shown again after you save them. Vultr keys are IP-allowlisted by default, so setup shows you the address to allow rather than letting the key fail silently at 2am. The full comparison — including what a single connection reaches on each provider — is on the cloud providers page.

The schedule is yours, the cleanup is automatic

Hourly, daily, weekly, monthly, a fixed interval in minutes, or raw cron — evaluated in your timezone rather than UTC, so a 02:00 job stays at 02:00 across a DST change instead of drifting an hour.

  • Retention prunes on their side. Set a window in days. After every successful run, images older than that are deleted through the provider’s own API — the line item on your cloud bill stays flat instead of climbing every night.

  • On EC2, the EBS snapshots go too. Deregistering an AMI leaves the volumes behind it billing quietly forever. We read them off the image first and delete those as well — the usual source of storage nobody remembers paying for.

  • Every step is in the log. Each poll is timestamped as it happens, and a failure carries the provider’s own error text — so you learn that Linode wanted Images scope, not that “the backup failed”.

Four things a snapshot job will not do

Worth knowing before you set the schedule, rather than during the incident you set it for.

One job images one machine

A snapshot job is bound to a single instance, so ten servers means ten jobs on ten schedules. On Linode it is narrower still: a job captures one disk, the boot disk is detected for you, and a second data disk needs its own job or a file backup beside it.

Twenty minutes is a hard ceiling

Every provider is polled for up to 20 minutes, then the run fails as timed out. That is a deliberate trade — a stuck image surfaces as a failure you can act on tonight rather than a job that quietly never reports. Large multi-volume EC2 instances are where this bites first.

Retention only prunes what we created

The cleanup pass deletes images recorded against this job’s own runs. Snapshots you took by hand in your provider’s console, or ones created before the job existed, are left exactly where they are — we do not sweep an account we did not fill.

Restoring happens in your provider’s console

Database and file backups can be restored from the dashboard, but a provider snapshot cannot — rebuilding from an image is your provider’s own operation, with your provider’s guarantees, and it works whether or not this subscription is still active. We record which image to reach for; you reach for it there.

There is a second, more fundamental set of caveats — an image is crash-consistent rather than application-consistent, it lives in the same account as the server it came from, and it cannot boot on a different provider. Four things a provider snapshot is not covers those in full, and they are the reason most people run a database or file job on the same schedule.

What people run alongside it

A snapshot is the fastest route back to a working server. These are the job types that cover what it deliberately does not.

Cloud providers

The seven integrations side by side — how each one connects, what a single connection reaches, and where the artifacts genuinely differ.

Read more

Database backups

pg_dump and mysqldump over SSH, for the consistent copy a crash-consistent image cannot give you on a busy database.

Read more

File backups

A portable tar.gz in a bucket you own — the off-account complement to an image that lives in the same place as the server.

Read more

If a server has no inbound route at all, those SSH-based job types can run through the Agent instead — though snapshot jobs never needed one, since they only ever talk to your provider’s API.

Powerful features to give you peace of mind

Rest easy knowing your data and your reputation are safe.

Bring your own storage
Backups land in your own S3-compatible bucket — Backblaze B2, Wasabi, Cloudflare R2, or plain S3. You hold the keys and the data.
Snapshots stay with your provider
Provider snapshots are created through the provider's own API and never leave your account. We store the snapshot ID, not the image.
Seven providers, one dashboard
DigitalOcean, Hetzner, Vultr, Linode, AWS EC2, Google Compute Engine and Microsoft Azure — scheduled and reviewed from the same place.
Schedules that fit your traffic
Hourly, daily, weekly, monthly, or a fixed interval in minutes — anchored to your timezone, so a 02:00 job stays at 02:00 across a DST change.
Retention that prunes itself
Set how many days to keep. Older snapshots and archives are cleaned up after each successful run, so storage bills stay flat.
Step-by-step run logs
Every run records what it did, in order, with warnings and errors kept in place — so a failure tells you which step broke.
Complete run history
Status, duration, byte size, and what triggered each run, kept per job. Proof the backup ran, long after the night it ran.
Checksummed on upload
Every archive is hashed as it streams to your bucket and the checksum is stored with the run, so you can verify what landed.
Run on demand
Trigger any job by hand before a migration or a risky deploy, without touching its schedule or its retention window.
Alerts on five channels
Email plus Slack, Microsoft Teams, Google Chat, and Discord — on success, on failure, and on a job that missed its schedule entirely.
Encrypted credentials
SSH keys, database passwords, and storage secrets are sealed with AES-256-GCM before they touch the database.
Team access with roles
Invite your team into a shared workspace as owner, admin, or member, so backups outlive whoever set them up.
View all features
Alex Morgan
“VPS Snaps gave us one place to manage backups across DigitalOcean, AWS, and a few standalone servers. We can schedule provider snapshots, database dumps, and file backups without maintaining a bunch of separate scripts, and the run logs make it easy to confirm everything actually completed.”
Alex MorganDevOps Engineer

Connect a provider and watch one run finish.

The first scheduled run is what proves your token has the right scope and your retention window does what you assumed. Snapshot jobs are on the Free plan — no card, no agent, nothing to install on the server.

No credit card required. Cancel anytime.