Data Processing Addendum

This Addendum applies where VPS Snaps processes personal data on your behalf in the course of providing the Service, and forms part of the Terms of Service.

For that data you are the controller and VPS Snaps is the processor. Where we process data about you as our own customer — your account record, your billing history — we act as controller, and our Privacy Policy governs that instead.

The subject matter is the provision of automated backup orchestration. Processing lasts for as long as your account is open, plus the deletion period in section 8.

The purpose is limited to operating the Service: scheduling and running backup jobs, connecting to the providers and storage destinations you configure, notifying you of outcomes, and enforcing the limits of your plan. We do not process your data for any other purpose, and we do not sell it.

Data subjects are you and any colleagues you invite into your workspace. The categories processed are:

• Account data — email address, name, hashed password, two-factor settings
• Connection credentials — provider API tokens, OAuth grants and SSH keys, encrypted at rest
• Infrastructure metadata — server names, IP addresses, region and storage bucket names
• Backup metadata — job names, schedules, run status, timestamps and archive sizes
• Billing data — subscription status and plan. Card details are handled by Stripe and never reach our systems

Backup data takes one of three paths, and the difference matters, so each is set out here rather than described in general terms.

• Backups that never leave your provider. Provider snapshots are created by your cloud provider inside your own account, and Kubernetes backups made with Velero are written by Velero from your cluster to its own storage location. We send the instruction and record the result; the contents never reach our systems.
• Backups written directly to your storage. Backups taken over SSH — files, databases, Docker volumes, and databases on a Coolify server — are uploaded by that server straight to your storage with short-lived links, and checked there. The VPS Snaps agent and the WordPress plugin upload the same way from your server or site. A Railway database, where Railway is connected with admin access, is dumped by a short-lived service in your own Railway project, which uploads it straight to your storage, and a Render database is dumped by a job in your own Render workspace, which does the same. Kubernetes manifests, where the cluster lets VPS Snaps run a short-lived Job in it, are read by that Job inside the cluster and uploaded straight to your storage. The contents never reach our systems during the backup, and we hold only metadata describing it: when it ran, whether it succeeded, how large it was.
• Backups that stream through us. Kubernetes manifests where the cluster does not let VPS Snaps run a Job in it, which our worker reads (Secrets included) through the cluster's API, and managed databases on Railway where it is connected without admin access, where the export itself runs on our infrastructure because we have nowhere of yours to run it, and DNS zones on Cloudflare, which our worker reads through Cloudflare's API for the same reason, are streamed by our worker to your storage as they are produced. The data is held in the worker's memory only as it passes; it is never written to disk here and never retained.

A Railway or Render dump runs on our infrastructure instead, on the third path, when the platform will not run it in your account — a plan limit, or no payment method on a Render workspace — and the run's log says so. A backup taken over SSH takes the third path only when the server cannot upload it itself — it lacks curl or another standard tool, or your storage refuses it — in which case that run streams through our worker instead, in memory only, and the run's log says so.

Restoring a backup does not pass it through us. A restore started from the dashboard, a scheduled test restore, a recovery server built from backups and moving an application to a new server each have the server being restored download the backup straight from your storage with a short-lived link. Only if that server cannot — it has neither curl nor wget, or your storage refuses it — is the backup streamed through our worker instead, and the restore's log says so.

Restoring a Railway database works the same way: where Railway is connected with admin access, a short-lived service in your own Railway project downloads the backup straight from your storage and restores it there; otherwise, or if Railway will not run it, the backup is restored through our worker and the restore's log says so. Whenever a backup or restore takes our worker instead of the direct path, you are also told, by email or wherever you send alerts, with the reason — for a job, once and then at most weekly while it keeps happening.

A Render database is restored, and test-restored, by a job in your own Render workspace that downloads the backup straight from your storage; there is no path through our worker for it. A DNS zone is restored by our worker, which reads the backup from your storage, compares it with the zone and writes back through Cloudflare's API only the records that differ. “Verify now” has the job's server download and check the backup, or, with no server to do it, asks your storage whether it is unchanged, without downloading it. Downloading a backup yourself goes straight to the file in your storage.

Where backup data takes the first or second path and contains personal data, it does not reach us and VPS Snaps is not a processor of it. Where it takes the third, or is read through us as described above, we are a processor of it for the duration of the transfer only.

Which path a backup job takes is shown on the job itself, and follows from what is being backed up rather than from any setting.

We process personal data only on your documented instructions, which are given through your configuration of the Service and through this Addendum, except where law requires otherwise — in which case we will tell you before processing, unless that law forbids it.

Everyone with access to personal data is bound by confidentiality. We maintain technical and organisational measures appropriate to the risk, described in full on the Security page, including AES-256-GCM encryption of credentials at rest, bcrypt password hashing, TLS in transit, optional two-factor authentication, and workspace-scoped access control.

We will notify you without undue delay after becoming aware of a personal data breach affecting your data, with the information you need to meet your own notification obligations.

You authorise the subprocessors below. Each is bound by data protection terms no less protective than this Addendum.

The providers and storage destinations you connect — DigitalOcean, Hetzner, Vultr, Linode, AWS, Google Cloud, Azure, Railway, Render, any S3-compatible storage, and your own Google Drive, Box, Dropbox or OneDrive — are not our subprocessors. You hold those relationships directly; we act on them using the credentials you supply.

We will give notice before adding or replacing a subprocessor, and you may object on reasonable data protection grounds.

You can delete your account at any time from the dashboard, under Settings → Delete account; a paid plan is cancelled under Billing first. For a copy of the data we hold about your account, contact us. On termination we delete personal data within 30 days, except where law requires us to keep it — billing records, for example, carry statutory retention periods.

A free account with no sign-in and no successful backup for 60 days is deleted in the same way, after we email the account owner at 14, 30 and 45 days. Paid accounts are never deleted for inactivity.

After deletion we keep, as controller, a record of the deleted account with no name, email address, IP address, credential or backup data in it, together with keyed one-way hashes used to keep the free plan to one account per person, as our Privacy Policy describes.

Deleting your VPS Snaps account does not touch backups already written to your own storage. Those remain entirely yours and are unaffected.

Taking into account the nature of the processing, we will assist you in responding to requests to exercise rights of access, rectification, erasure, restriction, portability and objection, and in meeting your obligations on security, breach notification and impact assessments. Most requests can be satisfied directly from the dashboard; for anything else, contact us.

Personal data is stored in the United States, and the subprocessors above are predominantly US-based. Encrypted copies of our database held with Google may be stored in its data centres elsewhere, and Cloudflare's network is global. Where data is transferred out of the EEA or UK, that transfer relies on the European Commission's Standard Contractual Clauses, incorporated into this Addendum by reference, together with the UK Addendum where the UK GDPR applies.

On reasonable written notice, and no more than once a year unless a regulator requires otherwise, we will make available the information necessary to demonstrate compliance with this Addendum. We do not currently hold a SOC 2 or ISO 27001 report; we say so plainly on the Security page rather than leave it to be discovered during procurement.

This Addendum takes effect on your acceptance of the Terms of Service and needs no separate signature. If your procurement process requires a countersigned copy, email [email protected] and we will arrange it.