Skip to main content

Encryption

Celeriant does not encrypt data at rest. WAL segments hold whatever bytes the client sent. What it offers is a slot for client-side encryption: each event carries an optional 12-byte iv, stored and returned next to an opaque payload.

What the server does with an iv​

Nothing cryptographic, and no client library (Rust or .NET) ships an encrypt or decrypt helper. Algorithm, keys, IV generation and rotation are yours. The field is documented as an AES-GCM IV; the server never checks.

Setting iv changes three things:

  • Schema validation is skipped for that event, even if its type has a schema.
  • Storage compression is off for the whole write batch. Ciphertext does not compress.
  • Bytes round-trip unchanged. Payload and IV come back exactly as stored.

What stays in the clear​

Only event_value is yours to encrypt. The server needs the rest to route, order, filter and deduplicate: org, aggregate type and id, event_type_major/minor, event and server timestamps, event_id, client_id, user_id, client_seq, versions. Encryption hides what happened, not that it happened, where, or when.

Transport and disk​

For the wire, turn on TLS or mTLS. For the disk, encrypt the volume underneath, and test it first: the server refuses to start when the data directory silently ignores O_DIRECT, and its startup check names encrypted filesystems as a known cause.

Why bother​

Per-subject keys give you crypto-shredding. Destroy the key and that subject's payloads are unreadable on both nodes, in S3 fallback objects and in every backup, without touching the log. See Retention and deletion and Enabling per-event encryption.