Cuándo alguien te dice que tiene un WordPress «en un VPS», suele significar una de dos cosas: o le ha instalado un panel de esos que te dan tres botones y una ilusión de control, o ha hecho una especie de apt install wordpress (ya lo sé, no existe, pero molaría) y reza cada noche para que nadie toque nada.
Ninguna de las dos me convence.
Llevamos años afinando un stack para WordPress que no usa paneles, no usa plugins milagrosos y no requiere que el cliente sepa qué es un daemon. La idea es simple: montar infraestructura transparente, estándar y que WordPress funcione como WordPress, sin sorpresas, sin dependencias raras, sin tener que llamar a nadie cuando algo se rompe.
Y sí, todo en un VPS. Sin más.
Ubuntu 24, porque sí
Partimos de Ubuntu 24.04. No por fe, sino porque es la base más documentada, más probada y con más respuestas cuando algo sale mal. Si entra alguien nuevo al equipo y sabe un mínimo de sistemas, ya sabe moverse. No hay que explicarle distros exóticas ni paquetes con nombres distintos.
SSH cerrado y puertos cambiados
Lo primero que hacemos es bloquear el acceso SSH por defecto y cambiar puertos. No es seguridad por oscuridad, es reducir el ruido. Los bots escanean el 22 a todas horas. Si cambias el puerto y limitas el acceso, tu log de autenticación deja de ser una novela de ciencia ficción y pasa a ser lo que tiene que ser: algo que puedes revisar de verdad.
Swap y limits: el colchón que nadie ve
Configuramos swap y ajustamos los security limits del sistema. WordPress tiene picos: una actualización de plugins, una subida de imágenes grande, un pico de tráfico por una campaña. Sin swap y sin limits bien configurados, el proceso simplemente muere, y el cliente ve un error 500 sin explicación. Con ellos, el sistema respira.
Fuentes alternativas para lo que importa
Añadimos los PPAs de Git, PHP y Redis:
ppa:git-core/ppa
ppa:ondrej/php
ppa:redislabs/redisUbuntu empaqueta versiones estables, que es fantástico para un servidor de correo, pero no para un stack que necesita PHP 8.4, la última versión de Redis y Git actualizado. Las versiones de los repositorios oficiales suelen ir un par de años por detrás. En WordPress, dos años es una eternidad.
Angie en lugar de nginx
Usamos Angie. Es un fork de nginx mantenido por gente que llevaba años contribuyendo al proyecto original. Mismos conceptos, misma configuración (si sabes nginx, sabes Angie) pero con desarrollo activo y funcionalidades que nginx tarda en incorporar (o que nunca incorpora).
Lo configuramos con HTTP/2 por defecto, GeoIP para saber de dónde vienen las peticiones, y ModSecurity con reglas específicas de WordPress. Esto último es clave: un WAF genérico bloquea requests legítimos de WordPress; uno calibrado para WordPress deja pasar lo que tiene que pasar y bloquea lo que no.
Si el cliente usa un proxy tipo Cloudflare, además tunelizamos el tráfico para que solo aceptemos conexiones desde las IP de ese proveedor. Si alguien intenta atacar directamente la IP del servidor, ni le contestamos.
curl compilado a mano
Compilamos curl con las últimas versiones de sus dependencias. Parece un detalle menor, hasta que te das cuenta de que la versión de curl de Ubuntu no soporta ciertos protocolos o cifrados que los API de pasarelas de pago y servicios externos ya exigen. Con WooCommerce y sus pasarelas de pago, no puedes permitirte que un curl antiguo te deje tirado.
DNS: lo que nadie revisa hasta que falla
Revisamos la resolución DNS. Un WordPress hace decenas de llamadas externas: API de plugins, pasarelas de pago, servicios de correo, actualizaciones del core. Si la resolución DNS es lenta o se cae, todo se hace lento, y el cliente culpa al servidor. Nos aseguramos de que el resolver local esté bien configurado y respondiendo rápido.
Netdata: los ojos del servidor
Instalamos Netdata Open Source como uno de los sistemas de monitorización. No es un panel de control, es un panel de verdad. Ves CPU, RAM, disco, red, procesos, contenedores… todo en tiempo real, con historial y alertas. Si algo se comporta raro, lo ves antes de que el cliente te escriba.
fail2ban para todo, no solo para SSH
Configuramos fail2ban tanto para accesos SSH como para web. Si alguien intenta hacer fuerza bruta contra wp-login.php o explota un endpoint de la REST API, fail2ban le corta el acceso. Es un filtro automático que trabaja las 24 horas sin quejarse.
Miles de IPs bloqueadas en iptables
Mantenemos una lista de varias decenas de miles de IP en una lista de denegación de iptables. Son IP que sabemos que son fuente de ataques, bots y escaneos. No es una solución elegante, pero es efectiva: si ya sabes que ciertas redes solo hacen ruido, no las dejas entrar. Es como poner una verja en un barrio donde sabes que hay carteristas.
MariaDB 11.8, configurado a medida
Instalamos MariaDB (ahora la 11.8) y la configuramos dependiendo de la CPU, la RAM y el disco del servidor. No es lo mismo un VPS con 2 núcleos y 2 GB que uno con 16 núcleos y 64 GB. Los inodos, los buffers, el tamaño de las tablas en memoria… todo se ajusta al hardware real.
En WordPress, la base de datos es el cuello de botella en el 90% de los casos. Si MariaDB está mal configurada, da igual lo rápido que sea el resto del stack.
PHP-FPM 8.4, ImageMagick y tamaños a medida
Instalamos PHP-FPM (por defecto 8.4) y compilamos ImageMagick en lugar de usar la versión del sistema. ¿Por qué? Porque la versión de Ubuntu suele ir por detrás, y porque ImageMagick es una de las dependencias que más conflictos da con WordPress cuando no está actualizada.
Ajustamos los tamaños máximos de subida para que el cliente pueda subir imágenes y archivos sin tener que tocar un php.ini — que, sinceramente, no debería tener que tocar nunca.
Redis para la caché de objetos
Instalamos Redis para la caché de objetos de WordPress. Es la pieza que hace que la base de datos respire: en lugar de ir a disco por cada consulta, las más frecuentes se sirven desde memoria. Con un tráfico medio, Redis reduce la carga de MariaDB a una fracción. Y un WordPress sin caché de objetos es como un coche sin turbo: funciona, pero no debería.
WP-CLI, listo para usar
Para acabar, dejamos instalado y configurado WP-CLI. Si el cliente necesita actualizar plugins, exportar datos o hacer un search-replace, lo tiene a un comando de distancia. Es la navaja suiza de WordPress, y tenerla lista significa que cualquier intervención se hace en segundos, no en minutos de «espera, que lo instalo».
Los sitios: cada uno en su sitio
Para cada sitio web, creamos un usuario exclusivo de base de datos (nunca compartimos credenciales entre clientes) y configuramos el virtualhost optimizado para cachés y las particularidades de WordPress: headers, compression, estáticos con larga expiración, reglas de reescritura limpias.
La filosofía es que el cliente entre a su WordPress y funcione. Sin tener que instalar un plugin de caché, sin tener que configurar permisos, sin tener que aprender sistemas. Todo lo que se pueda hacer «the WordPress way», se hace. Lo que requiera sistemas, ya está hecho.
Backups que no te encierran
Hacemos copias de seguridad de los VPS completos y, además, de cada sitio web a buckets S3 externos a nuestra infraestructura. Las copias son estándar: ficheros y base de datos, sin dependencias de plugins ni formatos propietarios. Si un cliente se descarga su backup, lo puede restaurar en cualquier servidor del mundo. No te necesitas a nosotros para recuperar tus datos. Ese es precisamente el punto.
En resumen, un stack estándar
El stack no es una colección de herramientas, es un criterio: estándar sobre exótico, transparente sobre mágico, simple sobre complicado. Si entras al servidor y sabes un poco de Linux, ves exactamente qué hay y cómo está montado. Si eres el cliente, usas WordPress normalmente y punto.
No hay panel que romperse, no hay plugin del que dependes, no hay formato raro que te encierre. Solo un servidor bien montado, haciendo lo que tiene que hacer.
Deja una respuesta