Security at BackUpScale

A backup service holds the copy of your data that’s supposed to survive the worst day of your company’s life. We think that obliges us to treat security as the product, not a feature of it.

Three principles run through everything below:

• Assume breach. Every layer is designed to limit what an attacker gets if the layer above it fails, including your own devices, and including ours.
• Least privilege, everywhere. People, machines, and automation each get the narrowest access that still does the job; nothing holds power it doesn’t need.
• Verify behaviour, not configuration. A protection that exists on paper but doesn’t actually block anything is worse than none, because it breeds false confidence. We continuously test what actually happens.

Your data: encrypted end to end

All backup data is encrypted on your devices before transmission, with keys that only you hold, and it stays encrypted at rest. There is no server-side decryption, no key escrow, and no recovery back door. If our storage were stolen outright, the thief would hold only ciphertext (data scrambled by encryption, unreadable without the key), and so would we.

Encryption doesn’t stop at our door, either. All traffic between the servers inside our platform is transparently encrypted as well, using WireGuard, so data in transit is protected even within our own network.

Access: keys, not passwords

The only way into the backup service is SSH (Secure Shell), the encrypted protocol that administrators worldwide use to manage servers over untrusted networks. The only accepted authentication is a cryptographic key; passwords are not supported, so they cannot be guessed, phished, stuffed, or reused.

Every authorized key is also bound to a forced command: a successful login runs exactly one thing, the backup transport with restrictive options applied, and nothing else. There is no shell to explore and no other tools to run. Port, agent and X11 forwarding are all denied.

Storage nothing can rewrite

Repositories are append-only by default. Your devices can add new snapshots; they cannot modify or delete existing ones. This is the property that makes backups worth having in a ransomware incident: even an attacker with total control of your servers, including your backup credentials, cannot corrupt or destroy the history that predates them.

Real-world maintenance (pruning old snapshots, retention clean-up) sometimes needs more than append. That capability is deliberately not available from your devices: it’s controlled from the BackUpScale dashboard, and the enforcement lives where connecting sessions cannot reach it. A compromised device cannot flip its own safety off.

We’re going further: on the roadmap is per-key access control, letting you run repository maintenance (such as pruning) from a separate, well-secured client of your choosing, while the keys on your everyday devices stay strictly append-only.

Tenant isolation, enforced below our code

Every customer’s data is walled off from every other’s, at two independent layers:

• The storage layer. Each customer gets their own storage credentials, cryptographically scoped to their own slice of storage. A request outside that scope isn’t rejected by our application logic; the storage provider itself refuses it. There is no shared credential to leak.
• The operating system. Each customer runs under their own system account with kernel-enforced ownership of their files. Isolation holds even against bugs in the layers above.

A network that denies by default

Inside our Kubernetes platform, no workload can talk to any other unless a network policy explicitly allows that exact connection. Every namespace starts from deny all, in both directions, and carries a short, reviewed allow-list: the dashboard may reach its own database, automation may reach the services it orchestrates, and nothing else.

The rule we care most about: the environment where customer backup sessions execute can reach exactly one internal service, the endpoint where sessions are logged. It cannot reach the database, the automation engine, the monitoring stack, or any other tenant of the platform. If a customer session were ever compromised, there is nowhere to move laterally to.

These aren’t aspirations. The denials are load-bearing, observed in our network flow logs, and asserted by automated tests; see the verification section below.

Least privilege operations

The automation that provisions, disables and deletes customer accounts runs under a service account scoped to precisely those operations. It holds no cluster-wide power, and there are no standing administrator credentials sitting in the pipeline. Internal dashboards and monitoring run under namespace-scoped roles rather than cluster-wide ones. When a credential doesn’t need to exist, we remove it entirely rather than guarding it.

Hardened runtime

The workloads themselves are built to offer an attacker as little as possible:

• Read-only root filesystems, with writes confined to explicit volumes.
• No privilege escalation, kernel capabilities dropped, and seccomp filtering on by default.
• Kubernetes Pod Security Standards enforced on our application namespaces from the moment they’re created.
• Pinned, verified versions across our images and infrastructure tooling; our supply chain doesn’t float on latest.

Even our blueprints are encrypted

The infrastructure-as-code state that describes our platform is client-side encrypted before it reaches any storage backend: the same standard we apply to your data, applied to our own.

Trust, but verify

Configuration describes intent; only behaviour is evidence. So we test behaviour:

• An automated end-to-end suite exercises the real service the way a customer does: provisioning, key management, real backups and restores over SSH, append-only enforcement, disabling and deletion.
• The same suite includes negative tests, probes asserting that the connections our segmentation must block are, in fact, blocked. A policy that silently stopped enforcing would fail the build.
• Independent monitoring watches the platform from both inside and outside, with an external heartbeat that alerts us if our own alerting goes quiet.

In the open

BackUpScale is an Open SaaS: a managed service built from open-source software. Everything that touches your unencrypted data (the backup client, the encryption, the repository format) is open source and independently auditable, and your backups stay restorable with standard tools whether or not we’re in the picture.

We give back to the ecosystem we build on: our public projects live at gitlab.com/backupscale, and we contribute improvements upstream to the projects we depend on.

Found something? We want to hear about it: contact us.

Curious how the architecture fits together? See the technical background, or get ready for our launch!