Environment Variable Generator

New project, day one. You need DATABASE_URL, REDIS_URL, JWT_SECRET, SMTP_HOST, SMTP_PORT, SMTP_USER, SMTP_PASS, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, S3_BUCKET — and that’s just the backend. You copy-paste from a previous project’s .env, delete half the variables, misspell DATABSE_URL, and spend 20 minutes debugging the connection error. You need a builder that gives you framework-specific templates with the right variable names already filled in.

Why This Generator (Not the .env Validator)

PureDevTools has a .env Validator for checking existing .env files for syntax errors and comparing two files. This tool is for building new .env files from scratch — pick a framework template (Node.js, Django, React CRA, Next.js, Docker), add variables grouped by purpose, and export as .env, docker-compose.yml environment block, or shell export format. Everything runs in your browser; your secrets are never sent anywhere.

What Is the Environment Variable Generator?

The Environment Variable Generator is an interactive tool for creating and managing .env files — the standard way to configure application secrets and settings without hard-coding them into source code. Build your environment variable configuration visually: add variables, group them by purpose, pick a framework template, and export in the format your project needs.

Environment variables keep secrets (database passwords, API keys, JWT secrets) out of your codebase. Every twelve-factor application, Docker container, and cloud deployment relies on them.

How to Use This Tool

1. Choose a template — start with Node.js, Django, React CRA, Next.js, Docker, or blank
2. Add variables — click “Add Variable” to create a new key-value pair
3. Set the group — assign each variable to Database, Auth, API Keys, or General
4. Add comments — document each variable with an inline comment (toggle visibility in output)
5. Validate naming — the tool flags any key that violates UPPER_SNAKE_CASE convention
6. Choose export format — .env file, Docker Compose environment block, or shell export statements
7. Copy the output — one-click copy of the complete generated file

The .env File Format

A .env file is a plain-text configuration file read at application startup — never committed to version control. Each line follows the format KEY=VALUE:

# Database
DB_HOST=localhost
DB_PORT=5432
DB_NAME=myapp
DB_PASSWORD=secret123

# Auth
JWT_SECRET=your-jwt-secret-here
SESSION_SECRET=your-session-secret-here

Most frameworks load .env automatically: Node.js uses dotenv, Python uses python-dotenv, and Next.js has built-in support.

UPPER_SNAKE_CASE Naming Convention

Environment variable names must follow UPPER_SNAKE_CASE — all uppercase letters, digits, and underscores only:

The POSIX standard (IEEE Std 1003.1) defines that environment variable names consist solely of uppercase letters, digits, and underscores, and do not begin with a digit. The tool validates each key and shows an error for any violation.

Variable Groups

Organizing variables into groups makes .env files readable and maintainable in large projects:

Database

Connection parameters for your primary database and caches:

• DB_HOST, DB_PORT, DB_NAME, DB_USER, DB_PASSWORD
• DATABASE_URL (connection string format used by Prisma, SQLAlchemy, dj-database-url)
• REDIS_URL, MONGO_URI, ELASTICSEARCH_URL

Auth

Secrets for authentication, sessions, and token signing:

• JWT_SECRET, SESSION_SECRET, COOKIE_SECRET
• NEXTAUTH_SECRET, DJANGO_SECRET_KEY
• OAUTH_CLIENT_ID, OAUTH_CLIENT_SECRET

API Keys

Third-party service credentials:

• STRIPE_SECRET_KEY, SENDGRID_API_KEY, TWILIO_AUTH_TOKEN
• AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY
• SENTRY_DSN, GOOGLE_ANALYTICS_ID

General

Runtime configuration that is not a secret:

• NODE_ENV, PORT, HOST, LOG_LEVEL
• APP_URL, CORS_ORIGIN
• Feature flags, timeouts, limits

Framework Templates

Node.js / Express

NODE_ENV=development
PORT=3000
HOST=0.0.0.0

# Database
DB_HOST=localhost
DB_PORT=5432
DB_NAME=myapp
DB_USER=postgres
DB_PASSWORD=

# Auth
JWT_SECRET=
SESSION_SECRET=

# API Keys
API_KEY=

Load with the dotenv package:

require('dotenv').config();
// or in ESM:
import 'dotenv/config';

Python Django

Django uses python-dotenv or django-environ. The SECRET_KEY is critical — generate it with:

python -c "from django.core.management.utils import get_random_secret_key; print(get_random_secret_key())"

DJANGO_SECRET_KEY=your-50-char-secret-here
DJANGO_DEBUG=True
DJANGO_ALLOWED_HOSTS=localhost,127.0.0.1
DATABASE_URL=postgresql://user:password@localhost:5432/mydb

Load in settings.py with django-environ:

