Secrets

runlot secret set STRIPE_KEY sk_live_xxx

If you omit the value, it is read from standard input (stdin). This keeps the secret value out of your shell history.

printf %s "$KEY" | runlot secret set STRIPE_KEY

Reading it in the worker

export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    const key = env.STRIPE_KEY;
    // …
  },
};

Names must match ^[A-Z][A-Z0-9_]{0,63}$. Uppercase names never collide with lowercase binding names such as db and assets.

Listing and deleting

runlot secret list

STRIPE_KEY    v2    2026-09-05T14:02:11Z
DATABASE_SALT v1    2026-09-01T09:12:40Z

The list shows only names and versions. Secret values are never shown again in the dashboard, the CLI, or the API, and runlot does not read them back either.

runlot secret delete STRIPE_KEY

Once deleted, the worker can no longer read that value. You are asked to confirm before the deletion.

There is no directory argument

The second argument to runlot secret set is the secret value. To target a different project, use flags instead of a directory argument.

runlot secret set STRIPE_KEY sk_live_xxx --org me --project other-app

Where secrets are stored

Deploy configuration contains only the names of your secrets. The values are passed to the worker process as environment variables only, and are not stored in the configuration file. So even if the configuration file is exposed, it does not contain any secret values.

Changing a secret value increments its version. The new value takes effect when the worker restarts, without waiting for the next deploy.