Static-first: por qué elegimos Astro frente a un CMS

TL;DR — Para el blog de un estudio pequeño, un CMS con base de datos es sobre todo un pasivo que pagas cada día: un servidor que parchear, un login de admin que defender, un backup que probar. Astro invierte el trato: el contenido es Markdown en git, la salida es HTML estático y todo se reconstruye en CI. Pierdes una interfaz de admin pulida; ganas una superficie de ataque mínima, contenido versionado y un sitio que es prácticamente gratis de mantener. Esta misma página está construida así.

Durante años el reflejo era automático: un blog nuevo significaba WordPress o — si nos sentíamos modernos — Ghost. Ambos son excelentes en lo suyo. Pero “lo suyo” incluye correr una base de datos, un runtime de PHP o Node, una página de login expuesta a internet y un goteo constante de actualizaciones de seguridad que alguien tiene que aplicar de verdad. En un estudio pequeño que entrega trabajo de cliente toda la semana, ese alguien siempre está ocupado. Así que dejamos de recurrir a un CMS por defecto, reconstruimos nuestro cuaderno sobre Astro y no lo hemos echado de menos.

Lo que de verdad cuesta un CMS con base de datos

La función estrella de un CMS es el editor. El coste oculto es todo lo que mantiene ese editor vivo y seguro. Una instalación de WordPress es un servidor en ejecución permanente: un proceso PHP, una base de datos MySQL, un /wp-admin público y un ecosistema de plugins que es la superficie más atacada de toda la web. Ghost es más ligero y está mucho mejor diseñado, pero sigue siendo un servicio Node más una base de datos que parchear, respaldar y monitorizar.

Nada de eso es difícil por separado. Lo que se acumula es la carga de mantenimiento constante:

• Parcheo. Cada dependencia es un reloj corriendo. Te saltas una actualización crítica del CMS o de un plugin y estás a un escaneo automático de un sitio desfigurado o un minero de cripto.
• Un login que defender. Un panel de admin público invita a fuerza bruta y credential-stuffing para siempre. Ahora te toca a ti el rate-limiting, el MFA y la higiene tipo fail2ban.
• Backups que tienes que probar. Una base de datos es estado mutable, así que “¿el backup restaura de verdad?” pasa a ser una pregunta real con una respuesta real que preferirías no descubrir durante un incidente.
• Una factura. Incluso un CMS gestionado pequeño cuesta 15–30 $/mes, más tu tiempo, que es la parte cara.

Un CMS te pide defender un castillo. Un sitio estático le da al atacante un muro de ladrillo: no hay login, ni base de datos, ni runtime que comprometer.

Lo que te da apostar por lo estático

Astro es un generador de sitios estáticos: renderiza tu contenido a HTML, CSS y una pizca de JS en tiempo de build, y luego sirve archivos. Sin base de datos, sin servidor de aplicación en producción, sin login de admin. La fuente de verdad es Markdown en un repositorio git.

Esa única decisión rinde en cuatro direcciones:

1. Superficie de ataque casi nula. No hay nada donde iniciar sesión ni nada ejecutándose por petición. Un host estático sirve archivos. Las clases de vulnerabilidad que dominan los incidentes de CMS — inyección SQL, RCE de plugins, toma del admin — simplemente no tienen objetivo.
2. Git como fuente de verdad. Cada post es un diff revisable. Obtienes historial, ramas, rollback y blame gratis. ¿Quieres revertir una mala edición? git revert. ¿Quieres un segundo par de ojos? Abres un PR. ¿Quieres que una IA redacte un post? Escribe Markdown y abre un PR que revisas como cualquier otro cambio — sin plugin, sin token de API, sin acceso de escritura a una base de datos en vivo.
3. Velocidad y coste. Archivos estáticos tras un CDN son de lo más rápido y barato que ofrece la web. Sin cold starts, sin latencia de consultas, sin estrategia de escalado que escribir. El hosting suele ser literalmente gratis.
4. Reutilizas la pipeline que ya tienes. Si ya corres CI para el trabajo de cliente, el build del blog es un job más. Push a main, CI construye, la salida se despliega. Las mismas puertas de revisión y el escaneo de secretos en los que confías para el código ahora protegen tu contenido.

La experiencia de edición es el trade-off honesto. Markdown en un editor no es un WYSIWYG pulido, y no hay botón de “publicar” para un autor no técnico. Para un cuaderno de ingeniería escrito por las mismas personas que escriben el código, eso es una ventaja, no un defecto.

Cómo funciona en Astro

Las content collections de Astro convierten una carpeta de Markdown en datos tipados y validados. Defines un esquema una vez y Astro hace fallar el build si a un post le falta un campo o tiene el tipo equivocado — tu contenido recibe las mismas garantías que tu código.

// src/content/config.ts
import { defineCollection, z } from "astro:content";

const blog = defineCollection({
  type: "content",
  schema: z.object({
    title: z.string(),
    pubDate: z.date(),
    lang: z.enum(["en", "es"]),
    featured: z.boolean().default(false),
  }),
});

export const collections = { blog };

Eso es todo el “backend”. Los posts viven en src/content/blog/, el esquema impone la forma y una errata en tu frontmatter es un error de build que cazas en CI — no una página rota que descubres en producción.

Cuándo un CMS sigue siendo la elección correcta

Apostar por lo estático no es dogma. Recurre a un CMS de verdad cuando:

• Editores no técnicos publican a menudo y no deberían tocar git ni Markdown.
• Necesitas membresías, muros de pago o contenido restringido — cualquier cosa que requiera lógica de servidor por usuario en tiempo de petición.
• El contenido cambia muchas veces al día de manos de varios autores que necesitan una cola, roles y una interfaz de programación.
• Corres comercio o comentarios con estado en vivo, mutable y generado por usuarios.

Esas son necesidades reales, y ahí una base de datos se gana su sitio. Pero el cuaderno de ingeniería de un estudio no es nada de eso. Es un puñado de autores, posts poco frecuentes y contenido que se beneficia de la revisión.

La conclusión

Si tu blog se lee mucho más de lo que se escribe, y quienes escriben se manejan con un archivo Markdown y un PR, ve a lo estático por defecto. Astro más content collections te da contenido tipado, un build que ya sabes correr y un sitio con casi nada que atacar o parchear. Cambias un panel de admin elegante por menos avisos a las 2 de la mañana — y para un equipo pequeño, ese es el trato que te mantiene entregando.