What are environment variables and why shouldn't I commit my API keys?

Environment variables are configuration values supplied to your program by its environment rather than written into the code — so secrets live outside your repository, and the same code can run against different settings in development and production. First, the urgent part: **that key is compromised, so rotate it now.** Deleting the commit is not enough. Git history retains it, forks retain it, and automated bots scan public GitHub for exposed credentials within minutes of a push — this is an industry-wide, continuously running scrape, not a hypothetical. Go to the provider, revoke the old key, generate a new one. Only after that is worth worrying about cleaning history. What the exposure can cost, so the urgency is clear: cloud provider keys have generated five-figure bills for people whose keys were used to mine cryptocurrency, sometimes overnight. Payment and email keys can be used to send fraud in your name. Database credentials expose your users' data, which is a legal problem as well as a technical one. The correct setup: 1. Put secrets in a `.env` file at the project root: ``` API_KEY=abc123 DATABASE_URL=postgres://... ``` 2. Add `.env` to `.gitignore` **before** the first commit. This is the step that was missed. 3. Read them in code from the environment — `process.env.API_KEY` in Node, `os.environ` in Python — never as a literal. 4. Commit a `.env.example` with the *names* and dummy values, so collaborators know what's required without receiving your actual secrets. 5. In production, set the same variables in your host's dashboard (Vercel, Netlify, Render, AWS all have an environment variables section). Nothing secret is ever deployed as a file. One critical caveat people get wrong: in a front-end app, anything sent to the browser is public, regardless of how it was configured. A `NEXT_PUBLIC_`-prefixed variable, or any key referenced in client-side JavaScript, is visible in DevTools to every visitor. Secret keys must only ever be used from server-side code — if the browser needs data from a protected API, route the request through your own backend, which holds the key. Good habits going forward: enable secret scanning on your repositories, use a pre-commit hook or a tool like `gitleaks` to catch mistakes before they're pushed, and treat any key that has ever touched a public repo as burned. Everyone does this once; the professional difference is rotating immediately rather than hoping nobody noticed.