“Lo probé en local y funcionaba” es la frase que más veces precede a una actualización de Moodle que sale mal en producción. Un entorno local no tiene el mismo PHP, la misma configuración de servidor ni el mismo volumen de datos que tu Moodle real, y esas diferencias son exactamente las que provocan sorpresas.
Un entorno de staging de verdad es una copia lo más fiel posible de producción: mismo código, misma base de datos, mismo PHP, mismos plugins. En esta guía vas a ver cómo montarlo bien, y sobre todo, cómo evitar el error más peligroso de todos: que el entorno de pruebas envíe correos reales a tus alumnos.
Qué es (y qué no es) un entorno de staging válido
Un staging válido para Moodle cumple tres condiciones:
- Mismo código y misma versión de Moodle que producción, no una instalación limpia.
- Copia real de la base de datos y de
moodledata, no datos de prueba inventados, los problemas reales aparecen con volumen y configuración reales, no con tres cursos de ejemplo. - Aislado de cualquier acción que afecte a usuarios reales: ningún correo, ninguna notificación, ningún webhook debe salir desde el entorno de pruebas hacia el exterior.
Un clon en local con Docker, un subdominio como staging.tudominio.com, o un servidor de pruebas separado son todos válidos, siempre que cumplan las tres condiciones anteriores.
El paso que más se olvida: bloquear el envío de correo
Este es, con diferencia, el error más costoso al montar un staging de Moodle: si copias la base de datos tal cual y no bloqueas el correo, cualquier prueba que hagas (enviar un mensaje de foro, calificar una tarea, simular una matrícula) puede disparar un correo real a un alumno o profesor de verdad, generando confusión y, en el peor caso, quejas de gente que recibe notificaciones sobre cursos o calificaciones que no corresponden al entorno real.
Antes de tocar nada más, añade esto al config.php del entorno de staging:
$CFG->noemailever = true;Con esta línea, Moodle bloquea el envío de cualquier correo saliente desde esa instancia, sin necesidad de tocar la configuración de cada usuario ni de cada curso.
Cómo montar el staging paso a paso
Clonar un Moodle es copiar tres componentes del mismo momento: el código, la base de datos y la carpeta moodledata. La clave está en ese “del mismo momento”. Si vuelcas la base de datos a las 10:00 pero copias moodledata a las 13:00, la base de datos tendrá referencias a archivos (adjuntos, entregas de tareas, imágenes de curso) que cree que existen y que en moodledata todavía no están (o al revés). En un Moodle con actividad, esa incoherencia se traduce en errores al abrir cursos o entregas en el clon. Si puedes, pon el sitio en modo mantenimiento un instante, o clona en la ventana de menos actividad.
1. Copia el código
rsync -avz /ruta/moodle/produccion/ /ruta/moodle/staging/2. Copia la base de datos
mysqldump -u usuario -p nombre_bd_produccion > backup_produccion.sql
mysql -u usuario -p nombre_bd_staging < backup_produccion.sql3. Copia moodledata
rsync -avz /ruta/moodledata/produccion/ /ruta/moodledata/staging/4. Ajusta config.php del staging
El config.php es lo único que no debe quedar idéntico a producción: es justo lo que le dice a esta copia que es otra instancia. Como mínimo cambia:
$CFG->wwwroot→ la URL del entorno de pruebas (p. ej.https://staging.tudominio.com). Si no lo cambias, Moodle redirige al dominio real y acabas navegando producción sin darte cuenta.$CFG->dataroot→ la ruta a la copia demoodledatadel staging, nunca la de producción.$CFG->dbname,$CFG->dbusery$CFG->dbpass→ las credenciales del esquema de staging, para que el clon no escriba en la base de datos real.
Y añade el bloqueo de correo mencionado arriba. El siguiente apartado reúne todos los ajustes de aislamiento en un único bloque.
5. Desactiva el cron real (o apunta a uno de pruebas)
Si el cron de producción está programado para ejecutarse cada minuto y el de staging apunta a la misma tarea, puedes acabar con dos instancias procesando las mismas tareas programadas de forma duplicada. Configura un cron independiente para el staging, o desactívalo mientras no lo necesites activamente.
6. Verifica el aislamiento antes de empezar a probar
Antes de hacer ninguna prueba real, confirma que:
- El correo está bloqueado (
$CFG->noemailever = true). - Cualquier integración externa (pasarela de pago, videoconferencia, webservices) apunta a un entorno de pruebas de esos servicios, no al real.
- El dominio de staging no es indexable por buscadores (añade una directiva
noindexo protégelo con autenticación HTTP básica).
Aislar el staging: qué apagar y por qué
Bloquear el correo es el primer paso, pero no el único. Un staging “vivo”: con una copia real de la base de datos, arrastra todas las integraciones que tenía producción configuradas: pasarelas de pago, videoconferencia, webservices, sincronizaciones con tu ERP o CRM. Si no las desactivas, una prueba inocente puede tener consecuencias reales.
El caso más caro es el de los cobros. Si tu Moodle cobra matrículas con una pasarela (PayPal, Redsys, Stripe…) y clonas la base de datos con esas credenciales de producción intactas, cada vez que pruebes el flujo de matrícula de pago estás lanzando una operación contra la pasarela real. En el mejor caso es un cobro de prueba que hay que anular a mano; en el peor, un alumno de verdad recibe un cargo por algo que nunca compró. Lo mismo pasa con las notificaciones: sin noemailever, calificar una tarea de prueba dispara el correo real al alumno real de esa entrega.
Reúne todos los ajustes de aislamiento en el config.php del staging:
// 1. Correo: bloquea CUALQUIER envío saliente desde esta instancia.
$CFG->noemailever = true;
// Alternativa si quieres inspeccionar los correos sin que lleguen a nadie:
// desvía TODO el correo a una única dirección de pruebas.
// $CFG->divertallemailsto = '[email protected]';
// 2. Cron: que solo pueda ejecutarse a mano por CLI, nunca por la web,
// para no duplicar tareas programadas que ya corre producción.
$CFG->cronclionly = true;
// 3. Identidad de la instancia (esto ya lo ajustaste en el paso 4).
$CFG->wwwroot = 'https://staging.tudominio.com';
$CFG->dataroot = '/ruta/moodledata/staging';Las pasarelas de pago y las integraciones externas no se apagan desde config.php: se configuran en cada plugin. Entra en la administración del staging y, para cada método de pago, o bien cámbialo a las credenciales sandbox que ofrece el proveedor, o desactívalo del todo mientras pruebas. Revisa igualmente cualquier plugin que hable con un servicio externo (videoconferencia, facturación, LTI hacia otra plataforma) y apúntalo a su entorno de pruebas.
| Elemento a aislar | Por qué | Cómo |
|---|---|---|
| Correo saliente | Las notificaciones (foros, calificaciones, matrículas) llegarían a alumnos reales | $CFG->noemailever = true; en config.php |
| Cron / tareas programadas | Dos instancias procesando lo mismo duplican avisos y trabajos programados | $CFG->cronclionly = true; y no programar el cron del staging |
| Pasarelas de pago | Una prueba de matrícula lanzaría un cobro real contra PayPal/Redsys/Stripe | Credenciales sandbox o desactivar el método en su plugin |
| Videoconferencia / LTI | Crear una sala o lanzar una actividad afectaría al servicio real | Apuntar a la instancia de pruebas del proveedor |
| Webservices / API salientes | Sincronizaciones con ERP/CRM escribirían datos reales | Desactivar los tokens o apuntar a un endpoint de pruebas |
| Indexación en buscadores | Google indexaría contenido duplicado o datos de alumnos | noindex + autenticación HTTP básica en el subdominio |
Refrescar el staging desde producción
Un staging es una foto de producción tomada un día concreto. Cuanto más tiempo pasa, menos se parece al Moodle real: entran matrículas nuevas, se crean cursos, cambia la configuración. Probar una actualización sobre una copia de hace tres meses es probarla sobre un sitio que ya no existe. Por eso conviene refrescar el staging (repetir el clonado de código, base de datos y moodledata) antes de cada prueba importante, no solo la primera vez.
Y aquí está el error que más veces vemos entrar por soporte, que es el del correo pero al revés: al volver a copiar producción sobre el staging, rsync sobrescribe también el config.php del clon, que vuelve a apuntar al dominio real, a la base de datos real y (lo peligroso) borra tu $CFG->noemailever. Es decir: refrescas el staging para tenerlo al día y, sin querer, lo reconviertes en una segunda copia de producción con el correo abierto.
Para evitarlo, excluye siempre config.php del refresco (o guárdalo antes y restáuralo después):
rsync -avz --exclude='config.php' /ruta/moodle/produccion/ /ruta/moodle/staging/Tras cada refresco, vuelve a verificar el aislamiento del paso 6 antes de tocar nada. Refrescar y volver a aislar el staging es, de hecho, el paso cero de cualquier cambio serio: tanto el checklist de actualización como el proceso completo de migración y actualización dan por hecho que pruebas sobre una copia fiel y aislada antes de tocar producción.
Privacidad de los datos en el entorno de pruebas
Si tu staging contiene una copia real de datos de alumnos, sigue estando sujeto a las mismas obligaciones de protección de datos que producción, no es un espacio “sin reglas” solo por ser de pruebas. Restringe el acceso al staging con autenticación adicional, y valora anonimizar los datos personales más sensibles si el entorno va a ser accesible para más personas de las que tienen acceso a producción.
Alternativas según tu volumen y recursos
| Método | Cuándo usarlo |
|---|---|
| Subdominio en el mismo servidor | Volumen pequeño-medio, sin recursos para un servidor adicional |
| Servidor de staging separado | Volumen alto, o cuando quieres aislar completamente el impacto en rendimiento |
| Contenedor Docker | Equipos técnicos que ya trabajan con contenedores y quieren staging desechable y reproducible |
| Snapshot de VPS | Si tu proveedor de VPS permite clonar el servidor completo con un clic, es la opción más rápida de levantar |
Errores comunes al montar un staging
- No bloquear el correo saliente, provocando notificaciones reales a usuarios reales durante las pruebas.
- Usar datos de prueba inventados en vez de una copia real, lo que oculta problemas que solo aparecen con volumen real de datos.
- Dejar el cron de staging duplicando tareas que ya ejecuta producción.
- No aislar integraciones externas, arriesgándose a que una prueba dispare un cobro real o una videollamada real.
- Dejar el staging indexado y accesible públicamente sin ninguna protección adicional.
Preguntas frecuentes
¿Es obligatorio tener un entorno de staging para actualizar Moodle? No es obligatorio técnicamente, pero es la única forma fiable de detectar problemas de plugins o configuración antes de que afecten a usuarios reales.
¿Puedo usar el mismo servidor para staging y producción?
Sí, mediante un subdominio separado, siempre que el staging tenga su propia base de datos y moodledata, y esté correctamente aislado en cuanto a correo y cron.
¿Qué pasa si olvido bloquear el correo en staging? Cualquier acción que dispare una notificación (mensajes de foro, calificaciones, matrículas) puede enviar un correo real a un alumno o profesor, generando confusión sobre qué entorno es cuál.
¿Cuánto tiempo debería mantener activo un entorno de staging? Al menos durante todo el proceso de prueba de una actualización o migración, y es buena práctica mantenerlo de forma permanente como herramienta para futuras pruebas, no solo para un cambio puntual.
¿El staging necesita los mismos recursos de servidor que producción? Idealmente sí, para que las pruebas de rendimiento sean representativas, aunque para pruebas puramente funcionales (plugins, actualizaciones) unos recursos algo menores suelen ser suficientes.
¿Cómo evito que Google indexe mi entorno de staging?
Añadiendo una directiva noindex en las cabeceras o el robots.txt de ese subdominio, y preferiblemente protegiéndolo también con autenticación HTTP básica.
¿Puedo probar integraciones de pago o videoconferencia en staging? Sí, pero apuntando a los entornos de pruebas (“sandbox”) que ofrecen la mayoría de estos servicios, nunca a las credenciales de producción.
¿Necesito volver a copiar producción a staging cada vez que voy a probar algo? Es recomendable refrescar el staging periódicamente, sobre todo antes de una prueba importante, para que los datos reflejen el estado real de producción y no una copia desactualizada.
¿Cómo refresco el staging sin volver a abrir el correo saliente?
Excluye config.php del clonado (rsync --exclude='config.php') o guárdalo antes y restáuralo después. El config.php del staging es el que contiene tu $CFG->noemailever y las credenciales de pruebas; si lo sobrescribes con el de producción, el clon vuelve a enviar correos reales. Tras cada refresco, revisa de nuevo el aislamiento antes de probar.
¿Puedo clonar solo la base de datos sin copiar moodledata?
No. La base de datos guarda las referencias a los archivos, pero los archivos en sí (adjuntos, entregas, recursos) viven en moodledata. Si copias solo la base de datos, el clon apuntará a ficheros que no existen y verás errores al abrir cursos o entregas. Los tres componentes (código, base de datos y moodledata) van juntos y del mismo momento.
¿Basta con $CFG->noemailever para aislar del todo el staging?
No del todo. Ese ajuste solo corta el correo. Falta desactivar el cron para que no duplique tareas ($CFG->cronclionly = true; y no programarlo), poner las pasarelas de pago en modo sandbox o apagarlas, y apuntar cualquier integración externa (videoconferencia, webservices) a su entorno de pruebas. El correo es el olvido más frecuente, pero no el único.
Conclusión
Un entorno de staging bien montado (con datos reales, pero completamente aislado de cualquier efecto sobre usuarios reales) es la diferencia entre detectar un problema antes de que afecte a un alumno, o después. El detalle que más se paga por olvidar no es técnico complicado: es simplemente bloquear el correo saliente antes de empezar a probar.
Si prefieres no tener que montar y mantener tú mismo este entorno cada vez que toca actualizar o migrar, en Avantys lo incluimos como parte del proceso de mantenimiento de cada Moodle que gestionamos. Puedes pedir una auditoría gratuita en Moodle Gestionado.
Artículos relacionados
- Mantenimiento y hosting Moodle: guía completa
- Cómo actualizar Moodle 3.x a 4.5 LTS paso a paso
- Migrar Moodle a un nuevo servidor sin perder cursos
- Plugins de Moodle incompatibles: cómo detectarlos antes de actualizar
- Checklist de actualización de Moodle sin downtime
¿Y si tu Moodle lo lleváramos nosotros?
Actualizaciones, backups verificados, rendimiento y trazabilidad FUNDAE, gestionado de forma continua por una persona que responde. Auditoría gratuita de tu plataforma actual.
