Stored once, shown once, resolved at deploy.
Encrypted secrets and reusable project variables in one place. Scope values by environment, link them to app environment variables, and let each deployment resolve the current value without anyone reading it.
- 5 secrets free
- AES-256 GCM per secret
- 4 environment scopes
- Unlimited project variables
# the value comes back once$ POST /v1/projects/:projectId/secrets{ "name": "DB_PASSWORD", "environment": "staging" }# every read after thatmaskedValue: "my••••ue" · version: 1
- DB_PASSWORDproduction
- DB_PASSWORDstaging
- STRIPE_API_KEYdefault
ENCRYPTION
AES-256GCM
A data key per secret, wrapped
INCLUDED
5secrets
Then USD 2 / month per pack of 5
SCOPES
4
Default, development, staging, production
READS
Metadata only
Plaintext returns twice, ever
From value to running app
The value never passes through a person
The usual leak is not the vault — it is the copy of the value in a chat message, a shared document, or six app configurations. Linking removes the copies.
- 01
Store the value once
Create the secret with an uppercase name and, if it differs per environment, the environment it belongs to. The plaintext is shown once and never again.
- 02
Link it to an app
In the app's environment variables, link the secret instead of pasting a value. The variable shows as linked to the vault rather than showing anything sensitive.
- 03
Rotate by updating one place
Linked variables resolve to the current value on each deploy, so updating the secret and redeploying is the whole rotation.
The security model, in practice
Built so a read cannot leak
Encryption is the easy half. The rest is making sure the plaintext has nowhere to appear once it is stored.
Envelope encryption
Every secret gets its own AES-256-GCM data encryption key, which is itself encrypted by a separate master key. Compromising one value does not hand over the rest.
AES-256-GCM · DEK + KEK
Write-only by design
Plaintext comes back exactly twice: when you create a secret and when you update it. Reads and lists return metadata and a masked preview, never the value.
maskedValue: my••••ue
Environment scopes
The same name can hold a different value in development, staging, and production, plus a default scope for the values that are the same everywhere.
development · staging · production
Resolved at deploy time
Linked app variables fetch the current decrypted value on every deployment, so rotating a credential is one edit rather than a search across apps.
Takes effect on next redeploy
Audit trail per secret
Every create, update, and delete is logged with the acting user and a timestamp, on the secret itself rather than in a project-wide firehose.
CREATED · UPDATED · DELETED
Variables for the rest
URLs, feature flags, and plain settings belong in project variables — readable at any time, unlimited, and not counted against your secrets limit.
Plaintext, on purpose
Linked app variables
One vault entry, however many apps
Instead of pasting a value into each app that needs it, link the secret. The variable appears with the secret's name as its key, and the value shows as linked to the vault rather than as anything readable.
- Linked variables are resolved to the current decrypted value each time the app deploys.
- Rotating a credential is one update plus a redeploy, not an edit in every app that uses it.
- The value is never rendered in the control panel — the field reads as linked to the vault.
- Link several secrets at once from the picker in an app's environment variables.
"envVars": [ { "key": "DB_PASSWORD", "value": "", "secret": true, "projectSecretId": "clx…" }]
# what the control panel showsDB_PASSWORD Linked to vault
What it costs
Five to start, five at a time after that
Secrets are counted, variables are not. When you need more room, packs are added as a prorated subscription item and removed again if your usage drops back.
- First 5 secrets
- Free
- Every project starts with 5 secrets included, with no subscription needed to use them.
- Each pack of 5 more
- USD 2 / month
- Buy as many packs as you need. Added as a prorated subscription item, and removed automatically if you drop back inside the free tier.
- Project variables
- Unlimited
- Non-sensitive configuration is not metered and never counts against the secrets limit.
Buying a pack requires the project to already have an active subscription. The control panel shows your new limit and the added monthly cost before you confirm.
One project
What it plugs into
A vault is only useful to the things that consume it, which is why it sits in the project rather than beside it.
Questions worth answering up front
Naming rules, environments, audit trails, and the security model are covered in the secrets guide.
- What if I lose the value?
- You update the secret, which returns the new plaintext once and starts a new version. There is no way to read an existing value back — that is the point of a write-only API, not a gap in it.
- Secret or variable?
- If reading it out loud would be a problem, it is a secret. API keys, passwords, and tokens go in the vault; URLs, feature flags, and settings go in project variables, which are readable, unlimited, and free.
- Who can create and read secrets?
- Only project owners and admins can create, update, or delete them. Members with read access see metadata — names, descriptions, versions, timestamps — and never a value.
- How do I keep separate staging and production values?
- Create the same name once per environment. A secret with no environment lands in the default scope, which applies everywhere, so shared values do not have to be duplicated three times.
- When does a linked value change take effect?
- On the next deployment. Linked environment variables resolve to the current decrypted value each time the app deploys, so a running app keeps the value it started with until you redeploy it.
- What happens if I delete secrets after buying a pack?
- The pack is removed automatically once you are back inside the free tier, so you are not left paying for headroom you stopped using.
Role-based access
Who sees what
Access to the vault follows the project role, so adding a teammate does not mean handing over every credential the project holds.
Owner and admin
Create, update, and delete secrets. They are the only roles that ever see a plaintext value, and only at the moment they set it.
Member with read access
Sees names, descriptions, versions, and timestamps — enough to work with configuration, and nothing that leaks it.
Everyone, afterwards
The audit trail records every mutation with the acting user and timestamp, so a change is always attributable.