VPS para Moodle o Alojamiento Gestionado: El Coste Real

Contratar una VPS para Moodle cuesta menos de 20 € al mes y parece la solución obvia para quien se ha cansado del alojamiento compartido. La cuota mensual, sin embargo, es la parte pequeña de la factura. Esta comparativa muestra lo que ofrece la VPS y lo que recae en usted, cuánto cuestan realmente la actualización, la copia de seguridad y la seguridad en un año, y cuándo cada opción tiene sentido para una institución de EAD.

TL;DR

• Una VPS para Moodle ofrece máquina, red y acceso root. El sistema operativo, PHP, la base de datos, cron, la copia de seguridad, la actualización de Moodle y la respuesta a incidentes recaen en su equipo.
• Moodle lanza una versión mayor cada 6 meses y una versión menor cada 2 meses. Son al menos 8 ventanas de actualización al año, todas responsabilidad de quien administra el servidor.
• La copia de seguridad semanal que incluye el plan de la VPS no es una copia de seguridad de Moodle. Necesita una base de datos y moodledata consistentes, guardados fuera del servidor y con restauración probada.
• En una VPS, la cuota mensual rara vez supera el 20% del coste anual. El resto son horas técnicas y el riesgo de que el AVA se detenga en semana de exámenes.
• La VPS tiene sentido cuando existe un sysadmin con tiempo y disponibilidad. Sin eso, el alojamiento Moodle gestionado resulta más económico al año.

Qué compra cuando contrata una VPS para Moodle

Una VPS (servidor privado virtual) es una parte de un servidor físico con CPU, memoria y disco reservados para usted. El proveedor garantiza que la máquina se enciende, tiene red y tiene energía. De ahí en adelante, todo es suyo.

La página de planes de Hostinger, consultada el 18/10/2026, lo dice con todas las letras: el cliente recibe acceso root y es "responsable de su servidor virtual privado". No es un defecto de Hostinger. Es el modelo. Es válido para Hetzner, Contabo, DigitalOcean, Locaweb o cualquier otra.

Una VPS para Moodle solo se convierte en un AVA después de que alguien instala y mantiene, como mínimo:

• Sistema operativo actualizado, con firewall y acceso SSH reforzado.
• Servidor web (Nginx o Apache) apuntando a la carpeta correcta. Desde Moodle 5.1, esa carpeta cambió, como verá más adelante.
• PHP-FPM en la versión exigida por la release de Moodle, con OPcache y las extensiones obligatorias.
• Base de datos (MariaDB, MySQL o PostgreSQL) en la versión mínima soportada.
• Redis para sesiones y caché, porque el estándar en disco es el primer cuello de botella en día de exámenes.
• Cron a cada minuto. La documentación oficial es directa: sin el cron, "su sitio no funcionará correctamente".
• moodledata fuera de la carpeta pública, con permisos correctos.
• SSL, renovación automática del certificado, correo transaccional que no cae en el spam.
• Copia de seguridad, monitorización y alerta.

Nada de esto es difícil para quien lo hace todos los días. El problema es que casi ninguna institución de EAD tiene a alguien haciendo esto todos los días.

Quién se encarga de qué: VPS para Moodle vs alojamiento gestionado

La forma más honesta de comparar los dos modelos es preguntar quién responde por cada capa cuando algo sale mal. Ya hemos publicado la matriz genérica de alojamiento gestionado vs VPS. Aquí tiene la versión específica para Moodle:

Capa	VPS no gestionada	Alojamiento Moodle gestionado
Hardware, red, energía	Proveedor	Proveedor
SO, parches, firewall	Su equipo	Proveedor
PHP, base de datos, Redis, Nginx	Su equipo	Proveedor
Cron y tareas programadas	Su equipo	Proveedor
Actualización menor de Moodle (cada 2 meses)	Su equipo	Proveedor
Actualización mayor y plugins (cada 6 meses)	Su equipo	Proveedor, con su homologación
Copia de seguridad de la base de datos y moodledata	Su equipo	Proveedor
Prueba de restauración	Su equipo (casi nunca ocurre)	Proveedor, con periodicidad en contrato
Monitorización y alerta	Su equipo	Proveedor
Incidente fuera de horario	Quien atienda el teléfono	SLA contractual
Contenido, cursos, matrículas	Su equipo	Su equipo

Fíjese en la última línea. El alojamiento gestionado no exime a la institución del trabajo académico: la coordinación, tutoría y secretaría continúan con usted. Elimina el trabajo de infraestructura, que es precisamente lo que no es el negocio de la institución.

El SLA de la VPS no protege su AVA

