Can I refer to env vars in wrangler.toml
Can I refer to env vars in wrangler.toml? I am setting up inngest with Cloudflare and need to set INNGEST_SIGNING_KEY, technically that's a "secret" but setting it via
wrangler secret put INNGEST_SIGNING_KEY doesn't make it available in the "environment variables", inngest sync fails and to put it in environment variables, I need to add it to wrangler.toml as "plain text" and deploy.17 Replies
Then I can't put wrangler.toml in version control anymore
So, can I do something like
INNGEST_SIGNING_KEY=$INNGEST_SIGNING_KEY in
wrangler.toml?secrets are just encrypted env vars
they're available just like env vars
where is it not available?
oh, if I do secret put, I don't see them in dashboard > settings > env vars
I was expecting the KEYs to be visible as plain text and value to not be visible
>where is it not available?
since I am not accessing it directly, I believe they aren't available in the runtime
they do show there yep
ah, okay, didn't show up for me
if you don't see them, that indicates a different problem
e.g. setting in the wrong environment or something
what's your wrangler.toml?
almost the default one, deploy is happening to the correct environment/project
literally just this
ok that'll be why
it's a pages project not worker
secret put is for workers
you'll need to set it in the dashboard
ah okay 🥹 ! thanks for the help, i totally wouldn't have figured this out
woud be so nice if wrangler can fail as it can detect that I am using put in a pages project
cc: @petebd this has been a common confusion since we added wrangler.toml - maybe we should add a warning here?
and point me to the correct place!
IMO this is a bug.. "wrangler secrets put" actually created a brand new worker from a wrangler.toml that is a pages project and put the secrets there! It should fail instead
Unknown User•6mo ago
Message Not Public
Sign In & Join Server To View
I will file an issue tomorrow!
By the way for the original request, do you need to use .dev.vars file instead of .env?no, I just needed to place the secrets in runtime and I incorrectly thought secrets aren't env var (because they were going to a worker that I didn't know existed) so my issue is sorted, will create a ticket tomorrow and link here
This error message from Prisma is outdated correct? As we concluded in this thread, env vars/secrets are available in the edge runtime as normal environment variables
(since I am using pages, it is surely mislabeled as workers, but I want to know if this is true for workers or not)
https://community.cloudflare.com/t/how-to-access-environment-variables-from-libraries/480041/3
Based on this, I think in workers secrets are not global env vars unlike pages!
Since this code is running in pages context, I think prisma is incorrectly judging it as worker and throwing early
In pages, env vars are available and I should not need to pass the datasource directly to Prisma (so this feels like a bug in Prisma)
AHA! soooooooooo in Remix template, if I have a route in functions/*, I can't run it locally but it can read env vars like normal and gets deployed successfully
BUT if I have a API route via Remix (app/routes/api.health.ts).. then it can't read the env like normal and has to come via loader + Cloudflare context env!
(I guess this is expected but pretty confusing! 😅)
and then whenever I need cloudflare env context, I need to use .dev.vars in addition to .env
don't know if there are plans to somehow unify .env / .dev.vars
Here is the relevant issue: https://github.com/cloudflare/workers-sdk/issues/6217
GitHub
🐛 BUG: wrangler should fail if secrets put is used in a pages proje...
Which Cloudflare product(s) does this pertain to? Pages What version(s) of the tool(s) are you using? 3.57.1 What version of Node are you using? v18.18.1 What operating system and version are you u...