The full security model.

Encryption

Your files are encrypted on your device by Restic before any data leaves your network. Restic uses authenticated encryption with AES-256 in counter mode and Poly1305 for integrity. The encryption key is derived from your repository password using scrypt - a memory-hard KDF designed to resist GPU and ASIC attacks.

We never see, store, or transmit your encryption key. We see ciphertext only. If you lose your password, your data is unrecoverable - including by us. That's not a bug; that's the contract.

Transport

All data in transit travels over SFTP (SSH File Transfer Protocol) using OpenSSH. Each vault has a unique SSH host key (no shared host keys across customers). Connections are authenticated with username + password generated at provision time and shown in the portal once.

Even if the SFTP connection were intercepted, all transferred data is already Restic-encrypted ciphertext. The SFTP layer is defense in depth, not the primary boundary.

Quantum resistance

Your backup data is sealed before it ever reaches the wire. Restic encrypts every chunk on your machine with AES-256, under a key generated at full entropy, shown to you once, and never stored on our systems. AES-256 has no practical quantum attack - Grover's algorithm only halves its effective strength, which leaves it far out of reach - so traffic an adversary records today to decrypt later, once a quantum computer exists, stays meaningless ciphertext without your key, whether the link is classical or not. The encryption that protects your data runs on your side, before transport, beyond the reach of both classical and quantum attackers.

The account portal goes one step further at the transport layer. Connections to portal.servercrate.net negotiate a hybrid post-quantum key exchange, X25519MLKEM768, pairing classical X25519 with ML-KEM-768 (the lattice KEM standardized by NIST as FIPS 203). Traffic an observer records today cannot be replayed against a future quantum computer to recover the session, because breaking the handshake means defeating both the classical and the post-quantum half. The vault transport carries the same protection one layer down: SFTP rides OpenSSH, and that SSH session negotiates mlkem768x25519-sha256, the same ML-KEM-768 hybridized with X25519 inside the SSH key exchange. In either case your backup data is already AES-256 ciphertext before it reaches any link, so its confidentiality never rested on the transport.

You can verify the portal's key exchange yourself with OpenSSL 3.5 or newer:

openssl s_client -connect portal.servercrate.net:443 -groups X25519MLKEM768 </dev/null | grep "Negotiated TLS1.3 group"

Storage isolation

Every customer gets a dedicated ZFS dataset on our storage pool. Datasets are isolated at the filesystem level - they cannot read each other's data, share inodes, or escape their boundaries. Each vault runs in its own LXC container with a chrooted SFTP user that cannot navigate above its dataset.

ZFS provides end-to-end data integrity via cryptographic checksums on every block read and write. If a disk silently corrupts a sector, ZFS detects it on the next read and (with the right pool topology) self-heals from redundancy. Your backup target won't quietly rot.

What we log

• SFTP connection metadata (timestamp, source IP, vault ID, bytes transferred). Retained 30 days.
• Portal authentication events (login, logout, password change). Retained 90 days.
• Stripe billing events (charges, subscription changes). Retained per Stripe and tax-record requirements.
• PayPal capture events (created, completed, refunded, denied). Self-hosted handler verifies PayPal-signed webhooks. Retained per tax-record requirements.
• BTCPay invoice events (created, settled, expired) for customers who pay with Bitcoin. Self-hosted on our infrastructure - no third-party payment processor sees the transaction. Retained for tax-record requirements only.
• Application errors (anonymized stack traces, no customer data). Retained 14 days.

We do not log file names, file paths, snapshot contents, restore content, or anything that could reveal what's inside your vault. Restic's wire protocol doesn't expose that information to us, and we've made no effort to derive it.

Threat model

The system is designed against three threat classes:

• External attacker compromising ServerCrate infrastructure: Attacker gets ciphertext blobs and connection metadata. Cannot decrypt without your repository password.
• Insider threat (operator-side): Same as external. We have no key access. Logs do not contain decryptable data.
• Legal demand or warrant: We can hand over what we have - ciphertext blobs and connection metadata. We cannot hand over decrypted data because we don't have it.

The system is not designed against an attacker who has compromised your machine and exfiltrated your repository password. That's a separate boundary - your endpoint security is your responsibility. We recommend storing your Restic password in a hardware-backed password manager.

Infrastructure

Storage runs on owned hardware in a single Los Angeles location with redundant power and a business-grade network uplink. We are not a multi-region cloud provider, and we don't pretend to be one. For homelab and small-team use cases this is the right tradeoff between cost and reliability; for workloads that require geographic redundancy you should treat ServerCrate as one leg of a 3-2-1 strategy, not the whole thing.

