Env File Example: Ready-to-Use Templates

When a config value is hardcoded, a code change can turn into a secret leak or a broken deploy. A ready-to-copy env file example gives you a safer place to start. Below are templates for a web app, a database, and separate environments, plus a shareable example file and tips for keeping real secrets out of version control.

We analyzed 57 comments and questions from YouTube and Quora about example.ENV files and found that 19% mentioned protecting secrets stored in.env files.

Basic .env File Example for a Web App

A .env file is a plain-text file that holds settings outside your source code. The app reads those settings when it starts, then gets them through its environment. Most files use one KEY=VALUE pair per line.

Use uppercase names with underscores so keys are easy to spot. Keep each value on one line unless your loader clearly supports multiline values.

# App settings
APP_ENV=development
PORT=3000
LOG_LEVEL=debug

# Public app address
APP_URL=http://localhost:3000

# Private service key
PAYMENT_API_KEY=replace_with_a_local_test_key

Lines that start with # are comments. Quotes can help when a value has spaces, but parsers differ on quoting and variable expansion.

Use placeholders in examples, never working credentials. And don’t assume every parser handles inline comments or references like ${APP_URL} in the same way. If a value depends on another value, check the loader your app actually uses.

In Node.js, load the file before code reads process.env. With the dotenv package, add import 'dotenv/config' near the start of your entry point. Node.js also supports loading a file from the command line with node --env-file=.env app.js.

Then read a value like this:

const port = process.env.PORT ?? '3000';
const apiKey = process.env.PAYMENT_API_KEY;

Values are strings. Convert numbers and booleans in your app, and check required values when it starts. A missing key should produce a clear startup error, not fail later when a user submits a form.

If your team is still sorting out the basic terms, this explanation of what an env file is covers the role it plays in an app.

Environment-Specific .env File Examples

Use the same variable names in each environment, then set values for that environment. Your app can read DATABASE_URL in every case without branching on its name.

# .env.development
APP_ENV=development
DATABASE_URL=postgres://localhost:5432/store_dev
LOG_LEVEL=debug

# .env.test
APP_ENV=test
DATABASE_URL=postgres://localhost:5432/store_test
LOG_LEVEL=warn

# .env.production
APP_ENV=production
DATABASE_URL=replace_in_your_deployment_settings
LOG_LEVEL=error

Keep real passwords and tokens out of committed files. A common local pattern is to commit a safe .env.example, then keep .env.local on each developer’s machine. Some frameworks load files by mode; check your framework’s rules before relying on a custom filename.

For Node.js, choose the file in your start command, such as node --env-file=.env.development app.js. If you use a library that loads more than one file, confirm which value wins when keys repeat. Existing shell or deployment values may take priority over a file.

Container deployment tools may use environment files to pass values into a container. Here’s one pattern:

services:
  web:
    image: store-app
    env_file:
      - .env.development

Don’t put secrets in a Dockerfile with ENV or ARG. Values baked into an image can remain in image layers. Pass deployment secrets when the container runs, and keep each environment’s values separate.

Frontend builds need extra care. Variables configured for browser exposure can be included in browser code. Treat them as public. Put private keys on the server, not in a value meant for a web browser.

For a fuller layout, the guide to managing variables across environments shows how to keep names consistent while values change.

API and Database .env File Example

Database URLs and API credentials are common entries in a backend configuration file. Keep them grouped by service, and use a separate file for each environment when local work needs different values.

# Database connection
DATABASE_URL=postgres://app_user:local_password@localhost:5432/store_dev

# External API
PAYMENT_API_BASE_URL=https://api.example.test
PAYMENT_API_KEY=replace_with_a_test_key

# Session settings
SESSION_SECRET=replace_with_a_long_random_value
SESSION_TTL_SECONDS=3600

The sample password and key are placeholders. Don’t use them in a live service. Real database URLs may need special characters encoded in the password portion. If a connection fails only when the password contains symbols, check how your database client expects those characters to be escaped.

Keep variable names specific enough to show what owns them. A name like API_KEY can become hard to trace once an app talks to several services. Names such as PAYMENT_API_KEY or MAPS_API_KEY make it easier to match a value to the code that reads it.

Validate settings at startup. For example, check that DATABASE_URL and SESSION_SECRET exist before opening a server port. Parse numeric settings like SESSION_TTL_SECONDS into numbers, and reject values that don’t make sense for your app.