Los proveedores de VPS anuncian 99,9% o 99,99% de disponibilidad. Este número mide si la máquina virtual está encendida. Si el PHP-FPM agota los procesos al abrir el cuestionario, la VPS está "en línea" y el alumno está viendo un error 502. Para el proveedor, no hubo incidente.

El calendario de Moodle que se convierte en trabajo en su VPS

Este es el punto que más afecta a quienes migran a una VPS para Moodle pensando que "es solo instalar". Moodle tiene un calendario fijo, publicado en la página oficial de releases:

• Versiones mayores cada 6 meses, en abril y octubre.
• Versiones menores cada 2 meses, en febrero, abril, junio, agosto, octubre y diciembre. Son ellas las que traen las correcciones de seguridad.
• Lanzamientos fuera de calendario cuando aparece una corrección de emergencia.

Situación de cada versión el 18/10/2026, según la misma página:

Versión	Lanzamiento	Fin del soporte general	Fin del soporte de seguridad
4.5 LTS	07/10/2024	06/10/2025	04/10/2027
5.0	14/04/2025	20/04/2026	05/10/2026 (finalizado)
5.1	06/10/2025	05/10/2026	19/04/2027
5.2	20/04/2026	19/04/2027	04/10/2027
5.3 LTS	05/10/2026	04/10/2027	01/10/2029

Quien aún ejecuta 5.0 está, hoy, sin ningún parche de seguridad. Detallamos las rutas de salida en la publicación sobre el fin del soporte de Moodle 5.1.

Actualización menor: rutina, pero no automática

En una VPS para Moodle, cada versión menor significa: descargar el código, mantener config.php y plugins, poner el sitio en mantenimiento, ejecutar la actualización por línea de comandos, limpiar cachés y verificar que nada se haya roto. En mi operación, esto lleva de una a dos horas por entorno cuando todo va bien. Son seis veces al año, como mínimo.

Actualización mayor: donde la VPS pasa factura

La versión mayor es otra historia. Tres ejemplos reales de 2025-2026 que llegan como sorpresa para quien administra su propia VPS:

1. La carpeta pública cambió en Moodle 5.1. Según la documentación de actualización, a partir de la 5.1 solo la carpeta /public debe ser accesible por la web, y el document root del servidor debe apuntar a ella. Sin este ajuste en Nginx o Apache, la actualización no avanza. Los plugins instalados vía git también deben ser reubicados.
2. El PHP eleva sus requisitos. Moodle 5.2 pasó a exigir PHP 8.3. Quien montó la VPS en Ubuntu 22.04 tiene PHP 8.1 en los repositorios estándar y necesita un repositorio externo o una actualización completa del sistema operativo. Ubuntu 24.04 ya incluye el 8.3.
3. El propio PHP caduca. Según la tabla oficial de PHP, PHP 8.2 pierde el soporte de seguridad el 31/12/2026. Una VPS que se quedó en 8.2 entra en 2027 con el intérprete sin corrección.

Cada actualización mayor requiere un entorno de homologación, prueba de los plugins de terceros y una ventana fuera del horario de clase. En un AVA con tema propio y media docena de plugins, calculo de 8 a 16 horas de trabajo técnico por versión mayor.

Copia de seguridad real en una VPS para Moodle

La mayoría de los planes de VPS incluyen alguna copia de seguridad. El de Hostinger, por ejemplo, es semanal. Parece suficiente hasta la primera pregunta difícil: si el servidor se corrompe el viernes, ¿la institución acepta perder seis días de entregas, calificaciones y mensajes del foro?

La documentación de copia de seguridad de Moodle lista tres cosas a proteger: la base de datos, la carpeta moodledata y el código (con plugins y personalizaciones). La base de datos y moodledata cambian constantemente y necesitan una copia frecuente. El volcado de la base de datos debe ser consistente, con opciones como --single-transaction, para no capturar datos "a medias".

Qué debe tener la copia de seguridad de una VPS para Moodle

• Base de datos y moodledata del mismo momento. Restaurar una base de datos del martes con archivos del domingo genera tareas que apuntan a archivos que no existen.
• Copia fuera de la VPS. Una instantánea en el mismo proveedor no protege de una cuenta bloqueada, un error de facturación o un incidente en el centro de datos.
• Retención. La eliminación accidental de un curso suele descubrirse días después. Una única copia, sobrescrita cada noche, no lo resuelve.
• Restauración probada. Una copia de seguridad que nunca ha sido restaurada es una hipótesis. Es también el elemento que primero desaparece de la rutina de quien administra una VPS solo.

Cuando la copia de seguridad del proveedor es suficiente

