.env Example Generator

How to use .env Example Generator

1. Select your stack and the services you use.
2. Save the generated template as .env.example and commit it.
3. Copy it to .env, fill in real values, and confirm .env is git-ignored.
4. Add .env to .gitignore before the first commit, not after.
5. Variables prefixed NEXT_PUBLIC_, VITE_ or REACT_APP_ are compiled into the client bundle.
6. Restart the dev server after changing .env — most frameworks read it only at startup.

Commit .env.example, never .env

The convention that works: a committed .env.example listing every variable name with a placeholder or empty value, and a git-ignored .env holding the real ones. That gives a new developer a complete checklist without exposing anything, and it documents the configuration surface in the repository where it belongs. The failure mode is a .env committed once early in a project’s life — which puts the secrets in the history permanently, where ignoring the file afterwards does nothing.

If a secret was committed, rotate it

Removing it from the working tree does not remove it from history, and rewriting history means force-pushing every commit and breaking every clone — and forks, caches and third-party mirrors may keep a copy regardless. Assume anything pushed to a remote is compromised and rotate the credential. That is faster, more certain, and does not require coordinating with everyone who has cloned the repository.

Environment variables are not encrypted

They are readable by any process running as the same user, they appear in crash dumps and in some logging setups, and on a shared host they may be visible in the process table. They are a reasonable place for configuration and moderate secrets, and a poor place for anything truly sensitive in a shared environment. Production systems of any scale should use a secrets manager — Vault, AWS Secrets Manager, or the platform’s own — which adds rotation, audit logging and access control that a file cannot.

The client-side prefix that catches people out

Build tools expose variables to browser code only when prefixed: NEXT_PUBLIC_ in Next.js, VITE_ in Vite, REACT_APP_ in Create React App. That is a safety mechanism, and it cuts both ways — a secret accidentally given one of those prefixes is compiled into the JavaScript bundle and shipped to every visitor. Anything with PUBLIC in its name should be treated as published, because it is.