Introducing Secrets and Environment Variables to Cloudflare Workers

Screenshot%20from%202019-08-27%2015-04-37

6 Likes

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.)

3 Likes

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.

3 Likes

Great, thank you.

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

2 Likes

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

1 Like

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?