.env.local.production -

The most common reason. You are about to deploy to AWS, Vercel, or Netlify. Your staging environment works flawlessly, but production fails mysteriously.

You need to run a production build on your local machine:

NODE_ENV=production npm run build

But you cannot use your live production database or live payment API keys on your laptop. You need a local "production-like" environment.

Enter .env.local.production:

# .env.local.production (not in Git)
DATABASE_URL="postgresql://localhost:5432/prod_mirror"
STRIPE_SECRET_KEY="sk_test_localDebugKey"
NEXT_PUBLIC_ANALYTICS_ID="debug-123"

This file allows you to simulate a production environment without touching real production secrets.

NEXT_PUBLIC_ANALYTICS_ID="UA-XXXXXXXX-X"

The .env.local.production file is a scalpel in a surgeon's hand—dangerous but precise. .env.local.production

Do use it when:

Do NOT use it when:

Remember the golden rule of environment variables: Never, ever commit secrets. Whether the file is called .env, .local, or .env.local.production, if it contains sensitive data, it belongs outside your repository. The most common reason

By mastering this naming convention, you unlock the full power of environment-aware configuration, moving from a "works on my machine" culture to a "works everywhere exactly as expected" engineering discipline.

If you are using dotenv directly:

require('dotenv').config( path: '.env.production.local' );

You must manually handle the loading order. But you cannot use your live production database