Binding reference Bindings

Use Secrets Store in a Worker

Secrets Store bindings let Workers read account-level secrets without storing secret values in code.

Add the Secrets Store config, call from worker code, and start with the local test path Devflare supports.

Start with the config, wire the binding into worker code, then use the support section to decide whether local tests or Cloudflare-backed tests fit.

Config key
Authoring shape
Best for: shared account secrets that should be referenced by store id and secret name instead of copied into config

Add the binding to config

Add to , then use the generated env binding from Worker code.

Keep the first version close to the route or handler that needs it; move to a helper only after the shape is obvious.

Smallest Secrets Store config with one default store

import { defineConfig } from 'devflare/config'

export default defineConfig({

name: 'secret-worker',

secretsStoreId: 'store-123',

bindings: {

secretsStore: {

API_TOKEN: 'api-token',

STRIPE_WEBHOOK_SECRET: 'stripe-webhook-secret'

}

})

Use the binding from application code

After Devflare generates the worker env, import from and keep the first Secrets Store path close to the route, handler, or service method that needs it.

Keep this first path small enough that the config, env binding, and user-visible behavior are easy to review together.

Protect an internal route with a shared API token

import { env } from 'devflare/runtime'

export async function fetch(request: Request): Promise<Response> {

const token = await env.API_TOKEN.get()

const authorization = request.headers.get('authorization')

if (authorization !== 'Bearer ' + token) {

return new Response('unauthorized', { status: 401 })

}

return Response.json({ ok: true })

}

Local and Remote Support

Devflare can run useful Secrets Store application behavior locally for ordinary development and tests. Cloudflare still owns production limits, quotas, billing, and deployed account behavior.

Full local support through Miniflare wiring, local values, and explicit fixture values for pure tests. Start locally with or ; that lane should cover the normal Secrets Store application flow without requiring a Cloudflare connection.

Use Cloudflare when the assertion depends on deployed limits, account state, lifecycle behavior, billing, or other production-only Secrets Store details.

Set local values without putting secrets in config

Keep limited to store IDs and secret names. Use the CLI to write local values into , then let dev, , and read those values locally.

The Worker sees a read-only binding.
CLI output lists references; it does not print secret values.
Use explicit binding objects only when one Worker needs secrets from multiple stores.

Create a local secret value

devflare secrets --local --store store-123 --name api-token --value local-token

devflare secrets --local --store store-123 --list

When this binding fits best

Use Secrets Store when shared account secrets that should be referenced by store id and secret name instead of copied into config.
Keep binding names stable and uppercase in examples so generated Env declarations remain predictable.
Prefer Devflare native config while it covers the feature; use only for unsupported Wrangler-only fields.

Testing path

Start with or for config-backed local worker tests.
Use / for small unit tests that only need deterministic application behavior.
Use Cloudflare-backed tests when the assertion depends on hosted platform behavior, account state, limits, billing, or production routing.

Open the next page when you need it

Subpage

Secrets Store internals

Internals

Check emitted Wrangler , preview behavior, and Cloudflare-specific details.

Subpage

Testing Secrets Store

Testing

Pick the or path first, then move to remote checks only when the test needs them.

Subpage

Secrets Store example

Example

Copy a fuller application path when the quick example is too small.