EnvRune: referências no Git, segredos no cofre

Um .env mistura duas informações diferentes: quais variáveis uma aplicação exige e quais valores permitem acessar um serviço. A primeira precisa circular no time e acompanhar o código. A segunda exige controle de acesso.

O EnvRune separa essas responsabilidades. Um cofre armazena os valores criptografados; envrune.yml associa variáveis a referências legíveis. O arquivo versionado descreve os vínculos, sem carregar os valores. O estudo de caso está em EnvRune no portfólio.

O fluxo documentado inicializa o projeto, desbloqueia o cofre, associa uma variável e inicia o programa:

SERVICE_TOKEN é um nome de exemplo. Nenhum valor real aparece neste artigo. Quando a referência ainda não existe, a CLI oferece armazená-la. O desbloqueio temporário é uma escolha explícita do operador.

O runner inicia diretamente o processo filho, sem um shell intermediário. Isso reduz interpretação adicional de comandos, mas não transforma um programa desconhecido em código confiável. O processo recebe o segredo e precisa ser tratado como parte dessa fronteira de confiança.

O desenho publicado usa Argon2id para derivar a chave da senha e XChaCha20-Poly1305 para criptografia autenticada do cofre. A documentação também descreve recuperação e chaves de dados. Esta descrição é do projeto; não é uma alegação de auditoria criptográfica independente.

O mascaramento de saída de run e up reduz vazamentos acidentais no terminal e nos logs. Ele não impede um programa de enviar o segredo deliberadamente pela rede ou gravá-lo em outro lugar. export tem uma finalidade diferente: produz texto puro, portanto exige cuidado com destino, permissões e histórico do Git.

O servidor envrune mcp oferece metadados de ambientes, referências e comandos, além da execução de comandos nomeados em envrune.yml. Por padrão, ele não oferece uma ferramenta de leitura dos valores nem execução arbitrária de uma linha de comando.

As opções --allow-args e --allow-any-command ampliam essa superfície e ficam desligadas por padrão. A saída é mascarada e limitada; a execução tem timeout. Essas restrições complementam a revisão dos comandos autorizados: permitir um script que exfiltra dados continua sendo perigoso mesmo com um nome conhecido.

O cofre local funciona sem Cloud. Na modalidade normal de compartilhamento, a documentação descreve criptografia e descriptografia nos dispositivos, com ciphertext no servidor. Há uma exceção importante: uma chave gerenciada marcada como sensível pode ser usada por um proxy do servidor, que precisa ler esse valor para inseri-lo na requisição. Não são modelos de confiança idênticos.

Antes de adotar, consulte as limitações de redaction, recuperação e operação do servidor. Este artigo não apresenta números de adoção, economia ou redução de incidentes: esses resultados exigem medição real.

O texto foi conferido contra o commit c2aa0d1 do repositório em 17/10/2026: README, segurança, MCP e chaves gerenciadas. Para avaliar a arquitetura no seu fluxo, comece por um projeto de teste e credenciais descartáveis.

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.