Platform / Module
Shards
Shards is Katafract's object-storage cluster. It is the server-side half of Vaultyx and the storage layer for a handful of internal workloads. It is S3-API-compatible — the same tools and SDKs that work with AWS S3 work here, which matters because you can export your data with any S3 client if you ever decide to leave.
Topology
Shards is a production-grade S3-compatible object store designed for geographically distributed clusters. Objects are replicated across multiple regions so that the loss of any one zone does not cause data loss. The cluster scales horizontally — we add nodes and zones as demand warrants.
Customers reach the cluster through a reverse proxy at s3.objstore.io. You never connect to a node's internal address directly. The proxy terminates TLS and forwards S3 requests to whichever cluster node answers for the bucket.
Client-side encryption — Vaultyx
This is the important part, and it is entirely on the client side.
When Vaultyx uploads a file, it does the following before any byte leaves your device:
- Derives a master key from your passphrase using PBKDF2-SHA256 with 600,000 iterations (NIST SP 800-132).
- Derives a per-folder key from the master key.
- Splits the file into variable-size chunks using FastCDC (16 KB min, 64 KB average, 256 KB max). Content-defined chunking means small edits invalidate one or two chunks instead of the whole file.
- Encrypts each chunk with a per-chunk key derived from the folder key, using AES-256-GCM (256-bit key, 96-bit nonce, 128-bit tag).
- Addresses each chunk by the SHA-256 of its plaintext. Chunks are content-addressed — duplicates dedupe automatically on your own device.
- Uploads the encrypted chunks as objects under
chunks/{hash}, and an encrypted manifest that maps your folder tree to chunk hashes.
Your master key is never transmitted. The server receives only AES-GCM ciphertext blobs and an encrypted manifest whose structure is readable (it is a JSON document) but whose filenames and folder names are not.
Bucket isolation
Each Vaultyx user gets their own bucket prefix: vault-{user_id}/. The per-user access key the client holds is scoped to that prefix. It cannot list or read another user's bucket.
Quotas live on the server side. The control plane tracks per-user byte usage and rejects presigned PUT URLs that would exceed the plan limit. Quota enforcement is the only user-specific state we maintain about Vaultyx; it counts bytes, not content.
What Katafract can see
- Ciphertext objects — the encrypted chunks. We can observe their sizes and the times they were uploaded.
- Object counts and total bytes per bucket — used for quota enforcement and billing.
- Access patterns in aggregate — how many GET/PUT operations a cluster node serves. We do not retain per-object access logs with customer identifiers.
- The encrypted manifest as ciphertext — it sits in a known location (
files/*.manifest) in each user's bucket. The filename pattern is known; the contents are AES-GCM ciphertext.
What Katafract cannot see
- Plaintext of any file — the master key never reaches us. AES-256-GCM is not reversible without the key.
- Folder names and filenames — these live inside the encrypted manifest. We see that a manifest exists, not what it describes.
- Chunk relationships across files — chunks are addressed by the SHA-256 of their plaintext, which we do not know. From our side, they are opaque blobs with random-looking identifiers.
Durability and export
Multi-region replication means a full-node failure does not lose data, and a full-zone outage does not prevent reads. Our operational practice is to rebalance promptly after node loss; objects are re-replicated to a healthy zone before we mark the failure resolved.
Because Shards speaks the S3 API, you can back up your Vaultyx bucket with any standard S3 client using the credentials in the app. The ciphertext transfers as-is. Keep your passphrase (Vaultyx does not store it) and those backups remain readable only to you.
What this means for you
The cryptographic promise Vaultyx makes is: we never hold a key that decrypts your files. Shards is the storage half of that promise. It is production-grade, multi-region object storage holding opaque encrypted blobs. If our cluster were compromised tomorrow, the attacker would obtain ciphertext and a manifest ciphertext. They would not obtain anyone's data in readable form.
Back to all modules.