Step 7: Rotating secrets

Step 7: Rotating secrets

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 .dev.vars 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.

Rotate a secret

For example, imagine your API_KEY_PRIVATE 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., prd), and enter the new value for the affected secret, as shown below:

Screenshot of Doppler dsahboard, showing how to update secrets

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.