El .env nunca sube a Git
Tus llaves viven en un archivo dentro del proyecto. Una línea en el .gitignore decide si quedan protegidas o expuestas para siempre.
Tu archivo de llaves vive dentro del proyecto. Ahí están la API key que pagas, la contraseña de tu base de datos, el token que da acceso a tus datos. Si ese archivo sube a GitHub, las llaves quedan expuestas — y no "hasta que lo borres": git guarda historia, así que quedan expuestas para siempre.
Necesitas una valla que lo impida. La buena noticia: es una línea de texto.
El .gitignore: la primera puerta
Git tiene una lista de prohibidos. Se llama .gitignore y es un archivo de
texto en la raíz del proyecto. Escribe .env ahí y git deja de verlo: no lo
sube, no lo versiona, no lo menciona. Una línea es la diferencia entre una
llave protegida y una llave expuesta.
El .gitignore es la puerta
Una línea en el .gitignore y la llave nunca sale de tu máquina. El resto sube tranquilo.
El trío que nunca falla
Un proyecto bien montado usa tres archivos que trabajan juntos:
Tres archivos, un solo trabajo
Tus llaves reales. Vive solo en tu máquina; git lo ignora.
La lista de prohibidos. Aquí escribes .env una sola vez.
La plantilla con los nombres de las variables y los valores vacíos.
¿Y por qué sube la plantilla? Porque quien clone tu proyecto necesita saber
qué llaves le hacen falta, sin ver cuáles son las tuyas. En el
.gitignore, la línea !.env.example es la excepción que deja pasar el molde
vacío:
# .gitignore
.env
*.env
!.env.example
# .env (IGNORADO · nunca sube)
API_KEY=sk-7Q2f9aXz
DB_PASS=miClaveReal
# .env.example (SÍ sube · sin valores)
API_KEY=
DB_PASS=
Tus claves se quedan en casa
A la nube solo viaja el molde vacío. Quien clona el proyecto copia .env.example como .env, lo llena con sus propias llaves y a trabajar.
Antes del primer commit
El orden importa. Configura el .gitignore antes de escribir tu primera
llave en el proyecto. Si el .env sube una vez, borrar el archivo no basta:
sigue vivo en el historial de git, y cualquiera que recorra los commits viejos
lo encuentra. Es un problema que no existe si la valla está puesta desde el
minuto uno.
¿Ya se te subió una llave?
Bórrala del proyecto y, más importante, rótala: genera una llave nueva en el servicio y revoca la vieja. Limpiar el historial es posible pero laborioso; rotar la llave es inmediato y cierra el riesgo de verdad.
Qué más se ignora
El .env no es el único archivo sensible que ronda un proyecto:
- Llaves sueltas:
*.key,*.pem - Archivos JSON de credenciales (cuentas de servicio de Google, Firebase)
- Bases de datos locales:
*.sqlite,*.db - Exports con datos de clientes
La regla mental es simple: si te daría vergüenza (o un problema legal) verlo
en una pantalla ajena, va al .gitignore.
Para llevar
El .gitignore es la puerta. El .env se queda. El resto sube. Configúralo
antes del primer commit y este problema deja de existir para siempre — y en el
próximo artículo le sumamos un guardián que revisa por ti cuando el
.gitignore no alcanza.
Sigue aprendiendo IA con nosotros
Lo que lees aquí es solo el comienzo. Únete a nuestra comunidad y aprende a construir y vender soluciones reales con inteligencia artificial.
- +80 personas aprendiendo en comunidad
- Directos cada semana con tecnología a la vanguardia
- Formaciones de los softwares para crear y vender soluciones