OneEnv
← All posts🔒 Part 19 of 21

Your Secrets Are Now Encrypted at Rest

ShareLinkedInX

A product whose pitch includes "govern your secrets" has no business storing those secrets as plaintext — so before opening OneEnv up, we closed exactly that gap. Every environment value is now encrypted at rest with AES-256-GCM: the shared master values, every service's synced copy, both override slots, and the value diffs inside change events. A leaked database backup no longer equals a secret dump.

Where the encryption lives

Not scattered across route handlers. The encryption is a single custom column type at the ORM boundary — values encrypt on the way into Postgres and decrypt on the way out, transparently to every read and write path in the codebase. That design choice matters: there is no code path that can accidentally write a secret in plaintext, because the column itself won't allow it.

App code
sees plain values
→
Column type
encrypts on write
→
Postgres
stores ciphertext only
→
Column type
decrypts on read

The rest of the secret-handling story

Masked on display
Secret values render as ab•••••yz on every listing, diff, and history view — full values appear only in the export a service actually pulls.
Mask-resubmit guard
Saving a form that still contains the masked placeholder can't overwrite the real value with asterisks.
Hashed tokens
Refresh tokens and CI export tokens are stored as hashes, shown once at creation — the database never holds a usable credential.
Verified, not assumed
We confirmed ciphertext in the actual Postgres rows with psql, and backfilled every pre-existing value idempotently.

What we're saying out loud

Two honest caveats, because publishing them is cheaper than a user discovering them: historical copies of values inside already-merged branch snapshots are on the fast-follow list for the same treatment, and encryption at rest protects a stolen backup, not a compromised server that holds the key. Security claims should be specific or they're marketing. The broader trust model — who can read, who can write, who can approve — is covered in Roles, Permissions & Trust.

ShareLinkedInX