Should You Still Use python-dotenv in 2026?27kTalk to an expertGet started for free

27k starsTalk to an expertGet started for free

← Back<br>Blog post • 10 min read<br>Should You Still Use python-dotenv in 2026?

Published onMonday, July 27, 2026

Every Python project eventually needs to use secrets like database passwords or API keys, which the app needs at runtime. But those credentials should never sit in the source code where anyone with repo access (or a leaked copy of it) could read it.

The fastest way to get something working is to hard-code the value into the file that needs it, and that's exactly the problem: the moment that file is pushed, the key is public, and it stays public in the Git history even after the line is deleted, which creates vulnerabilities.

Most projects solve this by getting the value out of the code entirely. First it goes into an environment variable, a piece of configuration the operating system hands to the running program, read in Python with os.environ, the standard library's dictionary-like view of whatever variables are set in the current process.

That works until manually setting half a dozen of these by hand every time gets tedious, which is usually the point where python-dotenv shows up: a small library that reads a .env file (a plain text file of KEY=value lines) and loads it into the environment automatically, so nobody has to type export before every session. That progression works fine for a solo project. It starts to strain the moment a second developer, a second environment, or a production deployment enters the picture.

The Python ecosystem has the same habits, and the same breaking point as any dotenv solution. so it's worth asking directly: should you still be reaching for python-dotenv in 2026?

How Python projects handle environment variables today

Most Python codebases handle secrets via a few patterns, usually in this order as the project grows:

os.environ and os.getenv() are the standard library baseline. No dependencies, no configuration, just whatever variables are already set in the process environment:

import os

database_url = os.environ["DATABASE_URL"]<br>debug = os.getenv("DEBUG", "false") == "true"

This works well until a developer has to manually set half a dozen variables in their shell every time they start the app locally.

python-dotenv fixes that friction. A .env file sits in the project root, and load_dotenv() reads it into os.environ before the rest of the app starts:

from dotenv import load_dotenv<br>import os

load_dotenv()<br>database_url = os.environ["DATABASE_URL"]

This is why python-dotenv became close to a default. It’s a convenience layer that turns a text file into environment variables, and the app code still reads those variables exactly the way it would without the file.

Then there’s pydantic-settings . It’s increasingly common in typed codebases and FastAPI apps. Instead of reading loose environment variables by name, a Settings class declares them as typed fields and validates that everything required is actually present at startup:

from pydantic_settings import BaseSettings

class Settings(BaseSettings):<br>database_url: str<br>debug: bool = False

settings = Settings()

pydantic-settings is effectively a wrapper around python-dotenv and works on top of the same .env file, it just adds validation and typing on the way in.

python-decouple . A smaller library that does the same job as python-dotenv with a different interface, separating configuration from code through a config() call that reads from a .env file or a settings.ini.

keyring is an entirely different category. It stores credentials in the operating system's native credential store, Keychain on macOS, Credential Locker on Windows, the Secret Service or GNOME Keyring on Linux. That makes it a reasonable fit for a CLI tool running on a developer's own machine. It's a poor fit for anything deployed to a server or a container, since there is usually no OS keychain for a headless environment to talk to.

Where python-dotenv and .env files break down for a team

None of those tools change what a .env file actually is: a plaintext file with your most sensitive credentials, sitting in a project folder. That's fine for a single developer’s hobby project, but gets harder to defend once a team, multiple environments, and a production deployment are all in play, and the problems aren't only about security. Some are just as much about the everyday friction of running a team.

.env files are leak-prone, in Python, Django, Flask, or anywhere else.

A .env file living in the project root is exactly the kind of file that ends up in a commit by accident, especially on a new teammate's first push before .gitignore habits are second nature, or if you’re using AI agents without checking their work.

This matters because a leaked DATABASE_URL or API key isn't a theoretical risk, it's a direct, usable credential. Public GitHub commits get scanned by automated bots within minutes looking for...