Encrypted storage

Encrypted storage makes the sensitive parts of your captured data unreadable at rest to anyone but your team, including the server operator. It is what lets you report from an application handling personal or confidential data, and keep your team the only one able to read what was captured.

Paid feature. Encrypted storage is gated by the encryption plan feature (included on Indie and Studio). Manage it from the Encryption page in the /app panel.

How it works: a per-team key pair

When you enable encryption, your team gets an X25519 key pair:

• The public key is stored in clear. It is used at ingestion to seal (encrypt) content. Encrypting data never needs your passphrase, so the server can keep encrypting incoming events even while no one is logged in.
• The private key is stored wrapped: encrypted by a key derived from your team passphrase with Argon2id (a kdf_salt is stored alongside it). Only your passphrase can unwrap it.

Cryptography uses libsodium: a sealed box for the content and a secretbox to wrap the private key.

What gets encrypted (and what doesn't)

When encryption is active, ingestion seals the sensitive content of each record, the exception message, stack trace and request context (and, for logs, the message and context), into a single sealed payload, and erases the readable copy.

Metadata stays in clear on purpose: exception class, file, line, level, environment, release and the grouping fingerprint. That keeps grouping, search and filtering working without ever exposing your content.

Session unlock

To read encrypted content you unlock your session:

1. On the Encryption page, choose Unlock and enter your team passphrase.
2. The passphrase unwraps the private key, which is held for the duration of your session.
3. Encrypted issues, occurrences and logs now decrypt transparently in the UI.

When locked, encrypted fields show a lock placeholder (🔒) instead of content. Lock clears the key; logging out drops it too.

Honest limitation. During an unlocked server session the private key lives in server memory (held app-encrypted in the session store). If you prefer that the key never reaches the server at all, use the browser unlock below. Either way the model at rest is zero-knowledge: your content is unreadable in the database without your passphrase.

Browser unlock: the key never leaves your tab

The Encryption page also offers Unlock in this browser. In this mode:

1. Your browser fetches the public key and the wrapped private key (members only).
2. The passphrase derivation and the unwrapping happen inside your browser; the passphrase is never sent to the server.
3. Sealed messages, contexts and stack traces on the issue and log detail pages decrypt directly in the page.

The unwrapped key is kept for the current tab only and is cleared when you press Lock this browser or close the tab. Deriving the key takes a few seconds on purpose: it uses the same hardened parameters as the server.

List views keep their lock placeholders; open the detail page to read decrypted content. The server unlock and the browser unlock are independent, use whichever fits your threat model.

Alerts and encrypted teams

Alerts are produced server-side at ingestion, where no passphrase is available. So for encrypted teams, alert payloads carry only metadata and a dashboard link, never the sealed content. See Alerting.

Changing your passphrase

You can change your passphrase from the Encryption page. This re-wraps the existing private key under the new passphrase, it does not re-encrypt your data, so it is fast and safe.

Lost passphrase = unrecoverable

There is no passphrase reset. Your data is sealed to a key only your passphrase can unwrap. If every holder of the passphrase loses it, the encrypted content is permanently unrecoverable by design, not even the operator can help. Enabling encryption requires you to acknowledge this. Store the passphrase somewhere safe (a team password manager).

Related

Encrypted storage also powers zero-knowledge backups, which use the same team key pair.