In this tutorial, you'll set up a complete secrets management workflow for Cloudflare Workers using Doppler. By the end, you'll have:

A Cloudflare Worker with secrets managed through Doppler across development, staging, and production environments

Automated local development that pulls secrets directly from Doppler

A one-command sync that pushes secrets to Cloudflare Workers

A GitHub Actions workflow for automated deployments

A rotation workflow that updates secrets across all environments in seconds

Managing secrets across development, staging, and production environments is one of the most common sources of friction in serverless development. When you're working alone, a .dev.vars file and a few wrangler secret put commands might suffice. But as your team grows and your deployment frequency increases, you start running into real problems. Secrets get out of sync. Someone on the team doesn't have the latest API key. Rotating a compromised credential requires updating three different places. And there's no audit trail showing who changed what or when.

Using a centralized secrets manager is a straightforward way to address this issue. Instead of scattering secrets across .env files, CI/CD variables, and Cloudflare's dashboard, you maintain a single source of truth. Everyone on the team pulls from the same place. Rotating a secret becomes a one-step operation. And you get a complete history of every change.

 installed and authenticated(run doppler login after installation)

A step-by-step guide to building a secure, scalable workflow for managing secrets in Cloudflare Workers.

To focus on the secrets management workflow, you'll use a sample Worker that's designed to verify your secrets configuration. Start by cloning the repository:

 endpoint that reports which secrets are configured without revealing their actual values. This makes it easy to verify that your integration is working at each step.

The Worker checks for nine different secrets representing common patterns in production applications, including API keys(both public and private), webhook signing secrets for verifying incoming requests, service tokens for internal authentication, error tracking DSNs, and a rotation version identifier for verifying that updates have propagated.

Throughout this tutorial, you'll use this project to pull secrets from Doppler for local development, sync them to Cloudflare for production, automate deployments with GitHub Actions, and practice rotating credentials without downtime.

Set the foundation with a ready-to-use project built for secure configuration workflows.

Step 1: Clone the starter project

To proceed, sign in to your Doppler account, go to the Projects page, and click the plus button(as shown below) to create a new project. Name the project “cloudflare-workers-demo.”

Doppler automatically creates three environment configurations for every new project. These are 

 (production). These values are displayed immediately after the project is created, as shown below.

You can also view them directly in your terminal with:

The dev_personal config is a personal branch of dev for individual developer customization. For this tutorial, the focus will be on the three shared environments: 

Establish a single source of truth for your application secrets.

Step 2: Create your Doppler project

Let’s move on to configuring secrets for your development environment. In your Doppler dashboard, select the 

 environment from the list. Next, click the dropdown next to 

After clicking this button, a modal will appear where you can paste your existing secrets. Paste the following values into it:

Once you’re finished, the secrets will be listed in your 

 environment in the Doppler dashboard for 

For production, import the following secrets using the 

At this point, your secrets exist in Doppler, but your Worker doesn't have access to them yet. The next step connects these two systems.

Move your secrets out of scattered files and into a secure, centralized system.

Step 3: Add your secrets to Doppler

Once your secrets are set up in the Doppler dashboard, ensure you’re signed in to the Doppler CLI and inside your cloned sample project folder. Then run:

This command links your project to Doppler and sets the dev environment as the default for all Doppler commands run in this directory.

Before deploying your application to production, you'll want to test locally. Cloudflare Workers present a unique challenge here. Unlike traditional Node.js applications that read secrets from 

, Cloudflare Workers receive secrets through the 

 object passed to the fetch handler. This means tools like 

 file. During local development, Wrangler reads this file and injects the values into the 

 object. Instead of manually maintaining this file, you can generate it directly from Doppler by running the following command:

This command pulls all secrets from your current configuration(dev) and writes them in the format that Wrangler expects.

You should see output indicating that Wrangler found and loaded your 

 in your browser, and you should see all secrets reporting as "configured":

Your local development environment is now pulling secrets from Doppler. Any team member with access to the Doppler project can generate the same 

 file and get identical results. No more sharing secrets over Slack, no more stale 

 files copied weeks ago, and no more debugging issues that turn out to be mismatched credentials.

To test with staging or production secrets locally, regenerate the 

Now your local Worker runs with staging secrets.

Develop locally without hardcoding secrets or exposing sensitive data.

Step 4: Cloudflare local development with Doppler

