A basic .env.development file looks like this:

# docker-compose.yml version: '3.8' services: api: build: . env_file: - .env.development ports: - "$PORT:3000" Now, running docker-compose up automatically injects your dev variables. You can create scripts that modify behavior based on the presence of .env.development .

| File Name | Typical Usage | | :--- | :--- | | .env | The fallback or default file. Contains base variables. | | | Loaded specifically during local development ( npm start or dev ). | | .env.production | Loaded when the app is built for production. | | .env.test | Loaded during unit/integration testing (e.g., Jest). |

In the modern world of software development, the line between "it works on my machine" and production failure is often drawn by one thing: configuration . Environment variables have become the industry standard for managing this configuration, and at the heart of this practice lies a specific, powerful file: .env.development .

# .env.development REACT_APP_API_URL=http://localhost:3001 REACT_APP_ENABLE_MOCKS=true Next.js supports .env.development natively but distinguishes between build-time and run-time variables. You must prefix browser-safe variables with NEXT_PUBLIC_ .