EnvRune: references in Git, secrets in the vault

A .env file mixes two kinds of information: which variables an application requires, and which values grant access to a service. The first belongs with the code and needs to circulate within a team. The second requires access control.

EnvRune separates those responsibilities. A vault stores encrypted values; envrune.yml maps environment variables to readable references. The versioned file describes bindings without containing the values. See the EnvRune case study for the project context.

The documented workflow initializes the project, unlocks the vault, binds a variable and starts a program:

SERVICE_TOKEN is an example name. This article contains no real secret values. When a reference does not exist, the CLI offers to store it. Temporary unlocking is an explicit operator choice.

The runner launches the child process directly, without an intermediate shell. This reduces additional command interpretation, but does not make an unknown program trustworthy. That process receives the secret and remains inside the trust boundary.

The published design uses Argon2id for password key derivation and XChaCha20-Poly1305 for authenticated vault encryption. The documentation also describes recovery and data keys. This describes the project, rather than claiming an independent cryptographic audit.

Output masking in run and up reduces accidental disclosure in terminals and logs. It cannot stop a program deliberately sending a value over the network or writing it elsewhere. export serves a different purpose: it produces plaintext, so its destination, permissions and Git history need attention.

The envrune mcp server exposes environment, reference and command metadata, plus execution of commands named in envrune.yml. By default, it offers neither a tool that reads secret values nor arbitrary command-line execution.

--allow-args and --allow-any-command expand that surface and are disabled by default. Output is masked and bounded, and execution has a timeout. These restrictions complement review of the allowed commands: a script that exfiltrates data remains dangerous even when it has an approved name.

The local vault works without Cloud. In ordinary sharing, the documentation describes encryption and decryption on devices, with ciphertext stored by the server. An important exception is a managed key marked sensitive: a server proxy can use it and must read that value to insert it into a request. These are different trust models.

Read the redaction, recovery and server operations limitations before adopting it. This article claims no adoption, savings or incident reduction figures; those outcomes require actual measurement.

This article was checked against repository commit c2aa0d1 on 17 October 2026: README, security, MCP and managed keys. Start with a test project and disposable credentials to evaluate the architecture in your workflow.