We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design Masterclass · Devops Cicd
Free preview: the first 2 parts of this 7-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Devops Cicd
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
A developer deployed a new version to production. The application connected to the staging database instead of production. Why? The database URL was hardcoded in a config file, and someone had changed it for testing and forgotten to revert it before deploying. The production deployment served stale staging data to customers for 20 minutes before anyone noticed.
In 2017, a GitLab employee accidentally ran a database deletion command against production instead of staging. The root cause: the two environments looked identical in the terminal, and there was no configuration safeguard preventing destructive commands in production.
Configuration management separates configuration from code. Database URLs, API keys, feature flags, and environment-specific settings are injected at runtime, not baked into the build. The same build artifact runs in development, staging, and production with different configurations.
The Twelve-Factor App principle: store config in the environment.
| Approach | Pros | Cons |
|---|---|---|
| Environment variables | Simple, universal, works everywhere | No structure, no validation, hard to manage at scale |
| Config files per environment | Structured, version-controlled | Risk of committing secrets, manual management |
| Config server (Consul, Spring Cloud Config) | Centralized, dynamic updates, auditable | Additional infrastructure to manage |
| Secrets manager (Vault, AWS Secrets Manager) | Encrypted at rest, access control, audit logging | Requires cloud provider or self-hosted Vault |
What goes where:
| Configuration Type | Where to Store It |
|---|---|
| App behavior (port, log level, timeouts) | Environment variables or config files |
| Feature flags | Feature flag service (LaunchDarkly, Flagsmith) |
| Secrets (API keys, passwords, TLS certs) | Secrets manager (Vault, AWS Secrets Manager) |
| Infrastructure config | IaC files (, Pulumi) in Git |
| Dynamic tuning (rate limits, cache TTLs) | Config server (Consul, etcd) with hot reload |
Validation is critical. If the application starts without a required config value, it should fail immediately with a clear error, not silently use a default that causes subtle bugs in production. Validate all configuration at startup. Libraries like envalid (Node.js) and pydantic-settings (Python) enforce this.
When NOT to use environment variables. When configuration is complex and hierarchical. A flat list of 200 environment variables becomes unmanageable. Use a structured config file loaded from a config server, with secrets injected from a secrets manager.