wrangler deployment overwrites env vars in the worker

I'll take the DEEPSEEK_API_KEY env var as the example. I ran the wrangler secret put command to set all vars and then ran the deploy command. Finally, I went to the Cloudflare worker settings page to check the environment variables, and I found that all the variables and secrets were overwritten by the placeholder values from wrangler.toml. I also tried setting the vars directly in the dashboard, but when I connected my github project to the worker and deployed again for further features, I found that placeholder values from wrangler.toml still would overwrite my environment variables. I found that the docs say we should consider the wrangler.toml as the single source of truth, so I think maybe we should not directly set the env vars in the dashboard, but no matter how we set the env vars, it would finally get overwritten when a new deployment goes. I started to think maybe I should gitignore the wrangler.toml file, but I saw some comments online saying that it is not necessary. I'm so frustrated and confused about this. What exactly is the best practice about this? Could someone share your thoughts and practice? Thx in advance!
No description
No description
3 Replies
Walshy
Walshy2mo ago
you shouldn't have placeholder values in wrangler.toml it's expected that if you send the variable it'll set it We can't know when or when it shouldn't be set if you're explicitly setting it I recommend just doing a comment like # Secret: DEEPSEEK_API_KEY
JohnTsang
JohnTsangOP2mo ago
@Walshy | Workers/Pages thanks for your reply. way 1 : now I made a wrangler.toml.example file to record those placeholder values to indicate and set up all the vars and secrets in wrangler.toml got git ignored. But I found that doing in this way won't trigger cicd properly when I connect my github repo to the worker because the wrangler.toml file is git ignored, so I have to manually run the deploy cli command everytime. is it a good practice? way 2: like you said, just make comments for those secrets and hardcode the insensitive vars, and allow wrangler.toml file by git commit and push to the repo. Before first deployment, run wrangler secret put command, but I'm not sure whether it would need me to do it again when I deploy next time or maybe the worker would just keep it there. By contrast, I think this way could do the cicd properly when we connect the github repo to the worker. which one do you recommand?
Walshy
Walshy2mo ago
The practices I recommend: * Example .dev.vars (.env format) -- this is where all your secrets are for local use. .dev.vars gitignored * Commit wrangler.toml, wrangler.toml contains secret names which are set in .dev.vars * Set secrets once when needed - can use wrangler secrets bulk .dev.vars once it's filled out

Did you find this page helpful?