Alojar WordPress en su propio VPS

Por qué autoalojar WordPress en un VPS

Las ganancias de un WordPress en VPS

• Recursos de CPU/RAM garantizados: se acabaron las ralentizaciones por culpa de los vecinos
• Control total de PHP-FPM, del servidor web y de las extensiones
• Caché de objetos Redis y caché de páginas para dividir los tiempos de respuesta
• Acceso SSH/WP-CLI completo para automatizar el mantenimiento y los despliegues
• Aislamiento por contenedor: varios sitios de clientes en un solo VPS
• Copias de seguridad y reglas de seguridad definidas por usted, sin sobrecosto por sitio

Requisitos realistas

Despliegue paso a paso

1. 01

   Componer WordPress, MariaDB y Redis

   En docker-compose.yml, declare wordpress:php8.3-fpm o wordpress:apache, un servicio mariadb:11 y redis:alpine. Persista wp-content y la base de datos en volúmenes con nombre, en una red Docker interna.

2. 02

   Indicar la base de datos y los secretos

   Pase WORDPRESS_DB_* y contraseñas robustas mediante variables de entorno. Añada las claves de seguridad (salts) generadas desde la API oficial de WordPress en WORDPRESS_CONFIG_EXTRA.

3. 03

   Arrancar e instalar WordPress

   Arranque con docker compose up -d y luego abra su dominio para el asistente de instalación. Mejor aún: automatice mediante WP-CLI (wp core install) para lograr despliegues reproducibles de un sitio a otro.

4. 04

   Colocar el reverse proxy y el SSL

   Configure Nginx/Caddy en HTTPS delante de WordPress. Ajuste client_max_body_size para las subidas, active la compresión gzip/brotli y la caché de los recursos estáticos (imágenes, CSS, JS) con cabeceras Cache-Control largas.

5. 05

   Activar la caché de objetos Redis

   Instale un plugin de caché de objetos (p. ej. Redis Object Cache), apúntelo al servicio redis y actívelo: las consultas repetidas a la base de datos se sirven desde la memoria, aliviando notablemente MariaDB.

6. 06

   Endurecer y respaldar

   Desactive la edición de archivos en la administración (DISALLOW_FILE_EDIT), limite los intentos de conexión y programe una copia de seguridad nocturna de wp-content + volcado SQL hacia un almacenamiento de objetos remoto.

7. 07

   Conectarse por primera vez

   Abra la URL del sitio: WordPress lanza su instalación en 5 minutos — idioma, título del sitio y después la creación de SU identificador de administrador con la contraseña y el correo que usted elija. Termínela sin esperar: una instalación inacabada queda ofrecida al primer visitante.

Alerta PHP del 21/10/2026 (PHP2Shell): actualizar WordPress no corrige PHP

Comprobar y corregir en cinco gestos

1. 08

   Leer la versión de PHP realmente servida

   Lo más fiable está en WordPress: Herramientas > Salud del sitio > Información > Servidor muestra la versión de PHP que ejecuta sus páginas. En un VPS sin Docker, desconfíe de php -v: consulta el binario de línea de comandos, que puede ser otra versión que PHP-FPM, el que atiende a sus visitantes. Pregunte al servicio mismo con php-fpm -v (o php-fpm8.3 -v en Debian y Ubuntu).

2. 09

   Comprobar la versión dentro del contenedor

   Con Docker, ejecute docker compose exec wordpress php -v: la imagen incluye un solo PHP, así que el resultado vale para el FPM o mod_php del contenedor. Compárelo con las versiones corregidas de arriba, manteniendo la misma rama (8.3.x debe llegar a 8.3.36, no a 8.4.27).

3. 10

   Descargar la imagen actualizada

   Ejecute docker compose pull && docker compose up -d. El pull descarga la última imagen publicada para su etiqueta (por ejemplo wordpress:php8.3-fpm), y up -d recrea el contenedor con ella. Sus volúmenes con nombre conservan wp-content y la base de datos. Si php -v aún muestra una versión antigua, la imagen corregida todavía no está publicada para esa etiqueta: vuelva a comprobarlo más tarde, o cambie de rama de PHP si su sitio la admite.

4. 11

   Reiniciar PHP-FPM

   Actualizar un paquete o unos archivos no cambia el código ya cargado por los procesos en curso. En un servidor clásico, reinicie el servicio con systemctl restart php8.3-fpm (adapte el número de versión); con Docker basta recrear el contenedor, o si no docker compose restart wordpress. Un simple reload es menos fiable que un restart si necesita que todos los workers se renueven.

5. 12

   Buscar rastros de explotación

   Una actualización cierra la puerta, pero no dice si alguien ya entró. Revise los registros de acceso y de error de Nginx o Apache (docker compose logs --since 72h wordpress con Docker) en busca de caídas de workers de PHP-FPM, mensajes de falta de memoria repetidos y peticiones inusuales de gran volumen. Dentro de wp-content, liste los archivos .php modificados recientemente con find wp-content -name '*.php' -mtime -7, sobre todo en uploads, donde no debería haber ningún script. Ante la menor duda, restaure desde una copia limpia y cambie contraseñas y salts.

6. 13

   Automatizar la comprobación con WP-CLI y cron

   Tenga en cuenta que wp --info indica la versión de PHP de la línea de comandos, no la de PHP-FPM: resérvelo para scripts, no para juzgar la exposición web. Programe mejor una tarea cron semanal que ejecute docker compose pull, compare la salida de docker compose exec wordpress php -v con la versión esperada y le avise por correo si no coincide. Así, la próxima alerta de seguridad de PHP ya no depende de su memoria.

7. 14

   Verificar de nuevo

   Vuelva a abrir Salud del sitio y repita php -v en el contenedor: ambos deben mostrar una versión corregida. Anote la fecha en su registro de mantenimiento y repita la rutina con cada nueva publicación de seguridad de PHP.