Environment Variables & Configuration

In one line

Environment variables are the standard way configuration and secrets reach an application at runtime, without hardcoding them into source code — and .env files are the conventional way to manage them locally.

0/3 · 0%

Think of it like this

Environment variables are like instructions given to an actor right before they go on stage, rather than instructions baked permanently into the script itself — the same script (application code) can behave differently each time depending on what's set beforehand, without ever needing to edit the script.

Key ideas

01
export VAR_NAME=value sets an environment variable for the CURRENT shell session and anything launched FROM it — echo $VAR_NAME reads it back. Without export, a variable assignment (VAR_NAME=value) is only a local SHELL variable, invisible to any program the shell subsequently launches — a genuinely common source of 'why isn't my app seeing this variable' confusion.
02
env (with no arguments) lists every environment variable currently set in your session — genuinely useful for confirming whether a variable your application expects is actually present before spending time debugging the application itself.
03
A .env file is a plain text convention (not a Linux feature itself, but adopted extremely widely) listing KEY=value pairs, one per line — tools like Node's dotenv package or Python's python-dotenv read this file and load its contents into the process's environment automatically at startup, so secrets and config never need to be hardcoded directly into source code.
04
.env files should almost always be listed in .gitignore (Phase 6/version control) — they typically contain real secrets (database passwords, API keys), and committing one to a shared repository is a genuinely common, genuinely serious security mistake. A .env.example file (with placeholder, non-secret values) is the standard way to document WHICH variables are needed without exposing any actual secret.
05
The twelve-factor app methodology (a widely-referenced set of best practices for building deployable services) specifically recommends STORING CONFIG IN ENVIRONMENT VARIABLES rather than in code — this is exactly why virtually every cloud platform (and Docker, from the earlier course) lets you set environment variables directly when deploying, rather than requiring a config file to be baked into the deployed artifact itself.

In your stack

→
A Spring Boot app reads application.properties values that can reference environment variables directly (spring.datasource.password=${DB_PASSWORD}), meaning the actual password lives only in the deployment environment's variables, never in a file committed to source control — exactly the pattern that keeps secrets out of the codebase entirely.

Code & diagrams

env-vars-and-dotenv.shmarkdown

The complete pattern: shell variables, .env files, and keeping secrets out of git.

# A plain shell variable is only visible to THIS shell
MY_VAR=hello
bash -c 'echo $MY_VAR'    # -> empty! not visible to the subshell

# export makes it visible to any process launched from this shell
export MY_VAR=hello
bash -c 'echo $MY_VAR'    # -> hello

# See every environment variable currently set
env | grep MY_VAR

# A typical .env file for local development
cat > .env << 'EOF'
DATABASE_URL=postgresql://localhost:5432/mydb
API_KEY=local-dev-key-not-real
DEBUG=true
EOF

# NEVER commit real secrets — .env belongs in .gitignore
echo ".env" >> .gitignore

# Document which variables are needed WITHOUT real values
cat > .env.example << 'EOF'
DATABASE_URL=
API_KEY=
DEBUG=
EOF

Explain it without notes

Why does 'VAR=value' without export sometimes fail to work as expected when a script or program tries to read that variable?

Why is it considered a serious mistake to commit a real .env file (with actual secrets) to a shared git repository?

Practice

Set a shell variable without export, confirm a subshell (bash -c) can't see it, then export it and confirm the subshell now can.

Create a .env and a .env.example for a small hypothetical project, and confirm you understand exactly which one should be committed to git and which one should not.

Trade-offs

↔
Environment variables are simple and universally supported, but they're all STRINGS (no native types) and can become unwieldy to manage once a project needs dozens of them — larger systems often layer a proper secrets manager (AWS Secrets Manager, HashiCorp Vault) on top, injecting values into the environment at deploy time rather than managing them by hand, while still ultimately handing the application plain environment variables it reads the exact same way.

Done when you can

I understand the difference between a plain shell variable and an exported one.
I can create and use a .env file, and I know why it must never be committed to git.
I know environment variables are the standard way production config and secrets reach an application.

Command Palette