Versioned by default
Every change appends a new version to a permanent history. You can see exactly what changed, restore any earlier value, and roll back with confidence, because nothing is ever rewritten in place.
Secrets management with explicit boundaries.
Redcee stores, versions, and delivers your application's secrets, and treats every access as a decision worth recording. Authority is granted narrowly, checked at the moment it is used, and written to a permanent audit ledger.
Product
A structured home for sensitive configuration.
Redcee organizes secrets by project, environment, and configuration, so development, staging, and production never blur together. Branches inherit from their root where that helps, and hold explicit local values where it matters.
A complete audit ledger
Every reveal, mutation, and grant is recorded in an append-only ledger, so reviews and investigations start from evidence rather than recollection.
Delivery without management authority
Read-only service tokens are scoped to a single configuration, and the CLI injects effective values into running software without ever holding the right to change them.
Step-up protection where it counts
Configurations that guard production can require a fresh password and one-time code before sensitive values are read or changed, even inside an authenticated session.
Duplication that stays safe
When a value is copied, it is authorized at its source and freshly encrypted for its destination, so a copy never widens who can read the original.
Imports you can preview
Bringing existing secrets into Redcee is a two-step operation: you see precisely what will change, and nothing is written until you approve it.
How it works
Plaintext is a release decision.
Decrypting a value is not the same as being entitled to see it. Redcee treats the return of plaintext as its own decision, made at the last possible moment and recorded before anything leaves the vault.
A revoked session, a changed grant, a replaced secret, or an expired step-up all end the same way: the request fails closed, and the value stays sealed.
-
Authorization is established
The requesting session or token is checked against the exact configuration and the exact version of the secret being asked for.
-
The value is decrypted
The value is decrypted in isolation, without relaxing or bypassing any of the checks that surround it.
-
Everything is checked again
Immediately before release, Redcee revalidates the same session, the current grants, and the same version, so a revocation made seconds earlier still counts.
-
The record commits before the value moves
An audit record of the access must commit before the plaintext is returned. If that record cannot be written, the value is not released.
Security
Built to be examined, not taken on faith.
Values are encrypted before they are ever stored, and plaintext is never written down anywhere. Organizations are fully isolated from one another. Access fails closed, and every release of a secret leaves a committed audit record behind. The full security model is public reading — we would rather you examine it than take our word for it.
Read the security modelSecrets should be boring to operate.
Redcee exists so that access to sensitive configuration is predictable, legible, and dull in the best possible way. If that is how you want your secrets to behave, we would like to hear from you.