Secrets

Secret values

Secret values are for runtime use and should not appear in read models, logs, diagnostics, support payloads, or effective-config responses as plaintext.

Users should see the existence and state of a secret, such as masked value, last update time, source environment, and whether it participates in deployment snapshots. They should not see plaintext values.

Build-time limit

Build-time variables cannot be marked secret because they can become part of build artifacts.

If a variable can enter a browser bundle, static file, or build artifact, it is not a secret. Do not put database passwords, API tokens, or private keys in build-time variables.

Rotate secrets

After rotating a secret, redeploy resources so running instances read the new deployment snapshot.

Recommended flow:

1. Set the new secret in the target environment or on the target resource when the override is resource-specific.
2. Create new deployments for affected resources.
3. Confirm health and logs show the app reading the new value safely.
4. Confirm the old secret is no longer used.
5. Revoke the old secret in the external system.

Diagnostics and support

When copying diagnostics, copy key names, masked state, error codes, and related deployment ids. Do not copy .env files, full variable tables, or secret values.

Related page: Diagnostics.