Frameworks can load env files for the app while leaving command-line tools out. A migration script or seed command may need its own loader, or a command such as node --env-file=.env.local scripts/seed.js. If a value works in the web app but is missing in a script, check that script’s startup path and working directory first.

For local testing, give each service a harmless test key. Keep production credentials in the deployment environment or a secrets manager. That way, running a seed script on a laptop won’t quietly point at a live database.

A Shareable .env.example Template

Commit a template that lists every required variable, but contains no real secrets. It gives new developers a clear setup checklist and helps the team notice when the app starts expecting a new key.

# Copy this file to .env.local and fill in local values.
APP_ENV=development
PORT=3000

# Required for the database
DATABASE_URL=

# Required for payment calls
PAYMENT_API_KEY=
PAYMENT_API_BASE_URL=https://api.example.test

# Used to sign sessions
SESSION_SECRET=
SESSION_TTL_SECONDS=3600

Use comments to say when a value is required and which service reads it. Don’t put a real key in a comment. A template is still tracked in version control, so treat every line in it as public.

Add ignore rules before creating your first local secrets file:

.env
.env.*
!.env.example

That pattern ignores the base file and environment-specific variants, while allowing the example to stay in version control. If a version-control system already tracks a secret file, adding an ignore rule won’t remove it from the repository’s history. Remove the tracked file and rotate any exposed credentials.

To make onboarding simple, tell teammates to copy .env.example to .env.local, then fill in their own values. If your app has several services, mark which keys belong to the API, worker, or frontend. Keep the names aligned across services when they refer to the same setting.

EnvManager’s variable import documentation describes the file formats it accepts, including standard dotenv files. That can help when a team is moving existing values into one shared workflow.

Securely Sync .env Values Across Local and CI/CD Environments

A local file is useful for development, but it gets harder to manage when each teammate keeps a separate copy. A key changes, someone forgets to update a CI job, and staging may end up using a value meant for another environment.

Keep a clear boundary between local, test, staging, and production values. Give each environment its own credentials, then scope access to the people and workflows that need them. Use your CI system’s secret settings for pipeline values instead of committing a secret file to the repository.

EnvManager is built for teams that want a shared place to manage encrypted environment values. We encrypt values with AES-256, support role-based access with per-environment read and write permissions, and track who changed what and when. Teams can sync secrets to local machines and CI/CD pipelines, so a change doesn’t depend on someone pasting a value into several dashboards.

For a local command that needs one secret, use this pattern:

envmanager run --only STRIPE_KEY -- npm run seed

The command scopes the requested value to the process it starts. For a CI job, use an environment-specific secret set and limit which jobs can access it. Avoid printing environment values in logs, even when the CI system masks known secret patterns.

EnvManager’s Pro plan is one flat price for the whole team, which can suit teams that want to avoid adding a per-seat charge as membership grows.

Before changing a shared value, identify the apps and jobs that consume it. Update the right environment, run the relevant test or deployment, then remove stale copies. If a secret reaches repository history or a build log, treat it as exposed and rotate it. Deleting the visible copy alone doesn’t make it safe again.

FAQ

What should an env file example include?

A useful example includes the variable names your app needs and safe placeholder values. Add comments that explain each required setting, such as the database connection or an API key. Don’t include working credentials. Commit the example file so teammates can copy it, then keep their real local values in an ignored file.

How do I load a .env file in Node.js?

Load it before your app reads process.env. You can use a dotenv library at startup or pass a file with Node’s --env-file command-line option. If a script still sees a value as missing, check that the loader runs first and that the process starts from the expected directory.

Should I commit a .env file to a version-control repository?

No, don’t commit a file that contains real credentials. Add local env files to .gitignore and commit a secret-free .env.example instead. If a real key was committed, remove the tracked file and rotate the key. A later deletion doesn’t erase the secret from earlier commits.

Can I use one .env file for development and production?

You can use the same variable names, but give each environment its own values. A local database URL should not point to production by accident. Use separate files for local work when your framework supports them, and set production values through your deployment platform or secrets manager.

Can I put secrets in a frontend .env file?

Only if the value stays on the server. Frontend build-tool prefixes or NEXT_PUBLIC_ can expose variables in browser code. Don’t put private API keys, passwords, or signing secrets behind those prefixes. Use public values there, such as a public API base URL.

Conclusion

Start with a committed .env.example, keep real values in ignored local files, and use separate credentials for each environment. If several people and pipelines need the same secrets, centralize access instead of copying values by hand. Next, compare your app’s required keys with its template and remove any real credentials from tracked files.