Encryption
Your files are encrypted on your device by Restic before any data leaves your network. We never see, store, or transmit your encryption key - we see ciphertext only.
KEY DERIVATION
scrypt (memory-hard)
✓
Key never leaves your device. Lose your password and your data is unrecoverable - including by us. That's not a bug; that's the contract.
Transport
All data in transit travels over HTTPS to your vault's REST endpoint, terminated at a hardened edge with a valid TLS certificate, authenticated with a per-vault token shown in the portal once. Even if intercepted, the payload is already Restic-encrypted ciphertext - the transport layer is defense in depth, not the primary boundary.
The vault runs no SSH service and exposes no shell. Verify it yourself:
SERVERCRATE // VERIFY
nmap
$nmap -p 22,443 your-vault-id.vault.servercrate.net
22/tcp closed ssh
443/tcp open https
Quantum resistance
Your backup data is sealed on your device with AES-256 before it ever reaches the wire, under a key we never see and never store. AES-256 has no practical quantum attack. The portal and vault transport go further, negotiating a hybrid post-quantum key exchange (X25519MLKEM768, the NIST FIPS 203 lattice KEM paired with classical X25519), so a connection recorded today cannot be replayed against a future quantum computer.
Don't take our word for it. Run this yourself:
SERVERCRATE // VERIFY
openssl 3.5+
$openssl s_client -connect portal.servercrate.net:443 -groups X25519MLKEM768 </dev/null | grep "Negotiated"
Negotiated TLS1.3 group: X25519MLKEM768
Storage isolation
Every customer gets a dedicated ZFS dataset, isolated at the filesystem level. Each vault runs in its own LXC container running only the Restic REST server, scoped to its own dataset.
ISOLATION UNIT
1 ZFS dataset + LXC per vault
INTEGRITY
Checksummed every block
✓
Silent corruption is caught and self-healed on read where pool topology allows it. Your backup target won't quietly rot.
What we log
LOGGED
HTTPS metadata (IP, vault ID, bytes) - 30d
Portal auth events (login, logout, password change) - 90d
Stripe / PayPal / BTCPay billing events - per tax-record req.
Application errors, anonymized stack traces only - 14d
✓ NEVER LOGGED
- file names, file paths, snapshot contents, restore content. Restic's wire protocol doesn't expose it to us and we've made no effort to derive it.
Threat model
INFRA COMPROMISE (external or insider)
Attacker gets ciphertext + connection metadata. No key access exists to take.
LEGAL DEMAND OR WARRANT
We hand over what we have: ciphertext + metadata. We cannot hand over decrypted data because we don't have it.
OUT OF SCOPE
A compromised endpoint that exfiltrates your repository password. That boundary is yours - use a hardware-backed password manager.
Infrastructure
We are not a multi-region cloud provider, and we don't pretend to be one. Treat ServerCrate as one leg of a 3-2-1 strategy, not the whole thing.
LOCATION
Los Angeles, owned hardware
STACK
Debian 12 / Proxmox VE / OpenZFS
HONEST STATUS
- no SOC 2 / ISO 27001 yet. Business customers doing their own review: contact us, no NDA required.
Account security
✓ Password hashing - Argon2id, legacy bcrypt auto-rehashed
✓ Two-factor (TOTP) - available on every account
✓ Sessions - HTTPOnly cookies, separate CSRF token, IP/UA change detection
✓ Rate limiting - per-account and per-IP on login, reset, chat
✓ Email verification required before vault provisioning
Incident response
For a confirmed security incident affecting customer data or availability, our commitment:
Direct
Email to all affected customers - what was accessed, what was not
14d
Post-incident report - root cause, timeline, mitigations. Cooperation with your compliance/legal team as needed
What we don't have yet
The honest version, for evaluation purposes.
No SOC 2, no third-party audit
Too small and too early to pay for one meaningfully. When revenue supports it, we will commission one.
No formal bug bounty
Good-faith reports acknowledged within 48h and credited publicly. No cash bounties yet.
Single-site deployment
All vaults in one Los Angeles location. Treat us as one leg of your 3-2-1, not the whole thing.
Provider continuity answer
Your repo is a self-contained, open Restic format. If we disappeared tomorrow, you'd restore it against any Restic-compatible backend - REST, S3, SFTP, local disk.
Responsible disclosure
Encrypt sensitive reports with our PGP public key (fingerprint AAB2 A06A E5F9 187B 9565 4584 C1B0 7D4D F41C B15F).
Security researchers: please email security@servercrate.net with findings. We aim to acknowledge within 48 hours and provide a remediation timeline within 7 days.
We don't yet operate a formal bounty program - we're a small operation - but verified vulnerability reports get public credit (with consent), free Pro plan time, and our genuine thanks. Please don't run automated scanners against production.
What you should do
✓ Save your repository password in a real password manager - not a text file
✓ Enable TOTP on your portal account
✓ Test a restore at least once - an untested backup is a hope
✓ Schedule restic check to verify repository integrity
✓ Keep your vault token out of shell history and world-readable scripts
Questions about anything on this page? Email security@servercrate.net. We answer security questions seriously and quickly.
What "zero-knowledge" actually means in practice
The term gets misused in backup marketing - "server-side encryption with customer-managed keys" or "encrypted at rest" are real features, but they are not zero-knowledge.
Zero-knowledge, as it applies to ServerCrate: the cryptographic keys that decrypt your data never exist on our infrastructure. They're generated by Restic on your device during restic init, derived from a password we never see. Even reading the key files in your vault gives an attacker nothing without that password.
If a court compels us to hand over your vault data, we hand over encrypted blobs - worthless without a password we do not have and cannot produce. The same guarantee Signal provides for messages and Bitwarden provides for passwords, applied to backup data.
Why this architecture matters more in 2026
Two things changed in the last five years that made client-side encryption a baseline requirement, not a nice-to-have:
RANSOMWARE TARGETS BACKUPS NOW
Crypto-extortion groups actively seek and destroy backup infrastructure before detonating the payload. A provider whose operators could technically decrypt your data is one bribed or phished employee away. Zero-knowledge cannot be leveraged that way - there is nothing to leak.
DATA BROKER LAW IS PATCHWORK
Storage providers under unclear privacy regimes have been quietly indexed, scanned, or handed over under orders they aren't allowed to disclose. Your key on your device is the only reliable guarantee your data stays out of a training corpus or a subpoena response.
Operational security you should also handle
Zero-knowledge at the service level only gets you so far. These operational details determine whether your encrypted backup actually stays private:
Where RESTIC_PASSWORD lives on disk
Keep it in a file readable only by the backup user. chmod 600 /etc/restic/env, loaded via a systemd EnvironmentFile=.
Your backup source machine is as sensitive as the backups
Root on the source means plaintext access already. What Restic over HTTPS doesn't stop by default is altering the offsite copy - consider append-only or push-from-isolated-host for high-value data.
Rotate RESTIC_PASSWORD periodically
Restic supports multiple keys per repo - add, verify, remove the old one with restic key add/remove, no re-encryption needed.
Keep your vault token separate from admin credentials
If an admin machine is compromised, the vault token shouldn't be sitting in the same place.