Finally! Does the usage of variables consume sub-requests, just like KV does?
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: https://developers.cloudflare.com/workers/about/limits/#environment-variables
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.
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
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.
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?