import environ
env = environ.Env()
environ.Env.read_env()
SECRET_KEY = env('DJANGO_SECRET_KEY')

React (Create React App)

CRA only exposes variables prefixed with REACT_APP_ to the browser bundle. All others are stripped at build time:

REACT_APP_API_URL=http://localhost:3001
REACT_APP_ENV=development
REACT_APP_GOOGLE_ANALYTICS_ID=G-XXXXXXXXXX

Access in JavaScript:

const apiUrl = process.env.REACT_APP_API_URL;

Warning: Never put secrets in REACT_APP_ variables — they are embedded in the client-side bundle.

Next.js

Next.js has two variable types:

• NEXT_PUBLIC_ prefix — exposed to the browser (safe for public values only)
• No prefix — server-side only (secure for secrets)

# Client-side safe
NEXT_PUBLIC_API_URL=https://api.example.com
NEXT_PUBLIC_APP_URL=https://myapp.com

# Server-side only (secrets)
NEXTAUTH_SECRET=
DATABASE_URL=postgresql://...
STRIPE_SECRET_KEY=

# .env.local — loaded for all environments, never committed
# .env.development — development only
# .env.production — production only

Docker

Docker can load .env files directly or use the environment: block in docker-compose.yml:

services:
  app:
    environment:
      - NODE_ENV=production
      - DB_HOST=db
      - DB_PASSWORD=${DB_PASSWORD}  # from .env file

Or use env_file to load your .env directly:

services:
  app:
    env_file:
      - .env

Export Formats

.env Format (Standard)

The universal format supported by dotenv, python-dotenv, Docker, and most platforms:

KEY=value
KEY_WITH_SPACES="value with spaces"
# Comment above the key
EMPTY_VALUE=

Docker Compose Environment Block

Ready to paste into the environment: section of docker-compose.yml:

environment:
  - DATABASE_URL=postgresql://user:pass@db:5432/mydb
  - REDIS_URL=redis://redis:6379
  - JWT_SECRET=

Shell Export Format

Bash/sh script to set variables in the current shell session or CI pipelines:

#!/bin/sh
export NODE_ENV=development
export PORT=3000
export DB_PASSWORD="my secret password"

Source it in your shell:

source ./env.sh
# or
. ./env.sh

Security Best Practices

Never commit .env to version control. Add it to .gitignore:

# Environment files
.env
.env.local
.env.*.local

Use .env.example as a template. Commit a .env.example with blank values for required variables — this serves as documentation without exposing secrets:

DB_PASSWORD=
JWT_SECRET=
STRIPE_SECRET_KEY=

Rotate secrets regularly. Treat leaked environment variables as compromised — rotate all secrets in the affected .env immediately.

Use secret managers in production. For production deployments, prefer secret managers (AWS Secrets Manager, HashiCorp Vault, Doppler) over .env files — they provide auditing, versioning, and fine-grained access control.

Never put secrets in REACT_APP_ or NEXT_PUBLIC_ variables. These are embedded in the client-side JavaScript bundle and visible to anyone who inspects your app’s source code.

Frequently Asked Questions

What is a .env file? A .env file is a plain-text file that stores environment variables for your application. Each line contains KEY=VALUE. Applications read it at startup using libraries like dotenv (Node.js) or python-dotenv (Python). The file is never committed to version control — instead, a .env.example template is committed with blank sensitive values.

Why must environment variable names be UPPER_SNAKE_CASE? The POSIX standard defines that portable environment variable names contain only uppercase letters (A-Z), digits (0-9), and underscores (_), and do not begin with a digit. While some shells accept lowercase, UPPER_SNAKE_CASE is the universal convention that works across all operating systems, shells, and deployment platforms without compatibility issues.

What is the difference between .env, .env.local, .env.development, and .env.production? In Next.js (and similar frameworks): .env applies to all environments and is committed; .env.local overrides for all environments and is gitignored; .env.development applies only when NODE_ENV=development; .env.production applies only when NODE_ENV=production. Local files (.local) always win and are never committed.

Should I quote values in .env files? Only when necessary. The dotenv spec allows optional quoting with single or double quotes. Values with spaces, #, or special characters need quotes: DB_URL="postgresql://user:pass@localhost/db". Empty values can be written as KEY= or KEY="".

What is the difference between environment variables and secrets managers? Both store configuration values, but .env files are file-based and require manual distribution. Secrets managers (AWS Secrets Manager, HashiCorp Vault, Doppler) are service-based — they provide versioning, audit logs, automatic rotation, and fine-grained access control. Use .env for local development; use a secrets manager in production.

Can I use comments in .env files? Yes. Lines starting with # are comments and are ignored by dotenv. Inline comments (after the value on the same line) are not universally supported — some parsers treat everything after # as a comment, others include it in the value. For safety, put comments on their own line above the variable.