«¿Qué hosting necesito para Moodle?» es una pregunta que casi siempre llega con el número equivocado: la cantidad de alumnos registrados. Ese dato sirve de poco. Lo que dimensiona un servidor de Moodle es cuántas personas hacen cosas al mismo tiempo, y eso cambia mucho entre un martes cualquiera y el día del examen final.
Alumnos registrados no es lo mismo que usuarios concurrentes
La documentación oficial de Moodle lo explica con un ejemplo: si una página tarda 0,1 segundos en generarse y diez personas la piden en el mismo segundo, el servidor tiene de media un usuario concurrente. Si la misma página tarda un segundo, ya son diez. Por eso la concurrencia depende tanto de cuánta gente hay como de lo rápido que responde el servidor.
Una academia con 3.000 alumnos registrados puede tener, en un día normal, una carga muy baja. La misma academia, con un examen de 200 alumnos que empieza a las 19:00 en punto, tiene un pico que puede tumbar un servidor mal dimensionado.
Las preguntas útiles son otras:
- ¿Cuántos alumnos se conectan en la hora más cargada de la semana?
- ¿Hay exámenes o entregas con horario fijo para muchos alumnos a la vez?
- ¿Los cursos usan vídeo alojado en el propio Moodle, SCORM pesados o muchos cuestionarios?
La cifra de referencia de Moodle
La FAQ de rendimiento de Moodle da una referencia conservadora: en el peor caso, un sitio puede atender entre 10 y 20 usuarios concurrentes por cada GB de memoria, y cada proceso de Moodle puede usar más de 50 MB de RAM. La misma documentación advierte que sobreestimar la concurrencia sale caro y recomienda medir con un piloto en lugar de adivinar.
Con esa referencia, la tabla siguiente es un punto de partida orientativo, no una regla. El tamaño real lo dan las mediciones de tu propia plataforma.
| Escenario | Concurrencia en hora pico | Punto de partida razonable |
|---|---|---|
| Academia pequeña, cursos grabados, sin exámenes simultáneos | Hasta 20–30 | VPS de 2 vCPU y 4 GB de RAM, base de datos en el mismo servidor |
| Academia mediana, cuestionarios frecuentes | 50–100 | 4 vCPU y 8 GB, con caché en Redis y disco SSD/NVMe |
| Exámenes con cientos de alumnos a la misma hora | 150 o más | 8 vCPU y 16 GB o más, base de datos separada y pruebas de carga antes del examen |
Lo que pide Moodle hoy (versión 5.3)
Moodle 5.3 es la versión LTS publicada en octubre de 2026. Sus requisitos mínimos son:
- PHP 8.3 o superior (también admite 8.4), solo en 64 bits, con la extensión
sodiumymax_input_varsde al menos 5000. - Base de datos: PostgreSQL 17, MySQL 8.4 o MariaDB 11.4 como mínimo. Oracle ya no está soportado desde Moodle 5.0.
- Actualización: solo se puede llegar a 5.3 desde Moodle 4.4 o posterior.
Muchos hostings compartidos todavía ofrecen versiones de MariaDB o PostgreSQL anteriores a esas. Es uno de los motivos más frecuentes por los que una academia «no puede actualizar».
Más allá de la RAM: qué configurar
Dos servidores con la misma memoria pueden rendir de forma muy distinta. Estos son los ajustes que más diferencia marcan en nuestra experiencia:
- OPcache activado y bien dimensionado. Evita que PHP compile el código de Moodle en cada petición.
- Caché de aplicación y sesiones en Redis. Moodle tiene su propio sistema de caché (MUC). Llevarlo a Redis en lugar del disco reduce mucho la carga en momentos de pico.
- PHP-FPM con un número de procesos acorde a la memoria. Demasiados procesos agotan la RAM; muy pocos dejan alumnos esperando.
- El cron ejecutándose cada minuto. Moodle depende del cron para notificaciones, copias de cursos, informes y limpieza. Un cron mal configurado produce errores difíciles de rastrear.
- moodledata en disco rápido y fuera del directorio público de la web.
- Document root apuntando a
/public. Desde Moodle 5.1 la parte accesible desde la web vive en esa carpeta. Si el servidor apunta a la raíz antigua, el sitio puede mostrar listados de directorios o errores. - Copias de seguridad de la base de datos y de moodledata, guardadas fuera del servidor y con restauración probada.
Errores de hosting que vemos a menudo
- Hosting compartido para una academia con exámenes. Funciona con poco tráfico y falla justo cuando más importa.
- Vídeos subidos directamente a Moodle. Llenan el disco y consumen ancho de banda. Es mejor alojarlos en una plataforma de vídeo e insertarlos.
- Nadie mira el servidor hasta que se cae. Sin monitorización no sabés que el disco está al 95 % hasta que Moodle deja de guardar entregas.
- Escalar a ciegas. Duplicar la RAM no arregla un cron roto ni una consulta lenta a la base de datos.
Cómo saber si tu servidor está bien dimensionado
- Revisá el informe de rendimiento y el de estado del sistema en la administración de Moodle.
- Medí las peticiones por segundo en la hora pico con los registros del servidor web.
- Antes de un examen masivo, hacé una prueba de carga con un número de usuarios similar al real.
Servidor administrado para academias
En Puro Web Design configuramos y administramos servidores para Moodle y WordPress: dimensionamiento, caché, cron, copias de seguridad, actualizaciones de seguridad y preparación para los picos de matrícula y exámenes. Si ya tenés servidor, también podemos revisarlo y administrarlo.
Ver el servicio para academias · Consultar por WhatsApp