Para un entorno de pruebas, un curso piloto con pocos alumnos o un AVA que puede retroceder una semana sin perjuicio, la instantánea del proveedor sirve. Para una institución con examen que vale nota y certificado, no sirve.

Seguridad: lo que llega a la bandeja de entrada de quien tiene una VPS para Moodle

Moodle es un software maduro y con un equipo de seguridad activo. Esto también significa que los fallos son encontrados, publicados y corregidos durante todo el año. Un ejemplo: el 29/04/2026, el CERT-FR, centro de respuesta a incidentes del gobierno francés, publicó la alerta CERTFR-2026-AVI-0508, con siete vulnerabilidades en Moodle, entre ellas ejecución remota de código e inyección SQL. Las correcciones salieron en las versiones 4.5.11, 5.0.7 y 5.1.4.

Para quien tiene alojamiento gestionado, esta alerta es una tarea del proveedor. Para quien tiene una VPS para Moodle, es una pregunta: ¿quién en la institución leyó esta alerta, y en cuántos días aplicó la corrección?

El mínimo de seguridad que exige la VPS

• Suscribirse a los anuncios de seguridad de Moodle y aplicar las versiones menores sin retraso.
• Actualizar SO, PHP y la base de datos con la misma disciplina.
• Bloquear el inicio de sesión SSH por contraseña, usar clave y limitar intentos (fail2ban o equivalente).
• Poner un WAF delante del AVA y limitar las peticiones en rutas de inicio de sesión.
• Revisar plugins de terceros sin mantenimiento: son la puerta de entrada más común que encuentro en entornos heredados.
• Recordar la RGPD: el AVA guarda DNI, calificaciones y datos de menores en muchos casos. Una fuga por servidor desactualizado es un incidente de seguridad con deber de comunicación. Tratamos el tema en RGPD en Moodle.

Coste real de una VPS para Moodle en 12 meses

Vamos a la cuenta. Primero, la cuota mensual. Precios de Hostinger el 18/10/2026, sin impuestos de tarjeta y en contrato a largo plazo:

Plan	vCPU / RAM / NVMe	Precio promocional	Precio en la renovación
KVM 1	1 / 4 GB / 50 GB	€ 5,45/mes	€ 10,90/mes
KVM 2	2 / 8 GB / 100 GB	€ 7,99/mes	€ 14,18/mes
KVM 4	4 / 16 GB / 200 GB	€ 10,90/mes	€ 27,27/mes
KVM 8	8 / 32 GB / 400 GB	€ 21,81/mes	€ 47,27/mes

Dos observaciones. La renovación del KVM 4 cuesta 2,5 veces el precio de entrada; haga el cálculo con el valor de renovación, no con el promocional. Y el precio de una VPS no es estable: la alemana Hetzner reajustó el portfolio en abril de 2026 y de nuevo en junio, con algunas líneas más que duplicándose.

Para un AVA con algunos cientos de alumnos en pico, una VPS para Moodle razonable comienza en el rango de 4 vCPU y 16 GB. Esto da algo entre € 130,91 y € 327,27 al año solo de máquina. Cómo dimensionar por su pico real está en la guía de alumnos simultáneos en Moodle.

La parte que no aparece en la factura

Ahora, las horas. La estimación abajo es de mi operación, no un número de mercado. Ajuste para su realidad:

Tarea	Frecuencia	Horas/año (estimación)
Versiones menores de Moodle	6 al año	6 a 12
Versión mayor, con homologación	1 a 2 al año	8 a 32
Parches de SO, PHP y base de datos	mensual	12
Prueba de restauración de copia de seguridad	trimestral	8
Monitorización, alertas y pequeños incidentes	continuo	24 a 36
Total		58 a 100 horas

Ejemplo hipotético: si la hora técnica que usted paga cuesta € 27,27, esto da entre € 1.581,82 y € 2.727,27 al año. Incluso en el escenario optimista, la máquina es menos del 20% del coste. Y esta cuenta aún no incluye lo más caro: el AVA fuera de servicio la víspera de un examen, con la coordinación respondiendo alumno por alumno.

Cuándo cada opción tiene sentido para su institución

Ninguno de los dos modelos es adecuado para todo el mundo. El criterio que uso con los clientes es simple: ¿quién va a despertarse a las 3 de la mañana cuando el AVA se caiga?

La VPS para Moodle tiene sentido cuando

• La institución tiene un sysadmin Linux en plantilla, con tiempo reservado para el AVA y cobertura de vacaciones.
• Existe guardias reales en los períodos críticos: selectividad, semana de exámenes, inicio de semestre.
• El AVA es interno o de baja criticidad: formación corporativa opcional, entorno de pruebas, piloto.
• La política de TI exige control total del servidor, por ejemplo para integraciones con sistemas internos que solo se ejecutan en la red de la institución.

