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”
In 2020, a developer at a startup committed their production database credentials directly in the code: const DB_PASSWORD = "SuperSecret123". The repository was public. A bot scanning GitHub for exposed credentials found it within 11 minutes. Within an hour, the database had been wiped and a ransom note left in its place.
This happens more often than anyone wants to admit. GitHub reports that millions of secrets (API keys, passwords, tokens) are committed to public repositories every year. GitGuardian's 2023 report found 10 million new secret occurrences in public commits in a single year.
Environment variables solve this by separating configuration from code. Instead of hardcoding DB_PASSWORD = "SuperSecret123", your code reads process.env.DB_PASSWORD. The actual value lives outside the codebase, set differently in each environment. Development uses a local database. Staging uses a staging database. Production uses the production database. Same code, different configuration.
An environment variable is a key-value pair set in the operating system's environment, accessible to any process running in that environment.
| Environment | DATABASE_URL | API_KEY | LOG_LEVEL |
|---|---|---|---|
| Development | postgres://localhost/myapp_dev | test_key_123 | debug |
| Staging | postgres://staging-db/myapp | stg_key_456 | info |
| Production | postgres://prod-db/myapp | prod_key_789 | warn |
The Twelve-Factor App (a methodology for building SaaS applications) makes environment variables its third principle: "Store config in the environment." The reasoning: config varies between environments, code doesn't. Separating them means the same code artifact can run anywhere.
Setting environment variables:
.env file (loaded by dotenv libraries), shell export, or IDE configurationCritical rule: Never commit .env files to version control. Add .env to .gitignore on day one. Provide a .env.example with placeholder values so new developers know which variables are needed.