Confusing advice about secrets and Wrangler
From what I can tell, it does not make sense to put sensitive data in the TOML file because this would be committed.
CF acknowledges this by suggesting we use
.dev.vars for local, and secrets for production.
However, when adding secrets (via the dashboard), CF then says it "recommend[s] updating your wrangler.toml file to keep your local development environment in sync."
So this advice seems to be contradictory.
A related issue is that, as far as I know, local DB connection strings for Hyperdrives must be specified in TOML, not .dev.vars (the latter didn't work for me). So this necessitates having two TOML files - one production, one local - the local one being denoted via the --config param, because putting the connection string in the main TOML would mean committing DB credentials.
Am I right in all the above, or can anyone clarify anything I'm missing?4 Replies
not sure how env works in local.... does it absorb the shell env where it was started?
You would have to define env vars locally to match the ones you define in the dashboard I guess (if you need them defined always)?
However, when adding secrets (via the dashboard), CF then says it "recommend[s] updating your wrangler.toml file to keep your local development environment in sync."Yea you don't need to do that for secrets. Are you clicking "Encrypt" when adding them? For me adding a new encrypted environment variable properly doesn't come up with that menu well if you have any non-encrypted env variables it does come up with that, but it excludes the encrypted ones
Thanks @Chaika . Mine are non-encrypted (they're sensitive, but I'm just testing things out right now so I didn't encrypt them.)
well that's not a secret then, that's just an environment variable
Secrets are just encrypted environment variables (can also be added via
npx wrangler secret put <key>)
Normal Environment Variables are not encrypted and useful for storing generic app config stuff (which account id to use, which endpoint, etc)