This hierarchy gives you maximum flexibility while maintaining security. You never need to commit sensitive values, and you never need to worry about accidentally overriding production credentials.
Environment variables are loaded into memory when the application server starts. If you modify .env.local , your running development server will not see the changes. You must completely stop your development server ( Ctrl + C ) and restart it (e.g., npm run dev ) to clear the old cache and inject the new variables.
export const env = databaseUrl: requireEnv('DATABASE_URL'), stripeSecretKey: requireEnv('STRIPE_SECRET_KEY'), authSecret: requireEnv('AUTH_SECRET'), as const; .env.local
By default, frameworks protect your environment variables by making them accessible only on the server environment. If you try to log process.env.API_SECRET_KEY in a browser-rendered React component, it will return undefined .
The security model of .env.local is based on . If you modify
# Local env files .env.local .env.*.local # Avoid committing actual secrets if you use standard naming .env Use code with caution. The .env.example Pattern
: The baseline. Often committed to the repository for "safe" defaults. If you try to log process
"I updated my .env.local file, but my app is still using the old values."
: Its primary "feature" is its absence from your repository. By placing sensitive credentials like API keys or database passwords here, you drastically reduce the risk of accidental leaks to GitHub or GitLab. Developer Autonomy
Essential for local development; dangerous if misconfigured; irrelevant for production.