The road to nvault run: secrets without a file on disk

Everything nvault does today assumes your project ultimately wants a .env file on disk. We store it encrypted, version it, and restore it safely — but at the end there is still a plaintext file sitting in your working directory.

For a lot of workflows that file is unnecessary. Your process needs the values in its environment; it does not need them written down. That is what nvault run is for.

The idea

nvault run -- npm run dev
nvault run -- pytest
nvault run --project portfolio-analytics -- ./deploy.sh

1. The CLI resolves the project (Git remote or explicit flag) and fetches the encrypted config.
2. It decrypts in memory, using the vault passphrase for the session.
3. It spawns the child process with those values in its environment, streams through stdio, and forwards the exit code.
4. When the process exits, the secrets leave with it. Nothing was written to disk.

Why it is a differentiator

• No file to leak. The most common exposure path — a committed or copied .env — is not available if there is no .env.
• No stale config. The process always gets the current version from the vault; there is no local copy to drift.
• CI-friendly. A runner fetches secrets for exactly one command and never persists them into the workspace.

What we are being careful about

Injecting secrets into a process is a sharp tool, and we would rather ship it right than ship it early:

• Child environments are readable by that process and its descendants — nvault run is not a sandbox, and we will document exactly what it does and does not isolate.
• On some platforms a process's environment is visible to other processes of the same user; the docs will be explicit about that.
• It must fail closed: if decryption or fetch fails, the command does not run with partial or empty config.
• It must not leak values into its own logs, error messages, or crash output.

Where it sits on the roadmap

The endgame is that "where is the .env file" stops being a question you ever have to answer.