# 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

1. Files are read top to bottom.
2. For each duplicate key, the **last occurrence wins** — matching the Node and Python ecosystems most teams already expect.
3. Every collision emits a structured warning: file, line of first occurrence, line of override, both values (redacted if matched against the secret patterns).
4. If `AURA_ENV_STRICT=1` is 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.