exit lab
DevOps learning path
BeginnerEnvironment

Environment Variables

How config and secrets move between local dev, CI, and production without being committed to Git.

30 min

Overview

Environment variables inject configuration (database URLs, API keys, feature flags) into an application at runtime, keeping it out of the source code and letting the same build behave differently in dev, staging, and production.

Why it matters

A Docker image or a compiled JAR should be identical across environments — what changes is configuration, not code. Environment variables are how you achieve that without rebuilding the app per environment.

How backend developers use it

Spring Boot reads application.properties with ${VAR_NAME} placeholders, so spring.datasource.password=${DB_PASSWORD} pulls from the environment at startup instead of being hardcoded. Locally, a .env file (gitignored) holds development values; in CI and production, the platform's secret manager injects the real ones.

Common mistakes

Warning

Committing a .env file with real values — .env.example with placeholder keys and no real secrets is what belongs in the repo.

Warning

Reading a required variable without validating it exists, so a missing env var fails silently deep in application logic instead of at startup with a clear error.

Warning

Storing a secret in a variable name that suggests it's not sensitive (API_URL when it actually embeds a key) — name the sensitive ones obviously.

Warning

The same database URL environment variable pointing at production, accidentally, from a developer's local .env — always double-check which environment a connection string actually points to before running anything destructive.

Example commands

Reference an env var in application.properties

spring.datasource.password=${DB_PASSWORD}

Set a variable for one command (shell)

DB_PASSWORD=secret ./mvnw spring-boot:run

Load variables from a .env file (Compose)

env_file:
  - .env

Resources

Retrieval check

Before you continue

  • Explain what this tool or practice changes in the delivery lifecycle.
  • Name one common failure it helps you diagnose or prevent.
  • Repeat one example command from memory, then verify it.