Platform / Module

Shards

S3-compatible object storage. What Vaultyx writes to, and what we can read on our side.

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:

  1. Derives a master key from your passphrase using PBKDF2-SHA256 with 600,000 iterations (NIST SP 800-132).
  2. Derives a per-folder key from the master key.
  3. 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.
  4. 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).
  5. Addresses each chunk by the SHA-256 of its plaintext. Chunks are content-addressed — duplicates dedupe automatically on your own device.
  6. 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

What Katafract cannot see

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.