🔐 Secretos: la clave nunca viaja en el bolsillo del código

¿Eres nuevo aquí? Un archivo .env (se lee «dot env», de «environment», entorno) es un archivo de texto simple que solo está en tu máquina y guarda variables de entorno — pares de nombre y valor que tu automatización lee al ejecutarse, sin que esos valores queden escritos dentro del código. En este archivo se guardan las contraseñas y claves de acceso que necesita la automatización.

Piensa en una libreta de papel para contraseñas, de esas que se guardan en un cajón de la casa. Anotas ahí la contraseña del banco, del correo y del wifi. ¿Tiene sentido llevar esa libreta al trabajo? No — se queda en casa, solo tú (y quienes viven contigo) tienen acceso. El .env es exactamente este cuaderno: está en tu computadora y nunca va junto cuando envías el código a PRO repositorio (la “caja compartida” donde se guarda y versiona el código — vimos esto en el módulo 4.2: es GitHub).

¿Eres nuevo aquí? O .gitignore es un archivo de texto, dentro de tu proyecto, con una lista de nombres de archivos y carpetas que el git (el programa que controla qué se sube al repositorio — módulo 4.2) debe ignorar por completo. Si un archivo está en esta lista, git finge que no existe: nunca aparece para enviarlo, aunque escribas el comando equivocado e intentes enviarlo todo de una vez.

Es el guardia que se queda plantado en la puerta de casa con la lista de quienes no pueden salir. Aunque tú, distraído, intentes llevarte el cuaderno de contraseñas junto con la mochila del trabajo, el guardia te detiene en la puerta. El .env siempre debería estar en esta lista; en la práctica, casi todo proyecto nuevo ya viene con esa línea lista, pero vale la pena comprobarlo.

Leyenda: el código y la clave viajan por caminos separados. El código pasa por el portero y llega al repositorio; la clave nunca pasa por ahí: la escribes directamente en el panel de la plataforma, y solo allí, en la nube, ambos vuelven a encontrarse.

No hace falta confiar a ciegas: puedes comprobar con unos pocos pasos que tu .env está efectivamente fuera de la lista de envío. El objetivo aquí es simple: crear un .env por ejemplo, confirmar que esté en la lista de .gitignore, y usar un comando de git para ver con tus propios ojos que no aparece como algo que se vaya a enviar.

Objetivo: tener un .env con marcadores de posición (nunca una clave real), protegido por .gitignore, y confirmar esto ejecutando git status.

# conteúdo de exemplo do arquivo .env (na raiz do projeto)
API_KEY=SUA_CHAVE_AQUI
OUTRO_SERVICO_TOKEN=SEU_TOKEN_AQUI

# conteúdo do .gitignore que garante que o .env nunca suba
.env
node_modules/
dist/

# comando para checar o que o git está prestes a enviar
git status

Cómo verificar: después de ejecutar git status, el archivo .env no debe aparecer en ninguna lista —ni en "archivos modificados" ni en "archivos sin seguimiento". Si aparece, es señal de que la línea .env no está en el .gitignore (o está mal escrita) — corrígela antes de continuar.

¿Eres nuevo aquí? O Trigger.dev es la plataforma de ejecución que mencionamos en el módulo 4.2: el servicio que ejecuta tu automatización en la nube, las 24 horas del día. Cuando tu automatización necesita comunicarse con otro servicio (enviar un correo electrónico, leer una hoja de cálculo, consultar una IA), la clave de ese servicio no se guarda en el código: se registra manualmente, una sola vez, en el panel de Trigger.dev. Consulta el flujo completo de principio a fin:

Así como el módulo 4.3 mostró dos «mundos» separados (desarrollo y producción) que ejecutan la misma automatización, las claves siguen esa misma separación: el panel de Trigger.dev guarda una variable de entorno por entorno. Esto significa que la clave que usas en tus pruebas no tiene que ser necesariamente la misma que se usa cuando la automatización está atendiendo a usuarios reales.

Las filtraciones ocurren — lo importante es reaccionar rápido. Si una clave real termina apareciendo donde no debía (en un commit por error, un mensaje, una captura), el paso no es "borrar" el rastro — en muchos casos eso no es suficiente, porque alguien podría haber copiado ya la clave o algún sistema automático que rastrea Internet en busca de ellas. Lo correcto es ir al panel del proveedor del servicio y revocar (revocar) esa clave y generar una nueva enseguida.

Con el secreto protegido, el siguiente módulo (4.5) aborda otro tipo de riesgo: qué hacer cuando una etapa de la automatización falla a mitad del proceso —cómo reaccionar sin duplicar nada.