Introducing Secrets and Environment Variables to Cloudflare Workers



Finally! Does the usage of variables consume sub-requests, just like KV does?

1 Like

KV operations also do not count against the documented per-worker subrequest limit. Note that, per the docs, they do count towards the concurrent connection limit.

(KV operations are considered “in-house” subrequests, which have a separate, undocumented limit which is high enough that the worker is unlikely to be able to hit it without first hitting the 50ms CPU limit.)


Thanks, so this means the variables have the same limits and cost as KV?

Hi @thomas4, no, environment variables are unrelated to KV. The environment variable-specific limits are documented here:

The maximum number of environment variables (secret and text combined) for an account is 32 variables.

Each environment variable has a size limitation of 1kB.

Update: The quote above was accurate at the time of writing, but the size limit has since been increased. Refer to the documentation linked above for the latest size limit.

There is no additional cost to using environment variables, and they don’t involve any I/O. Instead, the environment variable is injected into the worker script’s global scope immediately prior to its top-level execution.


Great, thank you.

For us that use “secrets” on every page load, this could actually cut cost by several times over.


Can an alias for process.env.XXX be added for easier interoperability with node?


We need a higher size limit for secrets. Average Google Cloud key JSON is ~2.5KB, and PEM key in it alone is 1.6KB


Good point.

While you await an answer from Cloudflare, you could use KV for secrets, since they are encrypted at rest.

To add some extra security, you can store a secret that is a random long string and use it to access the KV namespace in the worker, which would make it impossible to guess the KV namespace name.

1 Like

I am also looking at storing PEM key into secure storage. I’m flip-flopping between using a secret env and using KV. KV is the easiest as it can store values with a length greater than 1K.

The issue I have is that the KV raw values are visible from the dashboard.

The issue I have with the SECRET is that, should I need to refresh it, it’s already embedded into and executing workers - ie. It’s not dynamically refreshed.

I’ll need to do some more reading to understand how to force a SECRET to be refreshed into the workers (re-publishing works).

In my implementation that uses the SECRET - I’ve simply split the PEM string into chunks - and the reassembled in the worker.

@negrusti, have you had any further thoughts?

The documentation link you provided states that the limit is 5kB. Which is correct? I believe you are correct, given that I am unable to upload a 2kB string as a secret.

Hi @declan, the documentation is correct – the current size limit is 5KB. I’ve updated my response above to make clear that it is out of date.

1 Like

Great thanks for the update. I have a funny issue, that may well be a bug in wrangler cli. I am unable to put a secret to the worker with a length of 2024 characters. If I keep the length of the variable to less than 1020, it is accepted. I have checked my shell ARG_MAX and it is 262144…
For now I have split the secrets to make it work.

Well, this is embarrassing. We had intended to lift the limit to 5kb, and did, but weren’t aware of all locations where the limit is enforced, and missed one. So, the limit is still effectively 1kb.

Hopefully we can finish lifting the limit soon; in the meantime, I’ve updated the docs back to 1kb. I apologize for the confusion.


@harris, you missed to update the docs at the summary table:

Please who is very experience in wrangler and worker configuration that can assist me on my configuration. And will be paid for, pls whatsapp me on {redacted}. Many thanks

Hey @harris,

Do you happen to have a update on this?