How to Keep Passwords Out of Your Code With Environment Variables in the US

Typing a password straight into your code feels quick, and it works fine until the code is shared. The moment that file lands in a GitHub repository, a chat message, or a zip archive, the password goes with it. Environment variables solve this by keeping secrets outside your code entirely. Your program reads the secret at run time, and the secret itself never appears in a file you might commit.

What an environment variable is

An environment variable is a named value stored outside your code, in the environment where your program runs. Your code asks for the value by name, such as `DB_PASSWORD`, and the operating system hands it over. The code itself holds no secret, so you can share it, commit it, and publish it without leaking anything.

This is the same idea behind the advice to use `$DB_URL` instead of typing a database address and password into a command. A tool that saves the command only records the variable name, not the secret. Variables work the same way in Node.js, Python, shell scripts, and Docker, which makes them a habit worth building once and using everywhere.

Move a password into a .env file

A `.env` file is a plain text file that holds one variable per line in `KEY=value` format. Create one in your project folder and add your secrets there. Before you type a single secret into it, add `.env` to your project's `.gitignore` file. The order matters: ignore the file first, then fill it in, so a stray commit can never catch it.

A typical `.env` file looks like this:

DB_PASSWORD=your-database-password-here
API_KEY=your-api-key-here

Load it in Node.js with the dotenv package by calling `require('dotenv').config()` at the top of your entry file, then read values with `process.env.DB_PASSWORD`. In Python, install python-dotenv and call `load_dotenv()` before reading values with `os.getenv("DB_PASSWORD")`. In most recent versions of both tools, the setup is a single line, and your code never needs to know the actual secret.

Read variables in your code and commands

Once the secret lives in a variable, use the variable everywhere instead of the value. In a shell, set it for one session with `export API_KEY=your-key-here`, then pass it to a command as `$API_KEY`. When an AI coding assistant or a script asks to run a command with a secret, type the variable name, not the secret itself, so nothing sensitive is saved in a log or a settings file.

Docker has the same pattern built in. Pass variables with the `-e` flag, such as `docker run -e API_KEY=$API_KEY my-app`, or keep them in an env file and pass it with --env-file .env. In GitHub Actions, store secrets in the repository's Settings under Secrets and variables, then reference them as `${{ secrets.API_KEY }}` and assign them to environment variables in the workflow. The secret stays hidden in logs, and the workflow file holds only the reference.

One file per environment

Most projects need different values for development, testing, and production. Keep a separate file for each, such as `.env.local` for your machine and a production file managed by your hosting provider. Never copy production secrets into a development file, and never email a `.env` file to a teammate. Share secrets through a password manager or a secrets manager instead.

Commit a `.env.example` file with the same keys but placeholder values, such as `DB_PASSWORD=change-me`. New developers copy it to `.env` and fill in their own values, and the example doubles as a checklist of every variable the project needs. A placeholder in the example file is safe to commit because it is not a real secret.

When a secret slips through anyway

Even careful developers leak a secret now and then. If it happens, rotate first: change the password or revoke the key before you clean anything up. Then remove the secret from the code, add the file to `.gitignore`, and purge git history with git filter-repo or BFG Repo-Cleaner if the secret reached a repository. Turn on GitHub push protection so the next slip is blocked before it leaves your machine.

Check your own files too. Search your project for the secret, including settings files and saved chat logs from AI tools, and delete every copy that holds the real value. A secret saved in one place often has copies in others.

Beyond .env files

For solo projects, a `.env` file plus a password manager is enough. For teams, a secrets manager keeps things organized: tools such as 1Password, Doppler, AWS Secrets Manager, and HashiCorp Vault store secrets centrally and hand them to your code at run time. They also record who accessed what, which helps when a key needs rotating.

You do not need to adopt all of this at once. Start with one rule and keep it: no secret ever appears in your code. Move the secret into a variable, ignore the file that holds it, and let your code read the variable by name. That single habit prevents the most common way passwords end up public.

Frequently Asked Questions

Is a .env file safe on its own?

A `.env` file only protects your secrets if it is never committed, so adding it to `.gitignore` before you fill it in is the step that matters. A `.env` file is still plain text, so keep it on your own machine and share secrets through a password manager instead of sending the file around.

Can I commit a .env.example file?

Yes. A `.env.example` file holds the same keys with placeholder values, such as `change-me`, instead of real secrets. It is safe to commit and helps new developers see every variable the project needs.

What if I need the secret in a command?

Use the variable name, not the value. In a shell, write `$API_KEY` instead of the key itself, so any tool that saves the command records only the name. Set the variable with `export` first, or load it from your `.env` file, and the command works the same way.