How to avoid duplicate env configs
Duplication is not always bad: separate blast radius sometimes requires two copies of “the same” integration with different keys. The problem is untracked duplication — three STRIPE_SECRET_KEY values and nobody knows which is live.
1. Distinguish technical vs organizational duplication
| Type | OK? | Example |
|---|---|---|
| Same name, same value, copied everywhere | Bad | Identical .env in five folders |
| Same integration, different scoped keys | Good | web read-only vs worker read-write |
| Dev vs staging vs prod | Good | Different values, clear separation |
2. Single source of truth on a laptop
Use one vault workspace per product and reference it from docs — not scattered files:
Canonical: PassStore workspace "acme-api" / group "dev"
Ephemeral: .env generated or pasted for this session only
PassStore · organize across projects.
3. Monorepo: avoid root god .env
Anti-pattern:
/.env # 200 variables for web+api+worker — merge conflicts in real life
Better:
apps/api/.env.example,apps/web/.env.example— each minimal.- Shared non-secret defaults in committed
config/*.tsor small JSON without secrets.
4. CI: one secret set per pipeline
GitHub Actions: prefer environment secrets (environment: staging) over one flat org-wide bag. GitHub docs: Using environments for deployment.
5. Documentation beats copy-paste
If two services need the same third-party key (sometimes unavoidable):
- Document
owner: which team rotates it. - Store once in team secret manager; inject to both pipelines — do not ask humans to copy twice.
6. When duplication is intentional
- Microservices with independent deploys should not share files on disk — they may still share naming conventions.
- Per-developer API keys: everyone has their own value — “duplicate key name, different value” is fine.