Episodio 009 — El puente hacia el hosting

Serie: bitácora de ingeniería — caprini.dev
Slug: 009-el-puente-hacia-el-hosting
Resumen: el dominio vive en un mundo donde no hay botón de deploy ni integración con el repo. Solo FTP o SFTP: el protocolo de hace décadas, todavía el estándar de muchos planes compartidos. La limitación no es “mala”: obliga a ser explícitos sobre qué subimos (solo el estático en dist/) y cómo lo probamos antes.

La limitación

Muchos hostings económicos siguen el modelo sube archivos al espacio web. No conocen tu rama main, no leen ástro.config, no ejecutan ñpm install. Para un sitio 100% estático como este blog, eso está bien: el artefacto ya es HTML, CSS y JS empaquetados por Astro. Lo que falta es el puente entre la carpeta local dist/ y el directorio remoto (public_html o equivalente).

Cómo lo resolvemos con código propio

En lugar de depender de un PaaS, definimos SPEC-002 (projects/002-deploy-bot/): un script Node que:

1. Confía en variables de entorno (FTP_HOST, FTP_USER, FTP_PASS) para no filtrar secretos.
2. Se invoca tras ñpm run build**, en un único comando **ñpm run deploy.
3. Limpia o sincroniza el destino remoto según configuración (sitio completo vs. solo sobrescritura).
4. Grita SITE ONLINE cuando termina bien — y deja rastro en AGENT_PERSISTENT_MEMORY.md cuando no, para que el agente y los humanos compartan el mismo diario de operaciones.

No es magia: es ingeniería de flujo aplicada a una restricción real del proveedor.

Nota de cierre

El repo sigue siendo la fuente de verdad; el hosting es solo el espejo público del build. El episodio anterior abría la Fase 2 de herramientas activas; este es uno de esos brazos: menos fricción entre “build local” y “mundo online”.