Configuration and secrets

Beginner 8 min read

Keep settings and secrets out of the code, so one build runs safely in every environment.

Why it matters

A password in the code ends up in Git, in CI logs and on every laptop. Configuration read from the environment lets the same build run in development, staging and production — each with its own values.

Where it fits — Configuration applies across these stages

What you will learn

Separate code, configuration and secrets.
Read settings from environment variables.
Know what to do when a secret leaks.

Before you start

Git basics✓ Learned

Code, configuration, secrets

Code — the same everywhere; lives in Git.
Configuration — differs per environment (database host, feature switches); comes from the environment.
Secrets — configuration that grants access (passwords, API keys, tokens); comes from a secret store and is never committed.

.env.example

APP_ENV=local
DATABASE_URL=postgres://localhost:5432/app
PAYMENT_API_KEY=   # ask the team lead; never commit the real value

Commit an example file with empty secret values; list the real .env in .gitignore.

Example

import os

database_url = os.environ["DATABASE_URL"]        # required: fail fast if missing
debug = os.environ.get("DEBUG", "false") == "true"

Watch out: If a secret was committed, pushed or pasted somewhere public, rotate it: create a new one and revoke the old. Deleting the file is not enough.

Official documentation and references

Guides

OWASP Secrets Management Cheat Sheet ↗ Official · OWASP
The Twelve-Factor App — Config ↗ 12factor.net — The classic short argument for configuration in the environment.

Reference

OWASP Top 10 ↗ Official · OWASP — The most common web application security risks.

Learn next

Automated tests ›✓ Learned

Git basics✓ Learned
Containers with Docker✓ Learned
CI/CD pipelines✓ Learned

Done with this topic?

Reviewed 2026-10-23. Links go to the official documentation unless marked otherwise.