Why we never parse your .env file

It is tempting to treat a .env file as a dictionary. Parse it into keys and values, store those, and reconstruct the file on the way out. It would make search and diffing easy. We deliberately do not do it.

There is no single dotenv format

Different libraries and runtimes disagree about nearly every edge case:

• Whether # starts a comment mid-line or only at the start of a line.
• Whether values are trimmed, and whether quotes are preserved or stripped.
• How multiline values work — real newlines inside quotes, or \n escapes.
• Whether ${OTHER_VAR} is interpolated, and by whom.
• Whether export prefixes are allowed.
• What happens with a key that appears twice.

If nvault parsed and re-serialised your file, it would have to pick one interpretation. The moment ours differs from the one your app actually uses, we have corrupted your config in a subtle, hard-to-spot way.

Bytes in, same bytes out

nvault treats every configuration file as an opaque blob. What you upload is what you get back, exactly:

• Comments and their placement.
• Quoting style, or the absence of quotes.
• Key ordering — including deliberate grouping.
• Blank lines and trailing whitespace.
• Multiline values, however they are expressed.
• File encoding, where the platform supports it.

A backup you cannot trust to be byte-identical is not a backup. It is a suggestion.

It is also the safer choice

A parser is code that runs on your secrets. A blob is not. Not parsing means there is no dotenv-parsing logic anywhere near your plaintext — one less place for a bug, an injection, or an unexpected transformation. It also means nvault works for files that are not dotenv at all: a service-account JSON, a TOML config, a PEM key you need alongside the project.

The trade-off

Store files as files. Give them back unchanged. Everything else is negotiable; that is not.