dotenv duplicate keys — does last win? (Aura's deterministic resolver)
Most dotenv parsers say "last duplicate key wins" — but the answer depends on which library you load. Aura uses a deterministic last-wins resolver and warns on every collision.
Short answer: in almost every popular dotenv loader, the last occurrence of a duplicate key wins. But the behaviour is not universal, and the silent override has caused enough production incidents that Aura treats it as a first-class warning.
Library matrix
| Library | Behaviour on duplicate | Warns? |
|---|---|---|
dotenv (Node) |
last wins | no |
dotenv-flow |
last wins (after layering) | no |
python-dotenv |
last wins | no |
godotenv |
first wins (!) | no |
dotenvy (Rust) |
first wins by default; last wins with from_filename_override |
no |
aura env |
last wins | yes — every collision logged |
Why the inconsistency matters
When an AI agent generates a .env patch, it may unintentionally append a duplicate DATABASE_URL instead of editing the existing one. Whether that breaks production depends on which loader your runtime ships. Aura normalises the rule and surfaces the collision so the agent (and you) can decide intentionally.
Aura's deterministic rule
- Files are read top to bottom.
- For each duplicate key, the last occurrence wins — matching the Node and Python ecosystems most teams already expect.
- Every collision emits a structured warning: file, line of first occurrence, line of override, both values (redacted if matched against the secret patterns).
- If
AURA_ENV_STRICT=1is set, duplicates fail the load instead of warning.
Recommendation
Treat duplicate dotenv keys as a code smell, not a feature. Use aura env doctor in CI to fail builds when a collision sneaks in via an agent-generated diff.