Si tu sitio se despliega desde git, tu repo es tu raíz web
El deploy automático vale la pena. También publica todos los archivos en los que nunca pensaste: el README, los scripts de build, las notas para ti mismo. Revisar el tuyo toma un minuto.
Este sitio se despliega solo. Un push a la rama principal está en vivo en gald.ai en segundos, sin que nadie suba nada. Es un buen trato, y lo volveríamos a montar.
Lo que no preguntamos, hasta que alguien abrió la URL equivocada, fue qué se copia exactamente. La respuesta era: todo lo que está en el repositorio. El README respondía con un 200. También los scripts de Python que arman las páginas, las plantillas y los archivos de workflow.
Qué termina publicado
Un sitio estático desplegado desde un repositorio no tiene una carpeta de salida aparte. El repositorio es la raíz web. Cada archivo que está al lado de tu HTML es una URL, la enlace algo o no.
- El README, que normalmente explica tu arquitectura, tu hosting y lo que todavía no terminas.
- Los scripts de build, que nombran rutas internas, variables de entorno y las decisiones detrás de ellas.
- Plantillas y fixtures, que suelen traer datos de prueba escritos cuando nadie miraba.
- Los archivos de workflow de CI, que nombran cada secreto que usa tu pipeline, aunque los valores se queden del lado de CI.
- Todo lo que alguna herramienta dejó en la carpeta: configuración del editor, un archivo de créditos, un export que pensabas borrar.
- El repositorio es la raíz web
- Se sirve todo lo que está en disco
- Reglas agregadas al final de la config
- Revisado una vez, al montarlo
- El servidor rechaza las rutas del repo
- Solo se sirve el sitio
- El rechazo antes de la regla general
- Revisado otra vez al agregar carpetas
En nuestro caso no quedó expuesto nada secreto. Revisamos cada archivo versionado buscando tokens, llaves y contraseñas, y apareció un marcador de posición dentro de un comentario, y el host ya rechazaba la carpeta .git. Eso fue suerte, no diseño.
Arreglarlo sin romper el sitio
El arreglo son unas pocas líneas de configuración, y el orden importa más que las líneas. Casi todas las configs tienen una regla arriba que dice: si la petición coincide con un archivo que existe, sírvelo y para. Un rechazo escrito después de esa regla nunca corre, porque el archivo sí existe. El rechazo tiene que ir primero.
Ahora un push es un deploy. Una configuración del servidor con un error tipográfico queda en vivo en todos lados en segundos, así que pruébala antes de que salga de tu máquina.
Probamos la nuestra contra una copia local de Apache antes del push: cada página real tenía que seguir respondiendo 200 con sus headers intactos, y cada ruta del repositorio tenía que ser rechazada. La primera corrida falló todo, incluida la portada, porque macOS no dejaba a Apache leer la carpeta del proyecto. Servir una copia desde un directorio temporal dio un resultado limpio, y correr las reglas viejas al lado de las nuevas demostró que la prueba coincidía con lo que hace el servidor real.
El minuto que toma revisar el tuyo
- Abre tu dominio seguido de /README.md. Después /package.json, /.env, /.git/config y el nombre de tu carpeta de build.
- Prueba un archivo que sepas que está en el repositorio pero no es parte del sitio. Un fixture de prueba sirve.
- Todo lo que responda con contenido en vez de un error está publicado, y lo está desde tu primer deploy.
- Repítelo la próxima vez que agregues una carpeta al proyecto, porque la respuesta cambia cuando cambia el repositorio.
Nada de esto es una emergencia si tu repositorio no guarda secretos, y ninguno debería. Aun así vale el minuto: el README que escribiste para ti se lee distinto cuando un desconocido puede abrirlo.