Abandonando WordPress: migrando mi sitio a Astro y SQLite

Durante años, andrew.khanoff.com funcionó con WordPress: PHP-FPM, una base de datos MySQL, un montón de plugins y el zumbido constante en segundo plano de "tu sitio necesita actualizarse". Funcionaba, pero eran 475 MB de archivos, una base de datos de 160 MB con 301 tablas, y una superficie de ataque que nunca pedí (xmlrpc.php, wp-login.php, el plugin de la semana). Para un CV personal que muestra principalmente texto, son muchas piezas móviles para parchear y preocuparse.

Así que lo reemplacé. Aquí está el porqué y el cómo.

Por qué dejar WordPress

• Superficie de ataque. Un CV estático no necesita un formulario de inicio de sesión en internet público, un sistema de comentarios o ejecución remota de código mediante plugins.
• Huella (Footprint). PHP + MySQL + núcleo de WordPress + plugins, solo para renderizar una página que cambia unas pocas veces al año.
• Control. Quería el contenido en un formato que yo posea, renderizado por código que pueda leer, sin ningún panel de administración accesible desde la web abierta.

El reemplazo es deliberadamente pequeño: una única aplicación Astro (renderizada en el servidor, adaptador Node) en un contenedor Docker, con SQLite como única fuente de verdad. Sin PHP. Sin MySQL. El administrador solo admite passkey y está bloqueado a la LAN en el proxy inverso. Los proyectos se redactan mediante un pipeline diario de GitHub→local-LLM, y los análisis son propios con una base de datos GeoIP local.

La regla: nada destructivo sin un camino de vuelta

Toda la migración se hizo en fases, y la primera fase no fue código, sino copias de seguridad. Antes de tocar cualquier cosa:

1. tar del directorio raíz completo de WordPress (350 MB comprimido).
2. mysqldump --single-transaction de la base de datos de WordPress (18 MB).
3. Sumas de verificación (checksums), y una extracción de prueba para demostrar que los archivos eran reales.

Solo entonces construí el nuevo sitio junto a WordPress, en un puerto temporal, sin tocar el vhost activo. WordPress siguió sirviendo el dominio todo el tiempo que se estaba construyendo y llenando el contenido con la nueva aplicación.

Cambio sin tiempo de inactividad (downtime)

El cambio en sí fue una modificación del proxy inverso, no una migración de datos. nginx pasó de servir /var/www/andrew.khanoff.com vía PHP-FPM a hacer proxy al nuevo contenedor en 127.0.0.1:8090:

location / {
    proxy_pass http://127.0.0.1:8090;
}

El antiguo vhost fue respaldado primero, nginx -t controló la recarga, y si algo hubiera parecido mal, el rollback fue un simple cp de la configuración antigua más una recarga. Los archivos y la base de datos de WordPress quedaron completamente intactos: solo que el dominio dejó de apuntar a ellos. Tiempo de rollback: segundos.

Dejé el nuevo sitio activo por un tiempo, verifiqué todo (páginas públicas, inicio de sesión con passkey, el pipeline de proyectos, exportación PDF, análisis), y solo entonces eliminé la base de datos de WordPress, después de tomar otro volcado fresco justo antes del DROP. Los 475 MB de archivos de WordPress se eliminaron al final, una vez que las copias de seguridad fueron verificadas nuevamente.

Qué es mejor ahora

• Seguridad: sin inicio de sesión público, sin PHP, sin plugins. El administrador está detrás de passkeys WebAuthn y una regla allow 10.0.20.0/24 en nginx. HSTS está activado.
• Rendimiento: Lighthouse móvil es 92 / 96 / 96 / 100 (Rendimiento / Accesibilidad / Mejores Prácticas / SEO), LCP ~1.4 s. La respuesta del servidor es de ~30 ms porque no hay baile de ida y vuelta con la base de datos; solo SQLite y Astro.
• Operaciones: todo el sitio es un contenedor y un archivo SQLite. Las copias de seguridad son triviales. La automatización interesante (GitHub + un LLM local) vive en una ruta por lotes sin conexión (offline batch path): si falla, el sitio no se da cuenta.
• Propiedad: el contenido está en SQLite y Markdown, en un repositorio git, renderizado por ~2k líneas de código que puedo leer realmente.

WordPress es una herramienta excelente. Simplemente no era la cantidad adecuada de maquinaria para un CV que quiero que sea rápido, aburrido de operar y seguro de dejar solo durante meses a la vez. Esta publicación, y el sitio en el que lo estás leyendo, son el resultado.