De dotenv para dotenvx - o gerenciador de configuração da próxima geração

• Após o primeiro commit do dotenv, em julho de 2013, ele cresceu durante 11 anos até se tornar um dos pacotes mais utilizados no mundo
• Alcançou uma posição semelhante à de softwares essenciais como TypeScript e ESLint

Problemas do dotenv

• Risco de vazamento de arquivos .env
• Dificuldade para gerenciar múltiplos ambientes
• Falta de consistência entre plataformas

Solução para os problemas: dotenvx

• Funciona da mesma forma em todas as plataformas
• Suporte a múltiplos ambientes
• Criptografia de arquivos de variáveis de ambiente

Pode ser executado em qualquer lugar

• Funciona da mesma forma em todas as linguagens, frameworks e plataformas
• Permite injetar variáveis de ambiente em tempo de execução com dotenvx run -- your-cmd
• O mecanismo de parsing de .env, expansão de variáveis, substituição de comandos etc. funcionam da mesma forma
• Pode ser instalado de várias formas, como npm, brew, curl, docker e windows

  $ echo "HELLO=World" > .env  
  $ echo "console.log('Hello ' + process.env.HELLO)" > index.js  
  $ node index.js  # sem dotenvx  
  Hello undefined  
  $ dotenvx run -- node index.js  # com dotenvx  
  Hello World  
  

Suporte a múltiplos ambientes

• Crie o arquivo .env.production e carregue-o com a opção -f
• É possível configurar múltiplos ambientes usando várias flags -f

  $ echo "HELLO=production" > .env.production  
  $ dotenvx run -f .env.production -- node index.js  
  [dotenvx][info] loading env (1) from .env.production  
  Hello production  
  

Criptografia

• Adiciona criptografia ao arquivo .env com o comando dotenvx encrypt
• Usa criptografia de chave pública
• Mesmo que o arquivo .env vaze, ele não pode ser descriptografado sem DOTENV_PRIVATE_KEY
• Em projetos open source, é possível adicionar novas configurações sem descriptografar segredos anteriores

  $ dotenvx encrypt  
  ✔ encrypted (.env)  
  

Lançamento da versão 1.0.0

• Anunciado o lançamento do dotenvx versão 1.0.0
• Muitos desenvolvedores poderão utilizá-lo como uma ferramenta de gerenciamento de configuração da próxima geração

---

Opinião do GN⁺

• dotenvx oferece segurança e conveniência ao mesmo tempo
• É útil para desenvolvedores, pois facilita o gerenciamento de vários ambientes
• O recurso de criptografia é especialmente útil para projetos sensíveis à segurança
• Os recursos do dotenvx oferecem consistência em várias linguagens e plataformas, aumentando a eficiência no desenvolvimento

[yangeok]

Pelo jeito, dá para declarar direto no script de execução, sem precisar separar modo de produção e modo de desenvolvimento dentro do programa.

[GN⁺]

Comentários do Hacker News

• Não é uma boa ideia passar segredos por variáveis de ambiente. Variáveis de ambiente podem vazar com facilidade. Em vez disso, é melhor ler os segredos de um vault ou do sistema de arquivos dentro do próprio processo.

• O motivo para usar arquivos .env é que eles são simples e claros. Para usar uma forma de configuração mais segura e poderosa, é preciso ler a documentação.

• Comecei a usar o Mise para tarefas. Ainda não usei tanto, mas parece promissor. Ele lida com tarefas como inicializar um banco de dados de teste local, executar scripts de lint e também gerencia variáveis de ambiente e ambientes virtuais.

• Como vazamento de segredos é um problema sério, é sensato criptografar os segredos ao usar dotenvx. Ferramentas que não oferecem suporte a segredos não criptografados são mais seguras.

• É parecido com o Sops, mas não tem criptografia por padrão. O Sops se integra facilmente com a AWS e soluções existentes de gerenciamento de chaves, e foi muito bom na prática com base no uso em duas empresas ao longo de 5 anos.

• Criptografar e fazer commit de segredos é conveniente, mas se alguém obtiver acesso à chave de criptografia, todos os segredos podem ser expostos. É mais seguro configurar isso em um gerenciador de segredos na nuvem e não mexer mais.

• Variáveis de ambiente são compartilhadas em excesso, e arquivos dependem de permissões locais. Precisamos de uma nova forma de transferir segredos entre processos. Por exemplo, passar segredos por um socket Unix de uma forma que só permita leitura única.

• É preciso haver documentação sobre como colocar corretamente um arquivo .env em um vault. Se o vault for protegido por senha, surge o problema de ter que escrever essa senha em texto claro para que a aplicação consiga lê-la.

• Quero gerenciar todas as variáveis de ambiente em um único arquivo no formato TOML. Isso facilitaria atualizar, comparar e compartilhar. Mas é difícil manter consistência nos nomes dos ambientes. Isso costuma surgir de decisões rápidas ou necessidades momentâneas, e dá medo corrigir depois.