¿Cómo alojo esto?

Si te interesa saber cómo está desplegado este blog, vamos a analizarlo. No es una arquitectura compleja, pero cada decisión aquí tiene un motivo práctico: reducir la carga operacional al mínimo.

Para entenderlo, vamos a desglosarlo en tres partes: la pila tecnológica, la automatización y la seguridad.

1. La Pila Tecnológica

El sitio es completamente estático. No hay bases de datos ni procesos ejecutándose en el servidor; todo se resuelve en el tiempo de compilación (build time). Esto elimina una categoría entera de problemas de rendimiento y seguridad.

Astro 7

Uso Astro como generador de sitios estáticos (SSG). Lo que hace que Astro sea la elección correcta aquí es su arquitectura de “islas”. En lugar de enviar un paquete gigante de JavaScript al navegador, Astro solo envía el código estrictamente necesario para que la página sea interactiva. El contenido vive en archivos Markdown, lo que me permite escribir sin preocuparme por el diseño en cada post.

Tailwind CSS 4

Para los estilos uso Tailwind 4. La ventaja real de la versión 4 es que la configuración es mucho más directa y se integra nativamente con Vite. Esto significa que el flujo de desarrollo es inmediato; cambio una clase en el HTML y veo el resultado al instante sin lidiar con archivos de configuración masivos.

Cloudflare Pages

El despliegue final ocurre en Cloudflare Pages. Para contenido estático, es la opción más eficiente por tres razones:

• Latencia: El contenido se distribuye en la red global de Cloudflare (Edge), por lo que el sitio carga rápido sin importar dónde estés.
• Mantenimiento: No hay un servidor que parchear ni un sistema operativo que monitorear.
• Costo: La capa gratuita es más que suficiente para el tráfico de un blog técnico.

2. Flujo de Trabajo y Automatización

No escribo los archivos a mano cada vez. He implementado un flujo de automatización que asegura que cada post sea válido antes de que llegue al repositorio.

El Pipeline de CI/CD

El flujo de despliegue está dividido en dos etapas para evitar que un error de sintaxis rompa el sitio en producción:

1. Validación (GitLab CI): Cada push dispara un job que intenta compilar el sitio. Si el build falla, el despliegue se detiene automáticamente.

   build_validation:
     script:
       - pnpm install
       - pnpm run build
     only:
       - branches

2. Despliegue (Manual via Wrangler): Una vez validado el código, el despliegue se realiza mediante la CLI de Wrangler. Prefiero mantener este paso bajo control manual para decidir exactamente qué versión se hace pública.

3. Seguridad y Optimización

En lugar de configurar un servidor Nginx o Apache y pelear con sus configuraciones, la seguridad se maneja de forma declarativa a través de Cloudflare.

Uso cabeceras HTTP para endurecer el sitio contra ataques comunes:

X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=()

Para el SEO, la integración @astrojs/sitemap genera automáticamente el índice de URLs en cada build, el cual es referenciado en el robots.txt.

Conclusión

He sacrificado la capacidad de ejecutar código dinámico en el servidor a cambio de una carga operacional cercana a cero. Para un blog técnico, este es el trade-off correcto: priorizar la estabilidad y la velocidad de entrega sobre la complejidad de un backend.