La VPS para Moodle no tiene sentido cuando

• El departamento de TI es una sola persona que también se encarga de la red, la impresora y el correo electrónico.
• Moodle genera ingresos: cursos de pago, posgrado EAD, certificación con plazo.
• No existe nadie que sepa decir cuándo fue la última prueba de restauración.
• La VPS fue montada por un freelancer que ya no está disponible, y nadie sabe la contraseña de root con certeza.

Señales de que es hora de abandonar la VPS

El AVA está dos o más versiones menores atrasadas. PHP está cerca del fin de su soporte. El disco se llenó sin aviso. La coordinación descubre que el sitio se cayó por el WhatsApp de los alumnos. Si dos de estos aparecen juntos, la decisión ya ha sido tomada por los hechos.

Trampas que vemos en VPS para Moodle heredadas

Gran parte de los entornos que asumimos proviene de una VPS que funcionó bien el primer año. Los problemas que se repiten:

1. Cron ejecutándose cada 15 minutos (o ni siquiera ejecutándose). Las notificaciones se retrasan, la finalización del curso no se calcula, los correos salen en lote.
2. moodledata dentro de la carpeta pública. Archivos de alumnos accesibles por URL directa.
3. Copia de seguridad que solo copia la base de datos. En la restauración, los cursos aparecen sin ningún archivo.
4. Sesiones en disco. En pico, el AVA desloguea a los alumnos en medio del cuestionario.
5. Disco lleno por logs y papelera. Moodle deja de grabar y nadie recibe alerta.
6. Plugins abandonados que bloquean la actualización. La institución queda atrapada en una versión sin soporte porque un plugin no tiene versión compatible.

Si su institución ya ha decidido salir, la hoja de ruta técnica está en cómo migrar Moodle de servidor sin perder datos.

Cómo Agathas Web resuelve esto

El alojamiento Moodle gestionado de Agathas Web existe para quitar la infraestructura de encima de la institución sin quitarle el control del AVA. En la práctica, lo que está incluido:

• Stack montada para Moodle: PHP 8.3 con OPcache, PHP-FPM con pool dedicado, Nginx, MariaDB 10.11+, Redis para sesiones y caché y cron aislado en worker propio. Sin cPanel y sin dividir CPU con sitios WordPress.
• Copia de seguridad diaria con binlog cada 15 minutos, copia offsite cifrada y restauración probada cada mes.
• Actualización de Moodle en hasta 90 días desde el lanzamiento, siempre pasando por homologación en staging, con ventana combinada con la coordinación.
• Seguridad: Cloudflare WAF, fail2ban, límite de peticiones en rutas críticas y hardening del sistema operativo.
• Monitorización con Grafana, Prometheus, Sentry y UptimeRobot externo, con alerta en el WhatsApp del equipo técnico.
• SLA en contrato: 99,9% de disponibilidad y respuesta en hasta 15 minutos para incidente crítico.

Cómo funciona la contratación

1. Diagnóstico: analizamos versión, plugins, tamaño de moodledata y pico de alumnos simultáneos.
2. Propuesta: el plan se dimensiona por su pico real, no por la media.
3. Migración asistida: en hasta 5 días hábiles, con homologación en staging y aprobación por escrito antes del cambio.
4. Cambio fuera del horario de clase, con el entorno antiguo preservado por 30 días para reversión.

Si un día la institución quiere salir, entregamos la copia de seguridad completa. Estoy certificado por la Moodle Academy y administro Moodle desde 2008, pero Agathas es independiente: no somos Moodle Partner, y el compromiso está en el contrato, no en el sello. Para pedir el diagnóstico, hable con el equipo a través de la página de alojamiento Moodle.

Conclusión: la VPS para Moodle es barata; administrarla, no

La elección entre VPS para Moodle y alojamiento gestionado no es una elección de precio de máquina. Es una elección de quien asume 8 ventanas de actualización al año, la copia de seguridad que necesita ser restaurada en horas y la alerta de seguridad que llega un viernes por la noche.

Si su institución tiene sysadmin y guardias, la VPS ofrece control y ahorro real. Si no los tiene, la cuota mensual baja esconde un coste anual varias veces mayor y un riesgo que recae sobre la coordinación en la peor semana del semestre.

El siguiente paso práctico: liste quién, hoy, ejecuta cada línea de la tabla de responsabilidades de esta publicación. Si varias quedan en blanco, vale la pena conocer el alojamiento Moodle gestionado de Agathas Web y pedir un diagnóstico de su entorno.