Introducing Cloudflare Secrets Store (Beta): secure your secrets, simplify your workflow

Cloudflare centralizes secret management with new beta store

Cloudflare has launched Secrets Store in beta, giving customers a single place to create, manage, and secure API tokens, keys, and other sensitive values across the platform. The service is integrated with Cloudflare Workers from day one, with additional product integrations planned.

The core problem Secrets Store addresses is secret sprawl. Today, secrets are scoped to individual Workers, which means the same API token used across ten scripts must be created and stored ten separate times. Updates require touching each copy individually, and anyone with access to a Worker script can view, change, or delete its secrets. Secrets Store moves to an account-level model: create a secret once in the store, then bind it to any number of Workers. Rotating the value updates it everywhere simultaneously.

wrangler secrets-store store create <name>

wrangler secrets-store secret create <store-id>

secrets_store_secrets = [
{ binding = "'open_AI_KEY'", store_id= "abc123", secret_name = "open_AI_key"},
]

Once bound, the secret is referenced directly in Workers code just like the existing per-Worker secret API.

const openAIkey = await env.open_AI_key.get();

How secrets are protected

Secret values are encrypted before they are stored. Cloudflare uses a two-level key hierarchy: data encryption keys (DEKs) encrypt the secret values, and a separate key encryption key (KEK) protects the DEKs themselves. The root key never leaves secure infrastructure. DEKs are refreshed frequently so that exposure of a single DEK has minimal impact. Key rotation for the KEK is planned, as is support for customer-specific account DEKs.

Once encrypted, secrets are distributed across Cloudflare's network via Quicksilver, ensuring every secret is available on every server. Two permission checks govern deployment and use: the user creating a binding needs sufficient permissions, and when a Worker fetches the secret value at runtime, the platform verifies the Worker has an appropriate binding. Secret values are never readable by developers, admins, or Cloudflare employees after creation—only permitted services can consume them.

Secrets can also be consumed by other Cloudflare services. For example, an API key stored in Secrets Store can be passed to AI Gateway when securing model access.

export default {
 async fetch(request, env, ctx) {
   const prompt = "Write me a pun about Cloudflare";
   const openAIkey = await env.open_AI_key.get();

   const response = await fetch("https://gateway.ai.cloudflare.com/v1/YOUR_ACCOUNT_TAG/openai/chat/completions", {
     method: "POST",
     headers: {
       "Content-Type": "application/json",
       "Authorization": `Bearer ${openAIkey}`,
     },
     body: JSON.stringify({
       model: "gpt-3.5-turbo",
       messages: [
         { role: "user", content: prompt }
       ],
       temperature: 0.8,
       max_tokens: 100,
     }),
   });

   const data = await response.json();
   const answer = data.choices?.[0]?.message?.content || "No pun found 😢";

   return new Response(answer, {
     headers: { "Content-Type": "text/plain" },
   });
 }
};

Granular access controls

Secrets Store leverages role-based access control (RBAC) to restrict who can view, create, edit, or delete secrets. This is a refinement over per-Worker secrets, where anyone who can modify a Worker script can modify its secrets. Account-level secrets allow a cleaner separation of duties: security admins manage the secrets themselves, while developers simply reference them in code. All mutations are written to audit logs for tracking.

Each secret is scoped to a specific Cloudflare product. Currently, secrets are limited to Workers; once additional products are supported, you'll be able to restrict a secret to, say, Firewall Rules or a particular Transform Rule.

The product group for Secrets Store appears with a detailed controls description. In a Cloudflare Zero Trust environment, these controls map to permission policies that determine who can read from the store across your organization.

Roadmap and availability

Future iterations will extend Secrets Store to other Cloudflare services that rely on sensitive values, including:

• Cloudflare Access service tokens for Zero Trust authentication
• Transform Rules that need secret values in request headers
• AI Gateway, which stores provider API keys

Planned enhancements include the ability to bind a Worker to an entire store rather than individual secrets, and support for multiple stores per account. Up to twenty secrets per account are free during the beta; Cloudflare says pricing details for higher tiers will be published soon.

Secrets Store with the Workers integration is available now via the Cloudflare dashboard and API. Setup instructions are in the developer documentation.