Updates to environment variables docs (managing multiple environments) #20728
Conversation
…ents, and adds more details to Secrets vs Environment variables
…gler configuration docs
korinne
requested review from
a team,
GregBrimble,
ToriLindsay,
WalshyDev,
irvinebroque and
mikenomitch
as code owners
|
Howdy and thanks for contributing to our repo. The Cloudflare team reviews new, external PRs within two (2) weeks. If it's been two weeks or longer without any movement, please tag the PR Assignees in a comment. We review internal PRs within 1 week. If it's something urgent or has been sitting without a comment, start a thread in the Developer Docs space internally. PR Change SummaryUpdated documentation for managing environment variables, including a new section for handling multiple environments and clarifications on the differences between secrets and environment variables.
Modified Files
How can I customize these reviews?Check out the Hyperlint AI Reviewer docs for more information on how to customize the review. If you just want to ignore it on this PR, you can add the Note specifically for link checks, we only check the first 30 links in a file and we cache the results for several hours (for instance, if you just added a page, you might experience this). Our recommendation is to add What is Hyperlint?Hyperlint is an AI agent that helps you write, edit, and maintain your documentation. Learn more about the Hyperlint AI reviewer and the checks that we can run on your documentation. |
github-actions
bot
assigned
GregBrimble,
irvinebroque,
mikenomitch,
ToriLindsay and
WalshyDev
src/content/docs/workers/configuration/environment-variables.mdx
Outdated
Show resolved
Hide resolved
| Environment variables are a type of binding that allow you to attach text strings or JSON values to your Worker. They are pass in via the [`env` parameter](/workers/runtime-apis/handlers/fetch/#parameters) in your Worker's [`fetch` event handler](/workers/runtime-apis/handlers/fetch/). | ||
|
|
||
| Text strings and JSON values are not encrypted and are useful for storing application configuration. | ||
| Text strings and JSON values are **not encrypted** and are useful for storing application configuration. If you need to store sensitive information (such as API keys or tokens), use [secrets](/workers/configuration/secrets/). |
There was a problem hiding this comment.
I know this "not encrypted" language was here before, but I'd love if we could provide some more details here around encryption behaviour—are these encrypted at rest?
|
|
||
| For local development with `wrangler dev`, variables in the [Wrangler configuration file](/workers/wrangler/configuration/) are automatically overridden by any values defined in a `.dev.vars` file located in the root directory of your worker. This is useful for providing values you do not want to check in to source control. | ||
| ### Overriding environment variables during local development | ||
| When running [`wrangler dev`](/workers/wrangler/commands/#dev), variables in the [Wrangler configuration file](/workers/wrangler/configuration/) are automatically overridden by any values defined in a **`.dev.vars` file** located in the root directory of your Worker. This is useful for providing values you do not want to check in to source control. |
There was a problem hiding this comment.
You can also have per-environment dev.vars files, which might be useful to mention here?
There was a problem hiding this comment.
There info in the partial secrets-in-dev.mdx
|
|
||
| - **Visibility:** Once you define a secret, its value is no longer visible in Wrangler or the Cloudflare dashboard. | ||
|
|
||
| - **Security:** Sensitive data, such as passwords and tokens, should always be encrypted to prevent accidental exposure. |
There was a problem hiding this comment.
"should always be encrypted" is a bit confusing here. That kinda implies that the user needs to encrypt it, but I think you're saying that sensitive data should be a secret because secrets are encrypted?
| ### When to use [plaintext environment variables](/workers/configuration/environment-variables) | ||
|
|
||
| [Secrets](/workers/configuration/secrets/) are [environment variables](/workers/configuration/environment-variables/). The difference is secret values are not visible within Wrangler or Cloudflare dashboard after you define them. This means that sensitive data, including passwords or API tokens, should always be encrypted to prevent data leaks. To your Worker, there is no difference between an environment variable and a secret. The secret's value is passed through as defined. | ||
| Plaintext environment variables are best for non-sensitive configuration details, such as hostnames and IDs. These are values that **do not** require encryption because leaking them does not compromise security or privacy. |
There was a problem hiding this comment.
I know plaintext is a term of art here, but is there for potential for confusion given env vars can also be json, not just text?
Co-authored-by: Somhairle MacLeòid <[email protected]>
9 participants
Summary
Adds new section for managing environment variables across multiple envrionments
Updates comparison to secrets and environment variables
[X ] The documentation style guide has been adhered to.