Pick your stack — get a commented, production-ready .env boilerplate instantly.
Copy it or download it as a .env file.
Select your stack:
A .env file (short for environment file) is a plain-text configuration file used to store environment-specific variables — things like database credentials, API keys, application URLs, and feature flags. Rather than hardcoding these values directly in your source code, you place them in a .env file and your application reads them at startup. This makes it trivial to run the same codebase in development, staging, and production with completely different settings, without changing a single line of code.
Because a .env file often contains secrets — database passwords, third-party API keys, encryption keys — it should never be committed to version control. Add .env to your .gitignore immediately when you start a new project. Instead, commit a .env.example file with all the same variable names but with empty or placeholder values, so teammates know exactly what variables they need to configure without exposing any real secrets.
.gitignore from day one. A leaked API key or database password can cause serious security incidents and is a very common source of data breaches..env, add the key (with a blank or placeholder value) to .env.example too — then commit .env.example..env file to a server..env.testing and .env.production. Node.js / Next.js support .env.local, .env.development, and .env.production out of the box.APP_KEY, JWT_SECRET, and similar values as passwords — rotate them if you suspect exposure, and use a secrets manager for anything business-critical.Laravel reads the .env file via the vlucas/phpdotenv package. The most important variable unique to Laravel is APP_KEY — a 32-character base64-encoded key used for all encryption (sessions, cookies, encrypted model fields). It is never auto-populated; you must run php artisan key:generate after creating your .env. Laravel also caches the config for performance in production — run php artisan config:cache after any .env changes on a production server.
Node does not load .env automatically. The industry standard is the dotenv package — call require('dotenv').config() (or import 'dotenv/config' for ESM) at the very top of your entry file. All variables become available as process.env.VARIABLE_NAME. Never use dotenv in production — inject variables directly from your platform or CI/CD pipeline instead.
Next.js has built-in .env support with an important distinction: only variables prefixed with NEXT_PUBLIC_ are exposed to the browser bundle. Variables without that prefix are server-side only and are never sent to the client. This is a deliberate security boundary — never put a secret in a NEXT_PUBLIC_ variable, because it will be visible in your compiled JavaScript. Use .env.local for local overrides that are never committed, even in a public repository.
Vite uses a similar prefix convention: only variables prefixed with VITE_ are embedded into the client bundle and accessible via import.meta.env.VITE_VARIABLE. Variables without the prefix are excluded from the build entirely. For Create React App (CRA) projects the prefix is REACT_APP_ instead. Like Next.js, never put secrets in prefixed variables.
Django does not read .env natively. The most popular solution is django-environ or python-decouple. The critical variables are SECRET_KEY (used for CSRF, sessions, and signed cookies — generate a fresh value for every project) and ALLOWED_HOSTS (a comma-separated list of domains your Django site will serve — must be set correctly in production or Django will refuse all requests).
No — never. Add .env to your .gitignore file immediately. If you accidentally commit a .env containing real credentials, treat those credentials as fully compromised and rotate them right away. Even after removing the file in a later commit, the secrets remain visible in your git history. Commit .env.example instead, which contains the same variable names with placeholder values so teammates know what to configure.
APP_KEY is a 32-character random key Laravel uses to encrypt and decrypt data — including encrypted cookies, sessions, and any model attributes marked with encrypted:cast. Without it, Laravel will throw an error on startup. Generate it by running:
php artisan key:generate
This writes the key directly into your .env file. Never share your production APP_KEY — if it leaks, an attacker can forge signed cookies and decrypt your data.
.env holds your real secrets and environment-specific values. It is gitignored and stays on your local machine (or is injected by your hosting platform in production). .env.example is a template with all the same variable names but with empty or placeholder values — it is committed to the repository so that anyone cloning the project knows exactly what variables to configure. A common workflow: clone the repo, copy .env.example to .env, and fill in your local values.
Next.js runs in two environments: the server (Node.js) and the browser. Variables without NEXT_PUBLIC_ are available only on the server — they are never included in the JavaScript bundle sent to the browser. Variables prefixed with NEXT_PUBLIC_ are inlined into the client bundle at build time and become accessible from browser code via process.env.NEXT_PUBLIC_*. This is a deliberate security boundary: use NEXT_PUBLIC_ only for values you're comfortable being visible in the page source, such as a public API base URL. Never put API secrets, private keys, or database URLs in a NEXT_PUBLIC_ variable.
Yes. Most frameworks support environment-specific overrides:
.env.testing is automatically loaded when running php artisan test. You can also use APP_ENV=production and point to a .env.production file..env.local (never committed, highest priority), .env.development, .env.production, and .env.test out of the box. .env.local overrides all others..env.development is loaded by vite dev, .env.production by vite build.python-decouple and pass different .env file paths, or set variables directly in your deployment environment.