.env.development.local • Simple & Latest
A robust application fails fast when critical configuration is missing. A simple validation library can be built to check for required environment variables during the build or startup process. The following example uses the zod library to define a schema and validate that all required variables are present and of the correct type:
CRA popularized this pattern.
# --- DATABASE CONFIGURATION --- # Local database connection (different from staging/production) DATABASE_URL="postgresql://user:password@localhost:5432/my_dev_db" # --- API KEYS & SECRETS --- # Personal API keys for local testing STRIPE_SECRET_KEY="sk_test_51Mz..." AWS_SECRET_ACCESS_KEY="your-local-dev-key" AUTH_SECRET="a-very-long-random-string-for-local-auth" # --- APPLICATION SETTINGS --- # Local API endpoint overrides NEXT_PUBLIC_API_URL="http://localhost:4000/api" DEBUG=true # --- THIRD-PARTY SERVICES --- # Local-only sandbox credentials MAILTRAP_USER="your_mailtrap_user" MAILTRAP_PASS="your_mailtrap_password" Use code with caution. Copied to clipboard Key Rules for This File
# .gitignore .env.local .env.development.local .env.production.local Use code with caution. Common Use Cases
Later files override earlier files. If the same variable exists in .env and .env.development.local , the value in .env.development.local takes precedence. .env.development.local
If you are building a plain Node.js backend using Express, native environment loading of tiered files doesn't happen automatically. You will need a package like dotenv-flow instead of standard dotenv . javascript
Most modern build tools follow a specific precedence order when loading environment variables from files. A typical hierarchy (from lowest to highest priority) looks like this:
Implementing this file in your project is straightforward. Follow these steps to set it up correctly. Step 1: Create the File
Name your variables clearly, such as STRIPE_SECRET_KEY_DEV . A robust application fails fast when critical configuration
Managing this complexity is a fundamental challenge. A developer's database should be an isolated local instance, while production relies on a secure cloud database. API keys and secret tokens for a local development server are different from the critical secrets used in production. If configuration files are shared across environments, a developer might inadvertently commit a production API key to a repository or, conversely, deploy a local configuration to a live server, causing catastrophic failures.
(Default settings for all environments committed to Git) Why Use .env.development.local?
By correctly leveraging .env.development.local , you ensure a flexible, seamless local building experience that keeps production secrets safe and allows team members to customize their workflows without stepping on each other's toes.
I can provide the exact code snippets and naming conventions for your setup. Share public link # --- DATABASE CONFIGURATION --- # Local database
// Vite syntax const stripeKey = import.meta.env.VITE_STRIPE_PUBLIC_KEY; // Next.js / Node syntax const dbUrl = process.env.VITE_DATABASE_URL; Use code with caution. Best Practices for Managing .env.development.local
It allows you to override default settings (defined in .env.development or .env ) without changing the code for other team members [3jop].
Never store private keys, database passwords, or API secrets in environment variables that will be exposed to the client side. While a prefix like NEXT_PUBLIC_ is a convenience, its purpose is to mark a variable for the client; it doesn't imply security. Conversely, a variable without a prefix is not automatically secure either. Client-side code, by its nature, is visible to anyone, so no secret should ever be passed into it, regardless of how it is named.
