Web

De WordPress y VPS a Sitio Estático: Mantenimiento Cero y Paz Mental

25 Jan, 2026 • 5 min de lectura

Durante años mantuve este blog (y otros proyectos) en un servidor VPS propio con Ubuntu y WordPress. Si has administrado servidores, sabes lo que eso significa: una constante lucha contra la entropía.

Contenidos

1. El Ciclo Sin Fin del Mantenimiento
2. El Cambio de Paradigma: Static Site Generator
3. Conclusión
4. Caveats y Cosas a Tener en Cuenta

El Ciclo Sin Fin del Mantenimiento

Tener tu propio VPS te da control total, pero también responsabilidad total. Mi rutina incluía:

• Actualizaciones del Sistema Operativo: apt update && apt upgrade cada semana, vigilando que ninguna librería rompiera PHP o MySQL.
• Seguridad: Configurar firewalls (UFW), Fail2Ban para los intentos de login por SSH, y preocuparse por cada vulnerabilidad de Linux (como Dirty COW o similares).
• WordPress: El núcleo de WP se actualiza, los plugins se actualizan, el tema se actualiza. Y a veces, una actualización de un plugin rompe el sitio.
• Base de Datos: Backups de MySQL, optimización de tablas, y el miedo constante a una inyección SQL.

Era funcional, sí. Pero requería “cariño” constante. Si me iba de vacaciones dos semanas, volvía rezando para que el servidor no hubiera caído o hubiera sido hackeado por no aplicar un parche de seguridad crítico del día anterior.

El Cambio de Paradigma: Static Site Generator

Cansado de administrar infraestructura para un sitio que es esencialmente contenido de lectura, decidí migrar a una arquitectura moderna, “espartana” pero indestructible: Generador de Sitios Estáticos (Jekyll).

La Nueva Arquitectura

1. Código Fuente: Todo el contenido está en archivos Markdown en un repositorio de GitHub.
2. Motor: Usamos Jekyll para transformar ese Markdown en HTML puro.
3. Hosting: Cloudflare Pages.
4. CMS: Sveltia CMS (para escribir cómodamente desde el navegador sin tocar código si no quiero).

¿Por qué el cambio?

1. Mantenimiento Cero: Esta es la clave. Ya no hay servidor que actualizar. No hay base de datos que mantener. No hay PHP que parchear. Cloudflare se encarga de servir el HTML. El sitio podría estar ahí 10 años sin que yo toque una tecla, y seguiría funcionando igual de rápido y seguro.

2. Velocidad y Seguridad: Al servir HTML estático desde la CDN de Cloudflare, la velocidad de carga es instantánea en cualquier parte del mundo. Y la superficie de ataque es prácticamente nula: no puedes hackear una base de datos que no existe.

3. Versionado: Todo cambio queda registrado en Git. Si rompo algo, puedo volver atrás en segundos. Tengo un historial perfecto de cada coma que he cambiado en el blog.

Detalles Técnicos: Bajo el Capó

Para los curiosos, este es el stack tecnológico que sustituye al viejo LAMP (Linux, Apache, MySQL, PHP):

• Generador: Jekyll 4.2. Elegido por su madurez y simplicidad.
• Estilos: Tailwind CSS + DaisyUI. Adiós a los estilos en cascada inmanejables; ahora el diseño es atómico y mantenible.
• Hosting: Cloudflare Pages. Se encarga del SSL, la CDN global y los deploys atómicos.
• CMS: Sveltia CMS. Un panel de administración ligero que vive en el propio repo y hace commits directos a GitHub.
• Formularios: Resend API + Cloudflare Functions. Serverless real, sin servidores SMTP que configurar.

El flujo de publicación es ahora 100% GitOps:

1. Escribo un post (en local o vía CMS).
2. git push.
3. Cloudflare detecta el cambio, compila el sitio en segundos y lo despliega.

Conclusión

La migración no fue trivial (convertir base de datos a Markdown tiene su miga), pero el resultado es liberador. He pasado de ser un SysAdmin de mi propio blog a simplemente ser un Editor.

El sitio es más simple, sí. Pero esa simplicidad es su mayor fortaleza.

Caveats y Cosas a Tener en Cuenta

Aunque la solución es robusta, hay ciertos límites y comportamientos de Cloudflare Pages y el ecosistema gratuito que conviene conocer:

Tiempos de Despliegue

Cuando actualizas un post, los cambios no son inmediatos. El proceso de build y deploy puede tardar unos 5 minutos. Esto es intencional y necesario: durante este tiempo se ejecutan scripts que aseguran la consistencia de categorías, tags y enlaces, garantizando el buen funcionamiento del sitio. Paciencia.

Límites del Plan Gratuito (Cloudflare Pages)

Para un blog normal es difícil alcanzar estos techos, pero existen:

• 500 builds al mes: Cada push al repositorio (rama principal o preview) dispara un build que cuenta en contra de este límite.
• 1 build concurrente: Si disparas varios seguidos, se encolan.
• 20.000 ficheros por sitio: Límite para archivos HTML, CSS, imágenes, etc.
• Requests y ancho de banda: Son “ilimitados” para contenido estático en el plan gratuito, así que el tráfico de lectura no es un problema.

Sobre tu caso (muchos pequeños cambios)

Si estás usando el build integrado (repo conectado), cada commit/push que dispare un build cuenta contra los 500 del mes. Si algún día te acercaras al límite (por ejemplo, con CI que deploya en cada push), puedes:

1. Agrupar cambios: Hacer menos pushes juntando varias ediciones.
2. Construir externamente: Construir Jekyll localmente o en GitHub Actions y subir el artefacto a Pages. En ese modo, el límite pasa a ser básicamente el rate limit de la API, evitando consumir los 500 builds mensuales.

Categorías: Web Servidores

Etiquetas: jekyll cloudflare wordpress migracion static-site