Env Example Checker · Configuração
Detecte as variáveis de ambiente ausentes do seu .env.example.
Cole seu código e seu .env.example para encontrar as variáveis de ambiente que seu código lê mas que faltam no exemplo —além das chaves que nada lê— inteiramente no seu navegador.
Playground do Env Example Checker
Processed entirely in your browser — contents are never uploaded.
Tip: press Esc to release focus.
No share links on this tool — inputs may be secrets.
Load an example or paste your own code and .env.example, then check to see which variables drifted.
A lacuna
O .env.example sempre se desvia.
Uma nova variável chega ao código e ao seu .env local, e o .env.example, o arquivo que de fato é versionado no repositório e que cada colega de equipe copia, fica para trás em silêncio. O .env é ignorado pelo git, então nada te avisa. Esse desvio de variáveis de ambiente entre o código e a configuração permanece invisível até que alguém clone o projeto e a aplicação quebre por uma chave ausente, ou até que variáveis de ambiente ausentes quebrem um pipeline de CI porque uma variável obrigatória nunca foi documentada.
Verificar isso a olho em uma base de código extensa é exatamente o tipo de comparação mecânica que uma ferramenta deveria fazer. Este verificador lê as duas direções ao mesmo tempo: lista as variáveis que o seu código usa mas que faltam no exemplo —as que quebram um checkout recém-feito— e as chaves que o exemplo ainda declara mas que nada lê, para que você possa remover as obsoletas com confiança.
Quer ver primeiro? Pule para as duas entradas ou experimente o playground ao vivo acima.
O pipeline
Como funciona.
Cinco passos determinísticos comparam seu código com seu exemplo, todos dentro da aba do seu navegador, a cada vez.
-
Examina o código.
Seu código-fonte é percorrido em busca de cada leitura de variável de ambiente: process.env, os.environ, $NAME e as demais.
-
Analisa o exemplo.
Seu .env.example é lido como linhas KEY=value, pulando comentários e linhas em branco, em um conjunto de chaves.
-
Compara os dois conjuntos.
Os nomes usados no código são confrontados com as chaves declaradas no exemplo, nas duas direções ao mesmo tempo.
-
Traz as lacunas à tona.
As variáveis usadas mas não declaradas são sinalizadas como ausentes; as chaves declaradas mas não lidas são sinalizadas como sem uso.
-
Corrija e verifique de novo.
Adicione as chaves ausentes ao seu exemplo, remova as obsoletas e rode novamente até o relatório ficar limpo.
As entradas
Duas entradas, ambas familiares.
O verificador lê exatamente duas coisas: o código da sua aplicação e o seu .env.example. Se você já escreveu algum dos dois antes, vão parecer familiares na hora.
O código
Qualquer código-fonte que leia variáveis de ambiente. O scanner reconhece process.env.NAME e import.meta.env.NAME no Node / Vite, os.environ["NAME"] / os.getenv("NAME") em Python, os.Getenv("NAME") em Go, e o simples $NAME no shell.
// server.ts
const port = process.env.PORT ?? '3000';
const dbUrl = process.env.DATABASE_URL;
const apiKey = process.env["STRIPE_SECRET_KEY"];
if (!dbUrl) {
throw new Error('DATABASE_URL is required');
}O .env.example
Linhas dotenv padrão: KEY=value por linha, com comentários # e linhas em branco ignorados. Para a comparação só importam os nomes das chaves, então valores de placeholder não são problema. Este é o arquivo que seus colegas de equipe copiam para um .env real.
# .env.example
PORT=3000
DATABASE_URL=postgres://localhost:5432/app
# STRIPE_SECRET_KEY is used in server.ts but
# was never added here — the checker flags it.
# Declared below but nothing reads it — flagged as unused.
LEGACY_FEATURE_FLAG=falseEm breve
Faça a build falhar diante de um desvio.
O verificador do navegador é o primeiro passo. Uma CLI pronta para usar rodará a comparação idêntica sobre o seu repositório na CI, de modo que uma entrada esquecida do .env.example faça a build falhar em vez de quebrar o primeiro git clone de um colega de equipe.
Junto a ela está prevista uma Action própria do GitHub que encapsula a CLI. Ambas chegam em breve; o verificador no navegador acima já funciona hoje.
# Coming soon — the same check in CI
$ envcheck ./src --example .env.example
✗ Missing from .env.example (1)
STRIPE_SECRET_KEY used in src/server.ts
! Unused in .env.example (1)
LEGACY_FEATURE_FLAG
1 missing, 1 unusedUma nota sobre o escopo
Como a detecção funciona: o verificador identifica as leituras de variáveis de ambiente pelos seus padrões de acesso comuns e literais —process.env.NAME, os.environ["NAME"], $NAME e similares. Nomes construídos dinamicamente em tempo de execução (por exemplo, process.env[someVariable]) não podem ser resolvidos estaticamente, então não aparecerão no conjunto de usadas. Trate um relatório limpo como forte confiança de que a sua configuração documentada corresponde ao seu código, e ainda assim revise por cima, à mão, qualquer busca calculada.
FAQ
Suas perguntas, respondidas.
Toque em uma pergunta para expandir a resposta.
O que o Env Example Checker faz?
Ele compara as variáveis de ambiente que o seu código realmente lê com as chaves declaradas no seu .env.example. Cole os dois, clique em Verificar e ele informa duas lacunas: variáveis usadas no código mas ausentes do exemplo (as que prejudicam um novo desenvolvedor ou um deploy recém-feito) e chaves declaradas no exemplo que nada lê (entradas obsoletas que vale a pena remover). Tudo é calculado no seu navegador.
Meu código ou meu .env.example saem do meu navegador em algum momento?
Não. O verificador roda 100% no cliente. Seu código-fonte e seu arquivo de exemplo são analisados e comparados na aba do seu navegador: nada é enviado para um servidor e não há conta nem cadastro. É seguro colar código interno e chaves de configuração.
Quais linguagens e padrões de acesso ele detecta?
Ele reconhece as formas comuns pelas quais o código lê variáveis de ambiente nos ecossistemas mais populares: process.env.NAME e process.env["NAME"] no Node e no TypeScript, import.meta.env.NAME no Vite, Deno.env.get("NAME") no Deno, os.environ["NAME"] / os.getenv("NAME") em Python, ENV["NAME"] / ENV.fetch("NAME") em Ruby, os.Getenv("NAME") em Go, System.getenv("NAME") em Java, e getenv / $_ENV["NAME"] em PHP. O lado do .env.example é analisado como linhas KEY=value padrão, ignorando comentários e linhas em branco.
Por que o .env.example se desvia do código, afinal?
Uma nova variável é adicionada ao código e ao .env local, mas o .env.example —que é o arquivo versionado no repositório e o que os colegas de equipe copiam— é esquecido. O desvio fica invisível até que alguém clone o projeto, copie o exemplo e a aplicação quebre por uma chave ausente, ou até que um deploy falhe porque uma variável obrigatória nunca foi documentada. Esta ferramenta traz esse desvio à tona antes que ele chegue à produção.
Ele consegue dizer quais variáveis ausentes são obrigatórias e quais são opcionais?
Ele informa cada variável que o código lê e que o exemplo não declara; se uma determinada variável é estritamente obrigatória é uma decisão que só o seu código pode tomar (um valor padrão pode torná-la opcional). Trate a lista de ausentes como o conjunto a revisar e documentar: adicione cada uma ao .env.example com um valor de placeholder seguro ou um comentário indicando que é opcional.
Como encontro variáveis de ambiente usadas no código mas ausentes do .env.example?
Cole seu código-fonte no painel de código e seu .env.example no painel de modelo, depois clique em Verificar. O verificador examina o código em busca de todas as referências a variáveis de ambiente —process.env.X, os.getenv("X"), import.meta.env.X e padrões similares— e compara esse conjunto com as chaves do seu .env.example, listando cada variável que o código lê e que o arquivo de exemplo não declara.
Como encontro chaves sem uso no meu arquivo .env.example?
O verificador roda a comparação nas duas direções ao mesmo tempo. Junto ao relatório de chaves ausentes, ele também lista cada chave que o seu .env.example declara e que não aparece no código colado, para que você possa remover com segurança variáveis obsoletas ou sobrando e manter o modelo enxuto e preciso.
Como impeço que variáveis de ambiente ausentes quebrem a CI ou os deploys?
Rode este verificador antes de fazer o commit, para detectar cedo qualquer variável que o seu código leia e que o exemplo omita. Manter o .env.example sincronizado com o código oferece aos pipelines de CI e aos colegas de equipe um modelo completo, o que significa que a aplicação falha rápido no momento da configuração em vez de quebrar em tempo de execução com um erro de variável indefinida. Está prevista uma versão de CLI para verificações automatizadas na CI.
Qual é a diferença entre comparar dois arquivos .env e verificar contra o código?
Comparar .env com .env.example confronta dois arquivos de configuração entre si: ele só sabe quais chaves cada arquivo declara. Este verificador, em vez disso, lê o código-fonte real para saber quais variáveis são de fato usadas, de modo que detecta variáveis que o código precisa e que estão ausentes de todos os arquivos de configuração, e sinaliza as chaves do exemplo que o código nunca usa. Essa distinção é o que o torna útil para detectar o desvio de variáveis de ambiente entre o código e a configuração, não apenas entre dois arquivos de configuração.
Esta é uma ferramenta oficial de algum framework?
Não. É um utilitário independente e comunitário, e não é afiliado nem endossado por nenhum framework, runtime ou biblioteca dotenv. Ele modela a convenção .env / .env.example, amplamente utilizada, e os padrões comuns de acesso ao ambiente apenas para descrever o que verifica.
More free, private DevOps tools.
O Env Example Checker é mais uma ferramenta do OpsCanopy: uma copa crescente de validadores, conversores e verificadores baseados no navegador que nunca tocam um servidor.
Começando com Docker? Leia o guia de Docker →
29 ferramentas gratuitas, todas capazes de funcionar offline — o opscanopy.com não exige cadastro e não envia nada.
Validando configuração e pipelines? Combine isto com o GitHub Actions Validator para detectar problemas de fluxos de trabalho antes do push, ou explore o diretório completo de ferramentas.
Não é afiliado nem endossado por nenhum framework, runtime ou biblioteca dotenv. A convenção .env / .env.example e os padrões de acesso ao ambiente são mencionados apenas para descrever o que esta ferramenta verifica.