Local development is working. Now it's time to get those secrets into Cloudflare so your deployed Worker can use them.

Unlike local development, where secrets come from a file, production Workers read secrets stored in Cloudflare's infrastructure. That simply means you need to upload your secrets to Cloudflare before deploying. While Doppler doesn't have a native sync integration with Cloudflare Workers, you can pipe secrets directly using the CLIs.

First, make sure the Wrangler CLI is authenticated with Cloudflare:

Complete the OAuth flow in your browser. After successful authentication, return to your terminal and verify that everything is set up correctly by running:

This confirms which account you're currently authenticated as. Once verified, sync your production secrets from Doppler to Cloudflare:

This command first fetches all production secrets from Doppler in JSON format using the 

 configuration. The output is then piped through 

 to extract only the computed secret values, removing Doppler-specific metadata. Finally, 

 reads the cleaned JSON from standard input and uploads each secret to Cloudflare in a single batch.

As the process runs, you'll see a confirmation message for each secret as it's uploaded:

With secrets in place, deploy your Worker by running:

After deployment completes, you'll see the URL for your Worker:

 and all secrets reporting as "configured".

You've now completed the core workflow. Secrets are centrally managed in Doppler, local development always pulls the latest values, and production uses its own isolated set of credentials.

While this manual process works, running these commands on every deploy is tedious and error-prone. The next step automates the entire workflow.

Ensure your production environment stays secure and in sync.

Step 5: Deploy the application and sync secrets to Cloudflare

Manual deployments work for occasional updates, but they don't scale. Every time you push code, you need to remember to sync secrets. If a team member deploys without syncing, secrets could get out of date. And there's no record of who deployed what or when.

To solve this, all we need to do is create a GitHub Actions workflow. Once the Worker is created, the workflow will automatically fetch the latest secrets from Doppler, update them in Cloudflare, and deploy the Worker whenever you push code.

You've been using the Doppler CLI with your personal login, which works for interactive use. For automated systems like GitHub Actions, you need a service token instead.

Service tokens are scoped to a single environment(like production) and provide read-only access to secrets. If a token is compromised, an attacker can read secrets but can't modify them or access other environments. This principle of least privilege is important for CI/CD security.

To proceed, generate a token for your production configuration:

Save the output somewhere secure. You'll add it to GitHub in a moment.

 template, as shown in the image below, then generate and save the token.

After selecting the template, generate the token and copy it somewhere safe for now. You will need it shortly.

You'll also need your Cloudflare account ID. You can find it on the account home page by clicking the three-dot menu next to your email address, as shown below.

Now that you have all three values, add them as repository secrets. In your GitHub repository, go to Settings > Secrets and variables > Actions, then click "New repository secret" to add each of the following:

: Your Cloudflare account ID from the dashboard

Next, create a new GitHub Actions workflow at 

. This file will define the steps used to build and deploy your Worker automatically on each deployment.

Now, every push to your main branch automatically installs dependencies, pulls secrets from Doppler using the service token, syncs those secrets to Cloudflare, and deploys the Worker. This eliminates manual steps, forgotten secret syncs, and uncertainty about whether production has the latest credentials. Every deployment is consistent and fully auditable.

For more sophisticated setups, you may want separate staging and production deployments driven by different branches. The expanded workflow below deploys automatically based on the branch that was pushed.

With this setup, staging and production are cleanly separated while still being fully automated through the same pipeline. Each environment uses its own configuration, secrets, and deployment target, reducing the risk of accidental cross-environment changes.

Build a secure pipeline that keeps secrets out of your codebase.

Step 6: Set up GitHub Actions for CI/CD

With CI/CD in place, deployments are automatic. But what happens when you need to change a secret? Perhaps an API key was accidentally exposed, or perhaps your security policy requires rotating credentials every 90 days. This is where the centralized approach really pays off.

In a traditional setup, rotating a secret means updating it in every place it exists: local 

 files, CI/CD variables, production secrets, and possibly documentation. Miss one, and something breaks. With Doppler, you update the secret once and sync it everywhere.

 was exposed in a commit and needs to be rotated immediately. To update a secret, visit your Doppler dashboard, select the relevant environment(e.g., 

), and enter the new value for the affected secret, as shown below:

Alternatively, you can also update the secret directly from your terminal using the Doppler CLI:

Once updated, sync the latest production secrets to Cloudflare:

Finally, redeploy the Worker so the new value takes effect:

The entire process takes about 30 seconds. When CI/CD is configured, the sync and redeploy steps happen automatically on your next push, making secret rotation fast, reliable, and low-risk.

Zero-downtime rotation for critical secrets

Some secrets can't be rotated instantly without risking downtime. For example, webhook signing secrets often need to remain valid while you update the webhook provider to use a new value. In these cases, a dual-credential pattern allows you to rotate secrets safely without dropping requests.

To do this, start by adding the new secret alongside the existing one in Doppler, keeping both available in production:

Next, update your Worker code to accept either secret. The application should first attempt verification using the new secret and fall back to the old one if necessary:

Once the code is updated, the next deployment will automatically sync both secrets from Doppler and deploy the Worker:

At this point, your Worker accepts requests signed with either the old or new secret. You can now update your webhook provider's dashboard to use the new signing secret. As new requests begin arriving with the updated signature, traffic gradually shifts without interruption.

After confirming everything is working correctly, complete the rotation by removing the temporary secret and promoting the new value to the primary one:

This approach requires a bit more upfront coordination, but it ensures zero downtime and prevents dropped requests during sensitive secret rotations. It's also worth mentioning that this pattern is only necessary for externally validated secrets, such as webhook signing keys, and is usually overkill for internal credentials that can be rotated immediately.

Reduce risk with zero-downtime secret rotation.

Step 7: Rotating secrets

So far, you've been working alone. But the real value of centralized secrets management appears when multiple people need access. A new engineer joins the team. Do you send them secrets over Slack? Copy a 

 file from your machine? Neither option is secure nor maintainable.

Doppler solves this with role-based access control. Team members authenticate with their own accounts and access secrets based on their assigned roles. When someone leaves the team, you revoke their access in one place.

From the Doppler dashboard, navigate to your project and open the Members section, as shown in the image below.

From there, invite team members by email and assign each person a role based on their responsibilities. The available roles are:

For most teams, developers who need to run the application locally should have Collaborator access, while stakeholders who just need to verify configurations can have Viewer access.

New team members can get up and running in minutes:

 files to share. No secrets in Slack messages. Everyone pulls from the same source.

Doppler maintains a complete history of every secret access and modification. You can view recent activity on the 

You can also view activity through the CLI:

This shows workplace-level activity, including who accessed or modified secrets and when. If a breach occurs, you can determine exactly which secrets were potentially exposed and who had access. This level of visibility is essential for security compliance and incident investigation.

Give your team access without sacrificing security or control.

Step 8: Team collaboration

The sections below outline the most common problems you might encounter while integrating Cloudflare Workers and Doppler and how to diagnose and resolve them quickly.

 file is missing or out of sync with the current values in Doppler. Regenerate the file by pulling the latest secrets directly from Doppler:

After regenerating the file, restart your development server so the updated environment variables are picked up.

Service tokens are scoped to a specific configuration. If you're seeing authentication errors, verify that the token was created for the correct configuration, such as prd for production. Next, confirm that DOPPLER_TOKEN is correctly set in your CI/CD secrets. If issues persist, try regenerating the token and updating it in your pipeline.

If you have a large number of secrets(50 or more), you may encounter Cloudflare rate limits during sync. Wrangler's bulk upload handles this gracefully in most cases, but if you see rate-limit errors, you can reduce the upload pace by lowering the batch size:

This command syncs production secrets from Doppler to Cloudflare in smaller batches, which reduces the number of requests sent at once and helps avoid hitting rate limits.

Quickly resolve issues and keep your workflow running smoothly.

Troubleshooting common issues

You started with manual secret management and built a production-ready workflow. Secrets now live in Doppler, organized by environment. Team members generate identical local environments with one command, secrets sync to Cloudflare automatically, and rotating credentials is as simple as updating Doppler and pushing a commit.

 for each secret in each environment is now a single 

 followed by an automated sync. What used to take hours happens in seconds. For more advanced patterns, check out Doppler's documentation on 

. The complete code used in this tutorial is also available on 

Role	Capabilities
Admin	Full access, manage team, delete project
Collaborator	View and edit secrets in all environments
Viewer	View secrets (read-only)

Step 8: Team collaboration

Give your team access without sacrificing security or control.

Step 8: Team collaboration

Invite team members

Team member setup

Audit trail

Enter the new era of secrets management