s0sta
EN NL عربي
Filters
How to search
  • Plain words find names, texts and examples.
  • "two words" finds the exact phrase.
  • --name or -x finds an option.
  • #word looks only inside commands.
  • @grep finds lessons and labs that use grep.
  • Filters: cat:network · in:labs · in:notes · level:rhcsa · ch:8 · root:yes. Put ! before a word to leave it out. OR between words means one of them.
  • ↑ ↓ to move · Enter to open · Esc to close · / to search

DevOps basicsDevOps series

Environment variables vs a config service

Every platform eventually asks whether configuration belongs in environment variables or in a config service, and the argument usually starts with a strong opinion and no example.

Quick reference

ENV VARSCONFIG SVC
Where it livesIn the processIn a remote service
Change needsA restart or redeployA restart or reload
SecretsEasy to leak in CI logsScoped, audited access
VersioningGit history, if at allA version per change
Drift riskPer-host overridesOne source of truth
Best forSmall, static settingsMany environments, audit

ENV VARS (Keys in the process): Set by the shell, a manifest or CI, and inherited by every child process.

export DATABASE_URL=...

CONFIG SVC (Keys served at runtime): A managed API: versioned values, scoped per environment.

aws appconfig get-configuration
  • Env vars → local, cheap, easy to leak.
  • Config service → versioned, scoped, audited.

Explained

Where each one fits

Environment variables live in the process. The shell, a Kubernetes manifest or a CI job sets them, every child process inherits them, and a change means a restart or a redeploy. That is cheap and local, and it is why twelve-factor apps put config there.

A config service lives outside the process. A managed API versions values, scopes them per environment and records changes, and the app fetches them at boot or watches for updates. A change can reach a running service without a rebuild, and access is a permission rather than a file.

The rows in the picture

Where it lives is the process versus a remote service. A change needs a restart versus a reload. Secrets are easy to leak in CI logs versus scoped and audited. Versioning is Git history, if anything, versus a version per change. Drift risk is per-host overrides versus one source of truth. Best for is small static settings versus many environments with an audit requirement. The panel at the bottom repeats the split in one line each.

The honest caveat: a config service is another dependency on the boot path. Cache the last known good values and decide what happens when the service is unreachable, or a control plane outage becomes an application outage.

The lesson: use environment variables for the process, and a service for what must change without a deploy.

Config is a runtime concern.

More notes: DevOps basics

Open in the notes app: search, filters, copy This note on GitHub