/secrets

Secrets that never leak into a command, a log or a chat.

One store for the values nothing else should see. A value leaves it in exactly two ways: into a container’s environment when it is deployed, and to a person with permission — once, recorded.

Request early access Talk to us

Encrypted and versioned
Given at deploy time only
Who runs the old value, named

STRIPE_SECRET_KEYv4

•••••••••••••• encrypted · rotated just now

crm-apiv4
crm-workerv3older value

Deploy the 1 on v3

4
scopes
organization · stack · container · workspace environment
20
versions kept
restore any — as a new version
0
values in responses
except the one reveal that asks for it
1
button to catch up
deploys exactly the containers still behind

/how-secrets-work

Referenced, never copied.

A password in three configurations is three places to rotate and three places to leak. Here there is one row per value, referenced by what needs it.

Scoped to who may use it.

A secret belongs to the organization — any container may use it — to one stack, to one container, or to a workspace’s environment, where it reaches the containers built from that workspace’s code. The scope is checked when a configuration is saved and again when it is deployed, so a reference across a boundary fails where you are looking, not at 2 a.m.

A database’s password is generated as its own secret and goes when the database goes.
Production and staging values of one name are two secrets — set once per environment.
Paste a .env file: every line checked before any is written, and only real changes make new versions.

Secrets grouped by scope, with versions and the containers that use each one.

Every change is a version — and the old one is named.

Changing a value restarts nothing: a container keeps the value it was deployed with. Each deploy records which version of each secret it was given, so every screen can say the true thing — “running an older value of STRIPE_KEY” — and one button deploys exactly the containers that are behind.

Older versions are kept and can be restored — as a new version, so history only moves forward.
Rotation reminders and expiry warnings go to the people who can change the secret.
Rolling back a container uses today’s secrets: rolling back code never brings back a rotated password.

STRIPE_SECRET_KEY · who uses it

v4  rotated just now by alex · encrypted crm-api      v4   currentcrm-admin    v4   currentcrm-worker   v3   running an older value — deploy to apply → Deploy the 1 container on v3

Given at deploy time, over stdin.

The values exist in exactly one place at one moment: the payload of the deploy, on its way into the container’s environment. They go to the server on stdin — never in a command line, so never in the record of commands the platform keeps. Previews and reviews show a secret by its name.

-e STRIPE_KEY=<secret STRIPE_KEY> — the review shows where each value comes from, never the value.
Logs are masked on the way out: NAME=value for every secret name of the organization.
Encrypted with AES-256-GCM, bound to its row and version — a copied ciphertext fails loudly.

Review · what will run on vm-prod-1

docker run -d --name crm-api --network crm-prod-net \  -e 'DATABASE_URL=<database crm-mysql · url>' \  -e 'STRIPE_SECRET_KEY=<secret STRIPE_SECRET_KEY>' \  -e 'SESSION_KEY=<new secret SESSION_KEY>' \  crm-api:2026.09.25-8c1e2f4 # values travel on stdin to the Docker Engine API — not in this command

Knowing a secret exists is not knowing it.

Seeing the list, the versions and who uses what needs only read access. Revealing a value is its own permission, rate-limited per person and written to the audit log with the version. Only people — never an API key — may change or reveal a secret.

A reveal is the only response in the platform that carries a secret’s value.
Deleting a secret something still uses is refused, naming what uses it.
The audit log keeps that it existed after it is gone.

/faq

Secrets, answered plainly.

Something else? Write to [email protected] or use the contact page — a person answers.

Does changing a secret restart my containers?

No. A container keeps the value it was deployed with. Every screen then names the containers still running the older value, and one button deploys exactly those.

Can I use my own vault?

Secrets live in the platform’s own encrypted store. It is small enough that moving where the ciphertext lives is one file — tell us if your company needs its own vault.

Do secrets rotate automatically?

You can ask to be reminded every N days and warned before an expiry. We can remind — we can’t rotate a key someone else issued to you.

Are secrets available at build time?

Run-time secrets are, per container and per workspace environment — and a sandbox gets only the secrets its task was given.

/start

Rotate without fear.

Secrets come with every organization. Request early access to start.

Request early access Talk to us