Priced on what you back up.
Not on how much of it there is.

The server limit counts machines you register under Servers — the ones VPS Snaps reaches over SSH to run database, Docker and file backups. One machine is one server no matter how many jobs point at it, so a database dump, a file archive and a Docker volume job on the same box is three backup jobs against one server. Provider snapshot jobs work from a connected provider account rather than a registered server, so they draw on your backup-job count instead.

It is a plan. There is no countdown, no expiry date and no card on file — the Free plan never asks for payment details. It exists because a single unbacked-up server is the most common way people lose data, and the barrier to fixing that should be nothing at all. The exact limits are on the Free card above; they are read live from the same database the app enforces them from.

Yes, from the Billing page in your dashboard. Upgrades and downgrades take effect immediately and Stripe prorates the difference against the period you have already paid for — you are charged or credited for the days remaining, not for a whole new month. Cancelling behaves differently on purpose: it takes effect at the end of the period you have already paid for rather than cutting you off the moment you click.

Limits are checked at the moment you create something new. Try to add a server, a backup job or a storage destination beyond your plan and you get a clear message naming the current count and the limit, and nothing is created. What is already there is left alone — we do not delete servers, jobs, destinations or anything in your bucket because a number moved. The same applies to backup frequency: a cadence your plan does not allow is refused when you save the job rather than silently downgraded at run time.

No, and there is no plan where we do. Provider snapshots are created through your provider's own API and live in your account. Database, Docker and file archives are uploaded by your own server straight into your S3-compatible bucket, and the agent does the same from inside your network. The data passes through our worker only when a server can't upload it itself, for Railway databases connected without admin access, and when Railway or Render will not run the dump in your account — held in memory, never written to disk, and no copy retained. What we store is metadata about the run — status, duration, byte size, MD5 checksum and the object key — so you can prove the backup happened and go find it.

No. You pay your object-storage provider directly for what your archives occupy, and your cloud provider separately for the snapshots it keeps in your account. That is why bring-your-own storage is cheaper in practice than a bundled allowance — you get the provider's own pricing, including zero-egress options like Cloudflare R2, instead of ours with a margin on top.

It is the fastest cadence a plan will accept when you save a job. Manual, daily, weekly and monthly schedules are available everywhere; the faster intervals are what the plans differ on. Retention is set per job, in days, so a nightly dump kept for a week and a weekly archive kept for a quarter can sit on the same server.

They are unaffected, because they were never ours to remove. Snapshots stay in your provider account and archives stay in your bucket under your keys, exactly where they were before you cancelled. Your subscription itself runs to the end of the period you have already paid for.