Operating systems are Debian 12 stable on Proxmox VE host nodes. ZFS is the OpenZFS upstream. All systems are CrowdSec-enrolled with nftables-based bouncing for IP-level abuse mitigation.

We do not currently hold SOC 2, ISO 27001, or any other third-party audit attestation. For business customers conducting their own architecture review or DPIA, contact us and we'll walk through specifics directly - no NDA required, no compliance theatre.

Account security

• Password hashing: Argon2id (memory-hard) for all new and changed passwords; any legacy bcrypt hashes are transparently re-hashed to Argon2id on next login.
• Two-factor authentication (TOTP): available on every account, optional but strongly recommended.
• Session management: HTTPOnly cookies, separate CSRF token, IP and user-agent change detection.
• Rate limiting: Per-account and per-IP, applied to login, password reset, and chat endpoints.
• Email verification required before vault provisioning.

Incident response

In the event of a confirmed security incident affecting customer data or service availability, we commit to:

• Public disclosure within 72 hours of confirmation, on our status page
• Direct email to all affected customers, including specifics of what was accessed and what was not
• A post-incident report within 14 days describing root cause, response timeline, and mitigations
• Cooperation with affected customers' compliance and legal teams as needed

What we don't have yet

The honest version, for evaluation purposes.

• No SOC 2, no third-party audit. We are too small and too early to pay for these meaningfully. Our architecture is what we offer for evaluation today. When revenue supports a real audit, we will commission one.
• No formal bug bounty. We pay attention to good-faith reports, acknowledge within 48 hours, and credit researchers publicly unless they prefer otherwise. We do not pay cash bounties yet.
• Single-site deployment. All vaults run in a single Los Angeles location today. ServerCrate is designed to be one leg of your 3-2-1 backup strategy, not the whole thing.
• Provider continuity. A fair concern for any backup product. Our answer is data portability: your Restic repository is in a self-contained, open format. If ServerCrate disappeared tomorrow you would still have your repository, and you could restore it against any SFTP endpoint or any other Restic backend.

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 Restic repository password in a real password manager (1Password, Bitwarden, KeePassXC). Not in a text file.
• Enable TOTP on your portal account.
• Test a restore at least once. An untested backup is a hope, not a backup.
• Set up restic check on a schedule to verify repository integrity from your end.
• Use a dedicated SSH key for unattended Restic backups, separate from your interactive admin key.

What "zero-knowledge" actually means in practice

The term "zero-knowledge" gets misused in backup marketing. Some services describe themselves as zero-knowledge when they actually mean "server-side encryption with customer-managed keys" or "encrypted at rest." Those are real features, but they are not zero-knowledge.

Zero-knowledge, in the sense that applies to ServerCrate, means this: the cryptographic keys that decrypt your data never exist on our infrastructure. They are generated by Restic on your device during restic init, derived from a password we never see. The only keys present in your vault are themselves encrypted with your master key - so even reading the key files gives an attacker nothing without your password.

The practical consequence: if a court compels us to hand over your vault data, we can hand over encrypted blobs. Those blobs are worthless without your password, which we do not have and cannot produce. That is the same guarantee Signal provides for messages and that 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 rather than a nice-to-have:

• Ransomware stopped targeting just endpoints. Modern crypto-extortion groups actively seek and destroy backup infrastructure before detonating the primary payload. A backup service whose operators could technically decrypt your data is one step away from an attacker who bribes, coerces, or phishes an employee. Zero-knowledge architectures cannot be leveraged that way - there is nothing to leak.
• Data broker law is patchwork and unstable. Storage providers operating under unclear privacy regimes have been quietly indexed, scanned, or handed over under orders they aren't allowed to disclose. Your encryption key on your device is the only reliable guarantee that your data doesn't end up in someone else's machine learning corpus or subpoena response.

Operational security you should also handle

Zero-knowledge at the service level only gets you so far. These are the operational details that determine whether your encrypted backup actually stays private:

• Where your RESTIC_PASSWORD lives on disk. On production servers, keep it in a file readable only by the backup user, not in a shell history or a world-readable script. A common pattern: chmod 600 /etc/restic/env and load via a systemd EnvironmentFile=.
• The machine that holds your password is as sensitive as the backups. If an attacker has root on the backup source, they already have the plaintext data - that's not a backup problem. What matters is whether they can also alter the offsite copy. Restic over SFTP does not prevent this by default; consider an append-only wrapper or a push-from-isolated-host pattern for high-value data.
• Rotate the RESTIC_PASSWORD periodically using restic key add and restic key remove. Restic supports multiple keys per repository so you can add a new one, verify, and remove the old one without re-encrypting the data.
• Separate your interactive SSH key from your backup SFTP credentials. If the interactive key is compromised during an incident, the backup vault should still be inaccessible to the attacker.