We hold the key

This is what every instance gets by default. We create and manage a key for your instance, with nothing for you to set up.

What it protects

• Your two-factor secret and your instance's federation signing key, encrypted at the column level.
• Every table in your database, including posts and direct messages. This runs through Postgres's own transparent data encryption, and it's on for every instance, not an add-on.
• The disk your database lives on, encrypted separately at the block level.
• Your nightly backups, encrypted with a one-time key before they touch disk.
• Your media, either in your own S3-compatible bucket (Pro plan) or on your instance's own storage otherwise. It uses network-attached storage and is encrypted whenever encryption is enabled.

What it doesn't cover

Because we manage this key, we retain the ability to reach it. Move to a key you control when you need that authority to sit with you instead.

Nothing here stops plaintext from existing in memory while your instance is actually running, rendering a page or a search. That's true of any host that actually serves your content.

How we watch it

A job runs against every account every day and proves the key still answers, whether or not your instance happens to be running that day. If a run can't reach the key, that shows up on your account status within the hour, not weeks later.

Want more control? Move to your own key any time from account settings -- included on the Pro plan.

← Back to the choice

You hold the key

Included on the Pro plan, whenever you're ready. You bring a key from a key management service you control and grant the narrow permission needed to wrap and unwrap data keys. We never receive a password, static credential, or copy of your key.

How it works

• You configure a key management service and grant this instance only the permission it needs for that key.
• Your instance proves its identity with short-lived credentials, rather than a shared secret.
• Your key stays with your provider; the application receives only short-lived data keys when it needs them.

What happens after you submit

Your instance keeps running on the platform-managed key while its volume, database, local backup, and encrypted application data are re-wrapped and verified under yours. Your database restarts once, causing a minute or two of downtime. The platform-managed key is retired only after the move completes; until the move finishes, our key can still read what was written before it.

Off-cluster backup copies shipped before the move remain under the old key and become unreadable once it is retired. Everything stored on the cluster is carried over.

The switch you can pull

Disable your key in your provider's console. Anything that needs the key, like 2FA logins and outbound federation, starts failing loudly instead of quietly -- on the very next request that touches the key, or within about five minutes on an idle instance -- and your instance's status flips to encryption_ready = false shortly after. Re-enable the key and the instance recovers on its own.

How to check it yourself

• Your provider's audit history for key operations, including each wrap and unwrap. It is recorded in your account, not ours.
• Ask us and we'll show you the raw ciphertext sitting in the database for your 2FA secret or signing key. Unreadable binary, not obfuscated text.
• The status flag on your account page, backed by the same daily check described in the other story.

Prefer not to manage this yourself? We can hold the key for you instead, which is what every instance starts with.

← Back to the choice