Environment Variables in Production

# Environment Variables in Production Environment variables keep configuration and secrets out of your codebase, but managing them carelessly in production creates real security and reliability risks. ## What Belongs in Environment Variables API keys, database connection strings, and environment-specific URLs (staging vs production) belong here — never hardcoded directly in source files. ``` DATABASE_URL=postgres://user:pass@host:5432/db JWT_SECRET=your-secret-key NEXT_PUBLIC_API_URL=https://api.example.com ``` ## Never Commit .env Files `.env` files containing real secrets should always be in `.gitignore`. A common and costly mistake is committing a `.env` file once, then removing it later — the secret remains in git history and should be treated as compromised. ## Client-Exposed vs Server-Only In frameworks like Next.js, only variables explicitly prefixed (`NEXT_PUBLIC_`) are sent to the browser. Anything else stays server-side — mixing this up can accidentally leak a secret key into client-side JavaScript. ## Using a Secrets Manager For larger production systems, dedicated tools like AWS Secrets Manager or Vercel's environment variable dashboard are safer than plain `.env` files on a server, since they support access control and rotation. ## Validating Required Variables at Startup ```javascript if (!process.env.DATABASE_URL) { throw new Error("DATABASE_URL is not set"); } ``` Failing fast at startup is much easier to debug than a mysterious failure deep inside application logic caused by a missing variable. ## Conclusion Environment variables are simple in concept but a common source of real security incidents when secrets are exposed or mismanaged — treat them with the same care as passwords, because that's effectively what they are.