Vultr
The one setup step everybody misses
Connect a Vultr API key and VPS Snaps takes whole-instance snapshots on your schedule. The setup flow front-loads the access-control step that otherwise turns a two-minute job into an afternoon.
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
Connecting Vultr
API token
Paste a Vultr API key — and allow our IP in Vultr's Access Control, which VPS Snaps displays on the same screen.
In Vultr, go to Account → API and enable API access if it is not on already, then click Generate.
Under Access Control, either select Allow All IPv4 or add the specific IP address VPS Snaps shows you on the connect screen. Skip this and the next step fails.
Paste the key into VPS Snaps and run the connection test. If the allowlist is wrong you find out here, in a second, rather than at 3am when the first scheduled run fails.
What one connection reaches
One key reaches every Cloud Compute instance on the account, in every region. The constraint is not scope — it is which IP addresses are permitted to use the key at all.
What one run actually produces
No proprietary format and no copy on our side. VPS Snaps makes the same API call you could make yourself, and records what Vultr gave back.
Instance snapshot
POST /v2/snapshots { instance_id }- What it covers
- The whole Cloud Compute instance, as an ordinary Vultr snapshot you can deploy a new instance from at any time.
- How consistent it is, honestly
- Vultr takes it from the running instance with no reboot, so the image is crash-consistent. Nothing is installed on the server and nothing about the instance changes.
And what happens to the old ones
Snapshots belonging to runs older than your retention window are removed with DELETE /v2/snapshots/{id} after each successful run, so a frequent schedule settles at a constant number of stored snapshots instead of accumulating indefinitely.
Cleanup runs only after a run has already succeeded, so a failing schedule never deletes the last good copy you have. Every deletion is written into that run’s log with the date of the backup it removed.
VPS Snaps stores the ID and the name of each image it creates — never the image itself. Close your account and every copy already taken stays exactly where it is, in your Vultr account.
Vultr specifics worth knowing first
Every provider does this differently, and the differences are the part that bites at 3am. These are the ones that changed how the integration had to be built.
The allowlist is the whole difficulty
Vultr rejects API requests from any IP not on the key's access-control list, and the failure looks like an authentication problem rather than a network one. VPS Snaps prints the exact IP to allow next to the paste field and warns you in plain language that the connection test will fail without it.
There is no action object to poll
Unlike DigitalOcean and Hetzner, Vultr does not hand back a task to track. The snapshot resource carries its own status, so VPS Snaps polls the snapshot itself every 20 seconds for up to 20 minutes until it reports complete, and stores its ID against the run.
The key is account-wide, with no OAuth alternative
Vultr has no OAuth app flow and no refresh tokens, so the credential is a personal API key covering every instance on the account. VPS Snaps seals it with AES-256-GCM before storing it and never needs it anywhere but the worker — but it is worth knowing this is a broader credential than DigitalOcean's scoped token or the five-action IAM user AWS gets.
FAQs
Can’t find the answer you’re looking for? Reach out to our support team.
Can I use Allow All IPv4 instead of a single IP?
You can, and plenty of people do because the worker's address is one more thing to keep track of. Allowlisting the single IP VPS Snaps shows you is meaningfully tighter, though: the key is then useless to anyone who does not also control that host. Either choice works; only the narrower one is a security control.
Why did my key work yesterday and not today?
The overwhelmingly common cause is the access-control list, not the key. If the allowlist entry was removed, or the key was regenerated without re-adding the entry, every call fails at once and looks like a credential problem. Reconnecting the provider in VPS Snaps re-runs the same test and tells you which it is.
Do snapshots work on every Vultr product?
VPS Snaps lists and snapshots Cloud Compute instances through /v2. Other Vultr product lines — managed databases, object storage, Kubernetes — are not Cloud Compute instances and do not appear in the picker. For data living in those, a database or file backup job pointed at the endpoint is the route.
Running on more than one of these?
Connections are additive and independent — a Hetzner project and an AWS region live side by side in the same workspace, on the same schedules and the same run history.
A snapshot restores a instance on Vultr and nowhere else. For a copy you can carry anywhere, add a database, file or Docker job on the same instance — those write plain .tar.gz and .sql.gz into an S3-compatible bucket you own.
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.
“The biggest advantage for us is that VPS Snaps works with the infrastructure we already have instead of forcing us into a proprietary backup environment. Provider snapshots stay inside our cloud account, while database and file archives can go directly into our own bucket.”
Schedule your first Vultr backup tonight.
Connect the account, pick a instance, set a schedule and a retention window. The first run is what proves the credential has the scope it needs — a much better thing to discover on a quiet evening.
No credit card required. Cancel anytime.