Understanding .env.dev: A practical guide to development environment variables

What is a .env.dev?

A .env.dev is a convention for storing development-specific environment variables in a plain text file. It’s not a universal standard, but many projects use a file named .env.dev to keep settings that differ from production. This file is typically used alongside a general .env file and other environment-specific files like .env.local or .env.production.

How it works

Environment variables are loaded at runtime by a library or framework. Common patterns include:

• In Node.js, using the dotenv package: dotenv.config({ path: '.env.dev' }).
• In Python, using python-dotenv: load_dotenv('.env.dev').

The key idea is that the application reads variables from the file so you don’t have to set them in your shell every time you run the app.

Why a separate development file?

Separating development-specific variables helps keep production values safe and distinct. It also makes onboarding easier: new teammates can copy a template and customize locally without risking production secrets. Using a dev-specific file reduces the chance of accidentally leaking secrets when sharing code or configurations.

Where and how to load .env.dev

The exact mechanism depends on your tech stack, but the pattern is similar:

• Load the file early in startup so subsequent code can read process.env or equivalent.
• Favor explicit paths over relying on a global default, so development and production stay separate.

Example approaches:

• Node.js: require('dotenv').config({ path: '.env.dev' }).
• Python: from dotenv import loaddotenv; loaddotenv('.env.dev').

If your framework has built-in support for environment files, check its docs for how to specify an environment-specific path.

Best practices for .env.dev

• Do not commit .env.dev to version control. Add it to your .gitignore.
• Provide a template file, e.g., .env.example, so teammates know which keys are needed.
• Keep secrets out of the file when possible; use placeholders and local credentials instead.
• Use clear, consistent naming for keys (e.g., DBHOST, APIKEY).
• Document any non-obvious variables in your project’s README or the .env.example.
• Consider using a secret management tool or local vault for highly sensitive values, even in development.
• If you share the repository, ensure that secrets aren’t accidentally introduced by plugins or CI configurations.

Getting started: a quick example

Create a .env.dev with content like:

DBHOST=localhost DBUSER=dev DBPASSWORD=devpassword APIBASE_URL=http://localhost:3000/api

Then load it in your app as described above:

• Node.js: require('dotenv').config({ path: '.env.dev' }).
• Python: load_dotenv('.env.dev').

This lets your app read the values via process.env or os.environ without hardcoding them.

Security considerations

• Never commit real credentials or production keys in any environment file. Use placeholders in templates and provide real values only on local machines.
• Review who has access to development secrets and rotate them as needed.
• If you accidentally commit a secret, rotate it immediately and revoke the exposed credential.

By treating .env.dev as a controlled, local resource, you can keep development environments predictable while reducing risks to production systems.