When you start building with AI tools and APIs, you will quickly run into instructions that say "add your key to your environment file." If you have not used one before, that can feel like a gap. This guide explains what an environment file is, how it works, and why it matters for keeping your credentials safe.
What is an environment file?
An environment file is a simple configuration file, typically named .env, that stores key-value pairs your application needs at runtime. Each line has the format VARIABLE_NAME=value. When your application starts, a library like python-dotenv (Python) or dotenv (Node.js) reads the file and loads those values into the process's environment, where the application code can read them using os.environ or process.env.
The format is straightforward and provider-agnostic. AI projects typically use environment files to store API keys for services like Anthropic, OpenAI, or Google, along with database URLs and other configuration that changes between environments.
Why do environment files matter for AI projects?
The alternative to an environment file is putting configuration values directly in your code. That creates two serious problems.
First, it means your credentials are in your source files. The moment those files are committed to a repository, the credentials go with them. GitGuardian found that 70% of secrets leaked to public repositories are still valid three years after exposure. Even private repositories can be exposed through mis-configured permissions or future visibility changes.
Second, hardcoded values are inflexible. When you need to switch from a development key to a production key, you have to edit code. Environment files let you change configuration without touching the application.
Environment files also support multiple environments cleanly. You can maintain separate .env.development, .env.staging, and .env.production files with different values for each context, giving each environment its own credentials and limits.
How do I use an environment file correctly?
Create .gitignore first. Before you create your .env file, add .env to your .gitignore. This prevents the file from ever being committed. Once a credential is in Git history, removing it completely is difficult and disruptive.
Use .env.example for documentation. Create a second file called .env.example that lists all the variable names your application needs but with placeholder values instead of real credentials. Commit this file. It tells other developers what to configure without exposing anything real.
Load the file at startup. In Python, install python-dotenv and call load_dotenv() at the start of your application. In Node.js, install dotenv and call require('dotenv').config() before any other code runs.
Never log your environment variables. Debug logging that prints all environment variables will expose any secrets stored there. Log variable names if needed, not values.
What are common mistakes to avoid?
- Creating the
.envfile before adding it to.gitignore - Committing
.env.examplewith real credentials instead of placeholder values - Sharing
.envfiles over Slack, email, or other unsecured channels - Using the same
.envfile for development and production - Not restricting file permissions so other users on the machine cannot read it