EnvRune: referencias en Git, secretos en la bóveda

Un archivo .env mezcla dos informaciones: qué variables necesita una aplicación y qué valores permiten acceder a un servicio. La primera debe circular en el equipo y acompañar al código. La segunda requiere control de acceso.

EnvRune separa esas responsabilidades. Una bóveda almacena valores cifrados; envrune.yml asocia variables con referencias legibles. El archivo versionado describe los vínculos sin incluir los valores. El contexto está en el caso de estudio de EnvRune.

El flujo documentado inicializa el proyecto, desbloquea la bóveda, asocia una variable e inicia el programa:

SERVICE_TOKEN es un nombre de ejemplo. Este artículo no contiene valores secretos reales. Si la referencia no existe, la CLI ofrece almacenarla. El desbloqueo temporal es una decisión explícita del operador.

El runner inicia directamente el proceso hijo, sin un shell intermedio. Reduce así la interpretación adicional de comandos, pero no convierte un programa desconocido en código fiable. El proceso recibe el secreto y forma parte de ese límite de confianza.

El diseño publicado usa Argon2id para derivar la clave de la contraseña y XChaCha20-Poly1305 para el cifrado autenticado de la bóveda. La documentación también describe recuperación y claves de datos. Es una descripción del proyecto, no una afirmación de auditoría criptográfica independiente.

El enmascaramiento de salida en run y up reduce filtraciones accidentales en terminales y registros. No impide que un programa envíe deliberadamente un valor por la red o lo escriba en otro lugar. export tiene otra finalidad: produce texto plano, por lo que exige revisar el destino, los permisos y el historial de Git.

El servidor envrune mcp expone metadatos de entornos, referencias y comandos, además de ejecutar los comandos definidos en envrune.yml. Por defecto no ofrece una herramienta para leer valores ni ejecución arbitraria de líneas de comandos.

--allow-args y --allow-any-command amplían esa superficie y están desactivadas por defecto. La salida se enmascara y limita; la ejecución tiene timeout. Estas restricciones complementan la revisión de los comandos permitidos: un script que extrae datos sigue siendo peligroso aunque tenga un nombre autorizado.

La bóveda local funciona sin Cloud. En el modo habitual de compartir, la documentación describe cifrado y descifrado en los dispositivos, con ciphertext en el servidor. Existe una excepción importante: una clave gestionada marcada como sensible puede usarse mediante un proxy del servidor, que necesita leer ese valor para insertarlo en la petición. Son modelos de confianza distintos.

Antes de adoptarlo, consulta los límites del enmascaramiento, la recuperación y la operación del servidor. Este artículo no presenta cifras de adopción, ahorro o reducción de incidentes: esos resultados necesitan medición real.

El texto se contrastó con el commit c2aa0d1 del repositorio el 17/10/2026: README, seguridad, MCP y claves gestionadas. Empieza con un proyecto de prueba y credenciales desechables para evaluar la arquitectura en tu flujo.

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.