The one rule that defines everything
A zero-knowledge backend has exactly one rule, and every other decision falls out of it: the server receives ciphertext and nothing else. No plaintext file touches it. No decryption key touches it. Encryption and decryption happen on your device, before upload and after download, with keys the server has never seen. Hold that rule and "we can't read your files" stops being a promise — there is no key on our side to read them with.
That sounds like a small architectural choice. It is not. It breaks every convenient feature you would normally build server-side: search, deduplication, thumbnails, malware scanning, preview-in-browser. Each one assumes the server can read the bytes. When it can't, you move the work to the client or you don't do it. That tradeoff is the whole story, and it's worth getting right if you're trying to tell a real claim from a marketing one.
The key hierarchy: where keys live, and where they don't
It starts with a passphrase you choose, which never leaves your device. The client runs it through Argon2id, a memory-hard derivation function tuned at 256 MB of memory and 4 iterations. The point of that cost is offline guessing: even with the full ciphertext in hand, an attacker pays real RAM and real time per password attempt, which is exactly why RFC 9106 recommends memory-hard parameters in the first place.
The resulting root key stays on the device too. What the server stores is the output of an envelope scheme. Every file gets its own random AES-256-GCM key, generated client-side, that encrypts the file's bytes; GCM's authentication tag means any tampering fails the decrypt instead of returning garbage. That file key is then wrapped under a key derived from your root key, and only the wrapped version is uploaded. So the server holds three things: encrypted bytes, a wrapped key it cannot unwrap, and your account's public key. Sharing rides the same idea — a per-share key sealed to the recipient's X25519 public key, brokered by a server that can route the envelope but never open it.
What the server actually sees on upload
When you upload, the request that reaches our infrastructure in Falkenstein, Germany is an opaque blob of ciphertext, a wrapped key, and the minimum metadata needed to store and fetch it. The server writes the blob to disk. It never runs your file through an image library, a text indexer, or a scanner, because all three need plaintext it doesn't have.
Here is the part most marketing skips. Some metadata is unavoidable. The server has to know an object's size to enforce your quota and bill storage. It knows when the object was created or last touched, and which account owns it. We minimize and encrypt the rest — filenames and folder structure are encrypted client-side — but zero-knowledge means zero-knowledge about contents, not about the fact that an encrypted object of roughly N bytes belongs to an account. Anyone claiming their server knows literally nothing is overselling it.
Why search, dedup, and previews get hard
Search. You can't index ciphertext. A normal cloud builds a full-text index server-side; we can't, because the server can't read the words. Search runs on the client over data it decrypts locally, or through encrypted-index schemes the client builds and the server stores blind. It is slower and more limited than Google Drive's instant server-side search. That's a genuine cost, and the right one to pay.
Deduplication. The encrypted version is convergent encryption, where a file's key is derived from its own contents so identical files produce identical ciphertext — store it once, save money. It also leaks. An attacker who suspects you hold a specific file can encrypt their own copy and check whether that ciphertext already exists, confirming the guess. The same determinism opens offline dictionary attacks on low-entropy files. We don't do cross-user convergent dedup. The savings aren't worth handing attackers an oracle.
Previews. A normal cloud renders thumbnails server-side; we can't see the image. So thumbnails are generated on the client and encrypted before upload, or rendered on demand after the client decrypts the original. More bandwidth, more local work, but the server never sees a pixel. The pattern holds everywhere: anything that needs to understand your data runs where the keys are, which is your device.
What a breach can and cannot leak
The honest test is the worst day — someone gets root on the storage servers. What do they walk away with?
They get ciphertext: per-file AES-256-GCM blobs whose keys they don't have. They get wrapped keys they can't unwrap, sealed under your Argon2id-derived root key, which lives only on your device. And they get metadata — account identifiers, object sizes, timestamps, the shape of your storage. That last bucket is the real exposure of any end-to-end system, and pretending it away is the dishonest move; it's why metadata minimization and encrypted filenames matter. What they do not get is the one thing that counts: the contents of your files. Compare a conventional cloud, where root on the storage tier hands the attacker plaintext, because the provider holds the keys to run search and scanning. Blast radius follows key location.
How to verify the claim instead of trusting it
Three concrete tests. Can they reset your password and restore your files? If yes, they hold a key, and it isn't zero-knowledge. Real zero-knowledge means a forgotten passphrase with no recovery phrase is gone for good — we ship a BIP39 recovery phrase precisely because we have no backdoor to offer in its place. Can you read the client source? The encryption happens client-side, so the client is where the claim is proven or broken; our web app, CLI, mobile, desktop, and core crypto library are open source. The server is private — it only ever sees ciphertext, so there's little to audit there — and so is this marketing site. Is it on by default, on every tier? Apple's Advanced Data Protection for iCloud is the clearest counterexample: off by default, and even switched on, your iCloud Mail, Contacts, and Calendar stay readable by Apple. Encryption nobody enables protects nobody. On Beebeeb it's the architecture, not a setting, on every tier including the trial.
A zero-knowledge backend is slower to build on and can't do some things a normal cloud does for free. That's the price of the guarantee, not a flaw to apologize for: the moment a server can read your files to be helpful, it can read them under subpoena, in a breach, or to "improve the product." If you want to feel where the line sits,