How do I manage secrets across environments vs. preview URLs in Workers?
I’m a bit lost with how Cloudflare Workers handles environments and secrets.
- If I define multiple environments in wrangler.toml (e.g. [env.prod], [env.preview], [env.dev]), Wrangler deploys them as separate Worker scripts (my-app-prod, my-app-preview, my-app-dev). Each of these can have its own secrets, which makes sense.
- But when I use the Cloudflare dashboard’s Git integration, I get automatic Preview URLs for each deployment. That part is great, but I can’t figure out how to set different secrets for previews vs. production. It looks like they all share the same secrets because they’re the same Worker, just different versions.
Is there a way to have separate secrets for Preview URLs when using the dashboard Git integration? Or do I need to stick with Wrangler environments if I want isolated secrets per environment?
What’s the recommended best practice if I want both: easy Preview URLs and different secrets for prod vs. preview?
5 Replies
Honestly this is something that is missing for documentation. One thing I liked about pages is you could define seperate things for the preview build, even a seperate git branch. This is a feature that is sorely missing in workers. Given pages is supposed to be deprecated in the future i would love for them to fix this as well as allowing ENV to work with global binding settings.
Hey @engnadeau , I totally get the frustration. Environments (or lack of?) with workers is definitely a sore spot with Workers, and something that is being actively looked at.
You can still use environments with preview urls (and in fact, is what we recommend!). You'd want to set up your wrangler config with multiple environments (eg. production and staging), and then in your Versions Deploy command (in Workers settings / builds section), enable preview urls and specify the environment (eg. npx wrangler versions upload --env staging).
This will allow non-production branches to use your staging configuration for all preview uploads.
No need to fear, Pages will continue to be supported for the foreseeable future! We definitely encourage folks to use Workers Assets, as it's got way more features than Pages!
Thanks! I need to re-test that but last I tried that, when I did wrangler deploy it released my dev, preview, prod as three separate worker instances. What does the ideal wrangler.toml look like for this? Example?
Wrangler environments will always create separate workers, today there’s no getting around that. BUT I think that’s ok with your use case? Your second staging worker would just have version uploads, separate bindings (or the same if you want), secrets, etc,
The version upload (the preview url config) that you enable for your production worker (yeah, that feels weird to say) would just specify the environment you want for preview urls, and while it’ll upload to another worker, the preview url will still post on your PR to the staging variation (or whatever env you specify in your preview/version upload command)
so if i understand correctly: don't do Preview URLs on the production Worker. do them attached to a separate staging/preview Worker. Production stays locked down with real traffic and secrets, while Preview URLs are configured to deploy versions of the staging Worker, so PR builds run safely against staging secrets without exposing production. right?