---
title: "What Is a .env File?"
description: "A .env file stores secrets like API keys outside your code so they never get published. Learn what it is, how it works and how to keep it safe."
type: "fundamental"
locale: "en"
category: "concepts"
canonical: "https://agenticschool.dev/fundamentals/what-is-an-env-file"
dateModified: "2026-06-12"
---

# What Is a .env File?

- Category: concepts
- Updated: 2026-06-12
- Keywords: .env file, environment variables, secrets, API keys, gitignore
- Canonical URL: https://agenticschool.dev/fundamentals/what-is-an-env-file
- Locale: en

> A .env file stores secrets like API keys outside your code so they never get published. Learn what it is, how it works and how to keep it safe.

A .env file is a plain text file that stores secrets and settings, like API keys and passwords, separately from your code so they never get published by accident. The name is short for "environment". Your app reads values from it at runtime, but the file itself is kept private and is never uploaded to GitHub. Getting this one habit right is the single best thing a beginner can do to avoid leaking a key.

## What goes in a .env file

A .env file is a list of name and value pairs, one per line. Anything sensitive or environment-specific belongs here rather than hard-coded in your source files.

```bash
OPENAI_API_KEY=sk-your-secret-key
DATABASE_URL=postgres://user:pass@host/db
SITE_URL=http://localhost:3000
```
Each line is NAME=value. No quotes are needed for simple values.

## The golden rule: keep it out of Git

The whole point of a .env file is that it stays private. You make sure Git never tracks it by listing it in a .gitignore file. The rule is absolute: secrets go in .env, .env goes in .gitignore, and a key never appears in code that gets committed.

```bash
# .gitignore
.env
.env.local
```
Listing .env here tells Git to ignore it so it is never uploaded.

## In production

On a real deployment you do not upload your .env file either. Instead you set the same names and values as "environment variables" in your hosting dashboard, for example in Vercel. That way production has its own separate keys, and a mistake in development can never touch live data.

## Common beginner confusions

A frequent mix-up is between the secret value and its name. Your code refers to the name, like OPENAI_API_KEY, and the real secret only lives in the .env file and the host dashboard, never in the committed code. Another is the difference between a .env file (for secrets and settings) and .gitignore (the list of things Git should never track); they work together but do different jobs. If you ever do accidentally commit a key, do not just delete the line and move on. Treat the key as compromised, rotate it by generating a new one in the provider dashboard, and the old one becomes useless to anyone who saw it. Getting into this habit early means a slip is a minor annoyance, not a disaster.

## FAQ

### Why should I never commit a .env file?

Because it holds secrets like API keys. If it lands on GitHub, anyone who finds it can use your keys and run up costs or access your data. Always list .env in .gitignore.

### How does my app read the .env file?

Frameworks load it automatically and expose the values as environment variables your code can read. You reference a value by its name, never by pasting the secret into your code.

### What do I do with secrets in production?

Set them as environment variables in your hosting dashboard, such as Vercel, rather than uploading the file. Production gets its own separate keys, kept apart from development.