환경 변수와 비밀 정보 관리

A SaaS connects to databases, payment providers, and AI APIs — each with keys that differ per environment. Environment variables keep them out of code so one codebase runs anywhere.

Local config lives in a .env file as plain key-value pairs. It's loaded at startup and must never be committed to git.

Never commit secrets: add .env to .gitignore and ship a .env.example with empty values, so teammates know what to fill in without seeing real keys.

In Next.js, only variables prefixed NEXT_PUBLIC_ reach the browser bundle — everything else stays server-only. Never prefix a real secret, or every visitor sees it.

Read variables through process.env. Server code can access any of them; client code only ever sees the public, NEXT_PUBLIC_ ones.

A missing key should fail fast, not at 2am in production. Validate required variables on boot with a schema like Zod so problems surface immediately.

Next.js loads .env.local, then .env.development or .env.production. These per-environment files keep different values cleanly separated.

In production you don't ship a .env file. Set variables in your host's dashboard — Vercel, Render — so they're injected securely at runtime.

If a key leaks, rotate it: generate a new one, update your env store, redeploy. Because keys live outside code, rotation is quick and low-risk.

Watch for common leaks: logging full process.env, returning secrets in API responses, hardcoding keys as fallbacks, or committing a real .env.

Best practices: keep secrets in .env and out of git, expose only truly public values with NEXT_PUBLIC_, validate at startup, and store prod secrets in your host.

Test your secrets knowledge.

Recap: store config in .env and keep it out of git, use NEXT_PUBLIC_ only for safe values, validate at startup, and set prod secrets in your host.