Env Example Checker · Configuración
Detecta las variables de entorno ausentes de tu .env.example.
Pega tu código y tu .env.example para encontrar las variables de entorno que tu código lee pero que faltan en el ejemplo —además de las claves que nada lee— por completo en tu navegador.
Entorno de pruebas del 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.
La brecha
El .env.example siempre se desvía.
Una nueva variable aterriza en el código y en tu .env local, y el .env.example, el archivo que de verdad se confirma en el repositorio y que copia cada compañero de equipo, queda atrás en silencio. El .env está ignorado por git, así que nada te avisa. Esa desviación de variables de entorno entre el código y la configuración permanece invisible hasta que alguien clona el proyecto y la aplicación falla por una clave ausente, o hasta que variables de entorno ausentes rompen una canalización de CI porque nunca se documentó una variable obligatoria.
Comprobarlo a ojo en una base de código extensa es exactamente el tipo de comparación mecánica que una herramienta debería hacer. Este verificador lee ambas direcciones a la vez: lista las variables que tu código usa pero que el ejemplo no tiene —las que rompen una descarga recién hecha— y las claves que el ejemplo aún declara pero que nada lee, para que puedas eliminar las obsoletas con confianza.
¿Quieres verlo antes? Salta a las dos entradas o prueba el entorno de pruebas en vivo de arriba.
La canalización
Cómo funciona.
Cinco pasos deterministas comparan tu código con tu ejemplo, todos dentro de la pestaña de tu navegador, cada vez.
-
Examina el código.
Se recorre tu código fuente en busca de cada lectura de variable de entorno: process.env, os.environ, $NAME y las demás.
-
Analiza el ejemplo.
Tu .env.example se lee como líneas KEY=value, omitiendo comentarios y líneas en blanco, en un conjunto de claves.
-
Compara los dos conjuntos.
Los nombres usados en el código se confrontan con las claves declaradas en el ejemplo, en ambas direcciones a la vez.
-
Saca a la luz las brechas.
Las variables usadas pero no declaradas se señalan como ausentes; las claves declaradas pero no leídas se señalan como sin usar.
-
Corrige y vuelve a comprobar.
Añade las claves ausentes a tu ejemplo, elimina las obsoletas y vuelve a ejecutar hasta que el informe esté limpio.
Las entradas
Dos entradas, ambas familiares.
El verificador lee exactamente dos cosas: el código de tu aplicación y tu .env.example. Si alguna vez has escrito alguno de los dos, estos te resultarán de lo más conocidos.
El código
Cualquier código fuente que lea variables de entorno. El escáner reconoce process.env.NAME e import.meta.env.NAME en Node / Vite, os.environ["NAME"] / os.getenv("NAME") en Python, os.Getenv("NAME") en Go, y el simple $NAME en 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');
}El .env.example
Líneas dotenv estándar: KEY=value por línea, con comentarios # y líneas en blanco ignoradas. Para la comparación solo importan los nombres de las claves, así que los valores de marcador no son problema. Este es el archivo que tus compañeros de equipo copian a un .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=falsePróximamente
Haz que la compilación falle ante una desviación.
El verificador del navegador es el primer paso. Una CLI lista para usar ejecutará la comparación idéntica sobre tu repositorio en CI, de modo que una entrada olvidada del .env.example haga fallar la compilación en lugar de romper el primer git clone de un compañero de equipo.
Junto a ella está prevista una Action propia de GitHub que envuelve la CLI. Ambas llegan próximamente; el verificador en el navegador de arriba funciona hoy.
# 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 unusedUna nota sobre el alcance
Cómo funciona la detección: el verificador identifica las lecturas de variables de entorno por sus patrones de acceso comunes y literales —process.env.NAME, os.environ["NAME"], $NAME y similares—. Los nombres construidos dinámicamente en tiempo de ejecución (por ejemplo, process.env[someVariable]) no pueden resolverse de forma estática, así que no aparecerán en el conjunto de usadas. Trata un informe limpio como una sólida confianza de que tu configuración documentada coincide con tu código, y aun así revisa por encima a mano cualquier búsqueda calculada.
FAQ
Tus preguntas, respondidas.
Toca una pregunta para desplegar la respuesta.
¿Qué hace el Env Example Checker?
Compara las variables de entorno que tu código lee realmente con las claves declaradas en tu .env.example. Pega ambos, pulsa Comprobar y te informa de dos brechas: variables usadas en el código pero ausentes del ejemplo (las que perjudican a un nuevo desarrollador o a un despliegue recién hecho) y claves declaradas en el ejemplo que nada lee (entradas obsoletas que conviene eliminar). Todo se calcula en tu navegador.
¿Mi código o mi .env.example salen alguna vez de mi navegador?
No. El verificador se ejecuta 100 % en el cliente. Tu código fuente y tu archivo de ejemplo se analizan y comparan en la pestaña de tu navegador: no se sube nada a un servidor y no hay cuenta ni registro. Es seguro pegar código interno y claves de configuración.
¿Qué lenguajes y patrones de acceso detecta?
Reconoce las formas habituales en que el código lee variables de entorno en los ecosistemas más populares: process.env.NAME y process.env["NAME"] en Node y TypeScript, import.meta.env.NAME en Vite, Deno.env.get("NAME") en Deno, os.environ["NAME"] / os.getenv("NAME") en Python, ENV["NAME"] / ENV.fetch("NAME") en Ruby, os.Getenv("NAME") en Go, System.getenv("NAME") en Java, y getenv / $_ENV["NAME"] en PHP. El lado del .env.example se analiza como líneas estándar KEY=value, ignorando comentarios y líneas en blanco.
¿Por qué el .env.example se desvía del código en primer lugar?
Se añade una nueva variable al código y al .env local, pero el .env.example —que es el archivo que se confirma en el repositorio y el que copian los compañeros de equipo— se olvida. La desviación es invisible hasta que alguien clona el proyecto, copia el ejemplo y la aplicación falla por una clave ausente, o hasta que un despliegue falla porque nunca se documentó una variable obligatoria. Esta herramienta saca a la luz esa desviación antes de que llegue a producción.
¿Puede indicar qué variables ausentes son obligatorias y cuáles opcionales?
Informa de cada variable que el código lee y que el ejemplo no declara; si una variable dada es estrictamente obligatoria es una decisión que solo tu código puede tomar (un valor por defecto puede hacerla opcional). Trata la lista de ausentes como el conjunto que debes revisar y documentar: añade cada una al .env.example con un valor de marcador seguro o un comentario que indique que es opcional.
¿Cómo encuentro variables de entorno usadas en el código pero ausentes del .env.example?
Pega tu código fuente en el panel de código y tu .env.example en el panel de plantilla, luego pulsa Comprobar. El verificador examina el código en busca de todas las referencias a variables de entorno —process.env.X, os.getenv("X"), import.meta.env.X y patrones similares— y compara ese conjunto con las claves de tu .env.example, listando cada variable que el código lee y que el archivo de ejemplo no declara.
¿Cómo encuentro claves sin usar en mi archivo .env.example?
El verificador ejecuta la comparación en ambas direcciones a la vez. Junto al informe de claves ausentes, también lista cada clave que tu .env.example declara y que no aparece en el código pegado, de modo que puedas eliminar con seguridad variables obsoletas o sobrantes y mantener la plantilla concisa y precisa.
¿Cómo evito que las variables de entorno ausentes rompan la CI o los despliegues?
Ejecuta este verificador antes de confirmar, para detectar pronto cualquier variable que tu código lea y que el ejemplo omita. Mantener el .env.example sincronizado con el código ofrece a las canalizaciones de CI y a los compañeros de equipo una plantilla completa, lo que significa que la aplicación falla rápido en el momento de la configuración en lugar de fallar en tiempo de ejecución con un error de variable indefinida. Está prevista una versión de CLI para comprobaciones automatizadas en CI.
¿Cuál es la diferencia entre comparar dos archivos .env y comprobar contra el código?
Comparar .env con .env.example confronta dos archivos de configuración entre sí: solo sabe qué claves declara cada archivo. Este verificador, en cambio, lee el código fuente real para saber qué variables se usan de verdad, de modo que detecta variables que el código necesita y que están ausentes de todos los archivos de configuración, y señala las claves del ejemplo que el código nunca usa. Esa distinción es lo que lo hace útil para detectar la desviación de variables de entorno entre el código y la configuración, no solo entre dos archivos de configuración.
¿Es esta una herramienta oficial de algún framework?
No. Es una utilidad independiente y comunitaria, y no está afiliada ni respaldada por ningún framework, runtime o biblioteca dotenv. Modela la convención .env / .env.example, ampliamente utilizada, y los patrones habituales de acceso a entorno solo para describir lo que comprueba.
More free, private DevOps tools.
El Env Example Checker es una herramienta más de OpsCanopy: una creciente cúpula de validadores, convertidores y verificadores basados en el navegador que nunca tocan un servidor.
¿Empiezas con Docker? Lee la guía de Docker →
29 herramientas gratuitas, todas pueden funcionar sin conexión — opscanopy.com funciona sin registro y sin subir nada.
¿Validando configuración y canalizaciones? Combínalo con el GitHub Actions Validator para detectar problemas de flujos de trabajo antes del push, o explora el directorio completo de herramientas.
No está afiliado ni respaldado por ningún framework, runtime o biblioteca dotenv. La convención .env / .env.example y los patrones de acceso a entorno se mencionan solo para describir lo que esta herramienta comprueba.