Cloud Providers
Seven providers, seven genuinely different backups
Every integration calls the provider's own snapshot API, so a backup means something different on each — a whole Droplet, one Linode disk, an AMI and its EBS snapshots, one Azure snapshot per attached disk.
Dashboard
Backup health overview
Servers
12
Backup Jobs
28
Storage Destinations
3
Failed (24h)
0
Recent backup runs (24h)
View allBackup run
4m ago
Backup run
2h ago
Backup run
6h ago
Start with the provider you already run on
Each page covers the exact API call behind a run, what one connection reaches, how aged copies get deleted, and the quirks worth knowing before you set the schedule.
DigitalOcean
Authorize once with OAuth and never touch a token again. Each run produces the same whole-Droplet image the control panel makes — created by DigitalOcean, kept in your account.
Read moreHetzner Cloud
Hetzner API tokens are scoped to a single project, so the connection boundary is the project. Paste one token per project and every server inside it becomes schedulable.
Read moreVultr
Vultr API keys are IP-allowlisted by default, so a perfectly valid key fails until you allow the caller. VPS Snaps shows you the IP during setup instead of letting you debug a silent rejection.
Read moreLinode (Akamai)
Linode has no whole-instance snapshot API. VPS Snaps uses the Images API — independent, individually retainable images — and is explicit that each one captures a single disk.
Read moreAWS EC2
Deregistering an AMI does not delete the EBS snapshots behind it; AWS bills those forever. VPS Snaps reads the block device mappings before deregistering and deletes each one.
Read moreGoogle Compute Engine
A GCE machine image captures every disk on the instance in one self-contained resource. Delete it and nothing is left behind — the exact opposite of an AWS AMI.
Read moreMicrosoft Azure
Azure snapshots managed disks, not machines. A VM with an OS disk and two data disks produces three snapshots per run, taken together and pruned together — because a restore missing the data is worse than an obvious failure.
Read moreThe differences that change your setup
Four columns, seven rows, no marketing. If you are choosing where to run something, or wondering why your Linode job asked which disk to image, the answer is in here.
| Provider | Connect with | One backup is | One connection covers |
|---|---|---|---|
| DigitalOcean | OAuth, or a read/write API token | Droplet snapshot | Whole account, all regions |
| Hetzner Cloud | API token (Read & Write) | Server snapshot | One project per token |
| Vultr | API key (plus an IP allowlist entry) | Instance snapshot | Whole account, all regions |
| Linode (Akamai) | OAuth, or a personal access token | Disk image | Whole account; one disk per job |
| AWS EC2 | IAM access key + secret + region | AMI | One region per key |
| Google Compute Engine | Google OAuth + a GCP project ID | Machine image | One project, all zones |
| Microsoft Azure | Service principal (tenant, client, secret, subscription) | Managed disk snapshot | One subscription per connection |
Two rows deserve a second look. Linode images one disk rather than the whole instance, because its Backups API keeps a single destructive slot that retention windows cannot be built on. AWS EC2 is region-scoped, so instances in three regions mean three connections on one AWS account.
Everything above the API call is identical
The integrations differ. The product wrapped around them does not — which is the whole reason to run seven providers from one dashboard instead of seven control panels.
- The same schedule engine
- Hourly, daily, weekly, monthly, a fixed interval in minutes, or raw cron — evaluated in your timezone, not UTC. A Vultr job and an EC2 job are configured on identical screens.
- Retention that prunes on the provider's side
- Set how many days to keep. After every successful run, copies older than that window are deleted through the provider's own API, so the count of stored images stops growing instead of compounding.
- One run history, seven providers
- Status, duration, what triggered it, and the provider's ID for the image it created — recorded per run, in one list, whichever account the server lives in.
- Step-by-step logs, in the provider's words
- Each poll is logged as it happens, and a failure carries the provider's own error text rather than a generic message. You find out that Linode wanted Images scope, not that "the backup failed".
- The same 20-minute ceiling
- Every provider is polled every 20 seconds for up to 20 minutes. Past that the run is marked timed out rather than hanging indefinitely, so a stuck image shows up as a failure you can act on tonight instead of a job that never reports.
- Nothing installed on the server
- No agent, no cron entry, no SSH key, no package. A snapshot job is entirely API calls made from our side to your provider — the machine being backed up is never touched and never knows.
Snapshots are created inside your provider account and stay there. VPS Snaps stores the ID, the name and the outcome of the run — never the image. Every credential you hand over is sealed with AES-256-GCM before it reaches the database.
Backup Jobs
Automated backup schedules
postgres-main nightly
Last run 6h ago
web-01 snapshots
Last run 9h ago
api-prod volumes
Last run 4m ago
staging-db weekly
Last run 3d ago
Four things a provider snapshot is not
Snapshots are the fastest possible route back to a working server. They are also the backup type people most often over-trust, so here is where each of these seven stops being enough on its own.
They are not off-site from your provider
A snapshot lives in the same account as the server it came from. That protects you against a bad deploy, a botched upgrade or a deleted directory — not against losing the account itself. If that risk matters to you, run a database or file job alongside it, landing in an S3 bucket on a different provider entirely.
They are not application-consistent
None of the seven reboot or freeze the machine to image it, deliberately — that would mean downtime on every schedule. The image is crash-consistent: equivalent to pulling the power cable. A journalling filesystem recovers from that; a busy database may not, which is what pg_dump and mysqldump jobs are for.
They are not portable between providers
A Hetzner Image cannot boot on Vultr, and an AMI is not a machine image. Provider snapshots are the fastest way back to a working server on the same provider, and no help at all in moving off it. Portable copies come from the file, database and Docker job types, which produce plain tar.gz and .sql.gz in your own bucket.
They are not free of the provider's bill
Every provider here charges for the storage its snapshots occupy, on your account, separately from your VPS Snaps subscription. Automatic retention cleanup is the feature that keeps that line item flat rather than quietly climbing every night.
The complement to a snapshot is a portable copy in storage you control. Add a database backup, a file backup or a Docker backup on the same schedule, and the two failure modes stop overlapping. If the server has no inbound route at all, those three job types can run through the Agent instead of over SSH.
Your host isn't on the list
A snapshot integration needs the host to expose an API call that creates a snapshot. Some hosts don't have one — SSD Nodes will list and restore snapshots through its API but has no call that makes one, and InterServer's VPS API manages services and power state rather than disks. That rules out snapshot jobs on those hosts. It does not rule out backing the server up.
Both have a page of their own covering exactly what works and what does not: SSD Nodes and InterServer. The three job types below are what runs on either.
Database backups
pg_dump or mysqldump runs on the server over SSH and the output is streamed straight to your own S3 bucket, compressed, never touching a temporary file on either end. Application-consistent, which a snapshot never is.
File backups
Any set of paths, archived and streamed to your bucket on a schedule. A plain tar.gz you can open anywhere — including on a different host, which is the one thing a provider snapshot can never do.
Docker backups
Named volumes and container databases, dumped from inside the running containers. The same job whether Docker sits on a $5 VPS or a dedicated box in a rack you own.
All three need one thing from the host: SSH access to the server, which every host gives you. Add the machine under Servers with a key or a password, and it schedules, logs, retains and alerts exactly like a snapshot job. If the server has no inbound route at all — behind NAT, or with SSH firewalled off — the Agent runs the same three job types outbound instead.
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.
“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.”
Connect a provider and watch one run finish.
The first scheduled run is what proves your token has the right scope, your region is the one your instances are in, and your retention window does what you assumed. Better to learn that this week than during an incident.
No credit card required. Cancel anytime.