Security

We never store your backups. There is no bucket here holding your data. Backups land in storage you own and control, and that is the single biggest thing separating our risk profile from a service that keeps your backups for you. We are not a place where your data sits, so we are not a place where it can be taken from.

Most backups never touch us at all. A provider snapshot happens entirely inside your cloud account. A backup taken over SSH — files, a database, Docker volumes — is produced on your server and uploaded by that server straight to your storage, with short-lived links we sign for it; we send the instructions and check the result. The VPS Snaps agent and the WordPress plugin upload the same way. Box needs each backup as one finished file, so for Box the server writes it to its own disk first and uploads it with a token Box limits to that job's folder for about an hour. Dropbox takes it as it streams, uploaded with the destination's own token, which reaches only VPS Snaps' app folder in your Dropbox and lasts at most 4 hours. Restores go the other way round: the server being restored downloads the backup straight from your storage, and “Verify now” has your server check it there. If we were breached tomorrow, none of that data would be part of it.

Some backups do pass through us, and that is worth stating plainly rather than burying. A Railway database connected without admin access has nowhere of yours to run the export, so it runs on our worker and streams to your storage; with admin access it runs in your own Railway project instead, and a Render database runs as a job in your own Render workspace, each uploading from there. When the platform will not run it, that run goes through our worker and its log says so. A server that cannot upload for itself — it lacks curl, say, or your storage refuses it — has that run streamed through our worker instead, and the run's log says so — and you are told, with the reason, so it can be fixed. In every case the data is held in memory only while it passes: it is never written to our disks and never retained. Every job shows which way its data goes. That is also why a run that passes through us can go to Box only up to 64 MB: Box needs the whole file before it takes it, and we will not write your data to our disk to make one. Dropbox takes a backup as it streams, so it has no such limit.

To do its job, VPS Snaps holds provider API tokens and SSH keys. These are the most sensitive things we store, and they are treated accordingly.

• Every credential is encrypted at rest with AES-256-GCM, an authenticated cipher — meaning tampering with the stored ciphertext is detected rather than silently decrypted into something else.
• Each value is encrypted with its own random initialisation vector, so identical secrets do not produce identical ciphertext.
• The encryption key lives in the server environment, never in the database. A database dump on its own does not decrypt anything.
• Credentials are decrypted only in memory, at the moment a job runs, and are never written to logs.

Where a provider offers it, connecting is a sign-in rather than a pasted key. DigitalOcean, Linode, Google Compute Engine and Railway use OAuth, as do Cloudflare, Google Drive, Box and Dropbox. Microsoft Azure uses a Microsoft sign-in once, to give our own app a role on the subscription you choose; after that, nothing of yours is kept but the tenant and subscription IDs. Either way, there is no key for you to create and copy. Google Compute Engine can also connect keylessly, through Workload Identity Federation: VPS Snaps acts as a service account in your project and holds no secret of yours at all, and deleting one pool revokes it.

• Passwords are hashed with bcrypt. We cannot read your password, and neither can anyone who obtains the database.
• Two-factor authentication is available using any TOTP app. Recovery codes are themselves hashed, not stored in readable form.
• Sessions are signed tokens with a limited lifetime. The session cookie carries no personal data.
• Every query is scoped to your workspace. Data belonging to one workspace is not reachable from another.
• Sign-up is protected by Cloudflare Turnstile to keep automated abuse off the platform.

• VPS Snaps runs on a dedicated server in DigitalOcean's New York region. It is not shared with other tenants or applications.
• All traffic is served over TLS. The database is not exposed to the public internet.
• Automated daily checks report failed backups, process restarts and disk pressure, so problems surface without waiting for a customer to notice.

Security pages are usually a list of reassurances. It is more useful to be straight about the boundaries, so you can judge whether this fits your requirements:

• We do not hold a SOC 2, ISO 27001 or comparable certification. VPS Snaps is a young product and has not been through a formal audit.
• We have not commissioned an external penetration test. If you need one before adopting a vendor, tell us — that is a reasonable requirement and worth knowing about.
• We do not offer a contractual uptime SLA. If your use case depends on one, get in touch before subscribing rather than after.

If any of this changes, this page changes with it. We would rather lose a sale than win one on a claim we cannot support. Our Trust Center has every commitment in one place, including our subprocessors and where we are on SOC 2 and ISO 27001.

Two things materially reduce your exposure, and both are in your hands:

• Scope the credentials you give us. Where your provider supports restricted tokens or IAM policies, grant only snapshot and storage permissions rather than full account access.
• Turn on two-factor authentication. Your VPS Snaps account can reach your infrastructure, which makes it worth protecting as carefully as the infrastructure itself.

If you believe you have found a security issue, email [email protected] with enough detail to reproduce it. Reports are read by a person, not a queue, and you will get an acknowledgement.

Please give us a reasonable opportunity to fix an issue before disclosing it publicly. We will not pursue legal action against anyone who reports a vulnerability in good faith and without accessing or modifying other customers' data.