Manage Worker secrets

import { Steps, Aside } from ‘@astrojs/starlight/components’;

Every Worker gets a secret target with put, bulk, list, and delete configurations that wrap wrangler secret. They manage the secrets bound to your deployed Worker. Secret values are never passed as command arguments — secret:put prompts for them, and secret:bulk reads them from a file.

Before you start

• A Worker project. Scaffold one with the application generator.
• Authenticated Wrangler (wrangler login) for the account the Worker deploys to.

Local development secrets

nx run my-worker:serve (wrangler dev) reads local secrets from a .dev.vars file at the Worker root — no target needed. The file stays on your machine; it is never uploaded.

API_KEY=local-dev-key

Add `.dev.vars` and any secrets file to `.gitignore`. Never commit secret values.

Steps

These targets act on the deployed Worker.

1. Set one secret

   bunx nx run my-worker:secret:put --name=API_KEY

   secret:put prompts for the value, then uploads it to the deployed Worker.

2. Set many at once

   Put every key in a JSON file:

   {
     "API_KEY": "…",
     "DATABASE_URL": "…"
   }

   bunx nx run my-worker:secret:bulk --file=secrets.json

   Each key becomes a secret on the Worker. Do not commit this file.

3. List the Worker’s secrets

   bunx nx run my-worker:secret:list

   Only the names are returned — values are never exposed.

4. Delete a secret

   bunx nx run my-worker:secret:delete --name=API_KEY

   This removes the secret from the deployed Worker.

Variations

Target an environment

Every secret configuration accepts --env for a Wrangler environment:

bunx nx run my-worker:secret:put --name=API_KEY --env=production

Verify

secret:list shows the secret you set:

bunx nx run my-worker:secret:list

Next steps

• Run D1 migrations — the other Day-2 workflow
• Inferred targets — the full secret target and option reference
• application generator — scaffold a Worker