Por qué actualizar ahora
Mattermost publica versiones ESR (Extended Support Release) con una vida útil ampliada y después declara su fin de vida en una fecha anunciada con antelación. La ESR v10.11 está en fin de vida desde el 15 de agosto de 2026. A partir de esa fecha, ningún parche de seguridad se retroporta a esa rama: las vulnerabilidades descubiertas después de la fecha de EOL quedan abiertas en las instancias que no migran.
Una mensajería de equipo recibe archivos adjuntos, credenciales compartidas por mensaje directo y, a veces, claves de API pegadas en un mensaje. Una instancia sin parchear expone esos datos a cada corrección no aplicada. La v11 es la LTS en curso de ciclo — es la única versión que seguirá recibiendo parches durante varios meses más.
Lo que aporta la v11 LTS frente a la ESR v10.x
- Parches de seguridad activos — la rama recibe los parches de seguridad publicados por el equipo de Mattermost a lo largo de todo su ciclo de soporte.
- Mejoras de rendimiento — optimizaciones de las consultas PostgreSQL y menor consumo de memoria bajo carga elevada.
- Interfaz de videollamadas rediseñada — calidad y estabilidad mejoradas para las llamadas en canales.
- Plugins actualizados — los plugins oficiales (Calls, Boards, Playbooks) tienen versiones compatibles con la v11 publicadas en el gestor de plugins.
- Correcciones de migración de base de datos — las migraciones acumuladas desde la v10 se aplican correctamente, lo que mejora la integridad del esquema a largo plazo.
- Soporte ampliado — la v11 LTS contará con una ventana de soporte prolongada, lo que le evita una nueva migración a corto plazo.
Requisitos previos antes de empezar
Compruebe los siguientes puntos antes de lanzar el procedimiento.
Docker Compose v2 — el comando debe responder a docker compose version (con espacio, no con guion). Si todavía usa docker-compose v1, migre primero a Compose v2: las imágenes oficiales de Mattermost v11 dan por supuesto ese formato.
Acceso root o sudo en el VPS — los comandos que siguen actúan sobre los volúmenes Docker y los archivos de configuración.
Espacio en disco disponible — compruebe con df -h que el volumen que aloja sus volúmenes Docker dispone de al menos 3 GB libres para los dumps y las imágenes temporales.
RAM suficiente — Mattermost v11 funciona correctamente con 2 GB de RAM para menos de 50 usuarios activos. Compruébelo con free -m antes de la actualización.
Versión actual anotada — antes de cualquier operación, anote la versión instalada: docker exec <mattermost-container> mattermost version. Este punto es el paso 1 del procedimiento.
Procedimiento de actualización paso a paso
Anotar la versión actual
Antes de modificar nada, anote la versión en curso:
docker exec mattermost mattermost versionAnote el número (por ejemplo
v10.11.2). Esta referencia le permitirá comparar después de la actualización y demostrar que la migración se ha realizado.Hacer una copia de seguridad de la base PostgreSQL
Es el paso más crítico. Ejecute un
pg_dumpdesde el contenedor PostgreSQL:docker exec <pg-container> pg_dump -U mattermost mattermost > backup_mattermost_$(date +%Y%m%d).sqlSustituya
<pg-container>por el nombre real de su contenedor (visible condocker ps). Compruebe que el archivo.sqlcreado no está vacío (ls -lh backup_mattermost_*.sql). Sin esta copia de seguridad, toda migración de base de datos fallida es irreversible.Hacer una copia de seguridad de los volúmenes Docker
Copie también los volúmenes de Mattermost (configuración, datos, plugins):
tar czf mattermost_volumes_$(date +%Y%m%d).tar.gz /opt/mattermost/config /opt/mattermost/data /opt/mattermost/plugins /opt/mattermost/logsAdapte la ruta a su instalación (
/opt/mattermostes el directorio estándar del repositorio oficialmattermost-docker). Mueva el archivo comprimido fuera del VPS, a un almacenamiento externo, antes de continuar.Anotar los plugins activos
Desde System Console → Plugins → Plugin Management, liste todos los plugins activados con su versión. Anótelos en un archivo de texto: después de la actualización deberá comprobar la compatibilidad de cada uno.
Como alternativa, mediante la API:
curl -s -H "Authorization: Bearer <su-token>" https://chat.sudominio.com/api/v4/plugins | python3 -m json.tool | grep -E '"id"|"version"|"active"'Detener Mattermost y PostgreSQL
Detenga el stack limpiamente antes de descargar las nuevas imágenes:
docker compose downCompruebe que ya no queda ningún contenedor de Mattermost en ejecución:
docker ps | grep mattermost.Descargar las nuevas imágenes
Desde el directorio que contiene su
docker-compose.yml:docker compose pullEste comando descarga las nuevas imágenes de todos los servicios declarados (
mattermostypostgres). Si sudocker-compose.ymlfija una versión explícita (mattermost/mattermost-team-edition:v10.x.x), actualícela av11o alatest(y después fije el digest exacto para la reproducibilidad).Reiniciar el stack
Vuelva a lanzar el conjunto de los servicios:
docker compose up -dMattermost arranca, detecta que la base está en un esquema v10 y lanza las migraciones automáticamente. Este paso puede tardar de 30 segundos a unos minutos según el tamaño de su base.
Verificar las migraciones de base de datos
Siga los logs inmediatamente después del arranque:
docker compose logs mattermost | grep -i migratLas líneas esperadas se parecen a
Running migration X.YoMigrating database from version X. Si vefailed to run migrationsoerror running migration, detenga (docker compose down) y restaure desde el dump antes de ir más lejos.Para seguirlo en directo:
docker compose logs -f mattermost— espere el mensajeServer is listening on.Verificar la nueva versión
Confirme que la actualización es realmente efectiva:
docker exec mattermost mattermost versionLa salida debe mostrar un número
v11.x.x. Conéctese a la interfaz web y navegue a System Console → About → Mattermost Server para contrastar la verificación.Probar las funcionalidades críticas
Antes de dar por válida la actualización, pruebe manualmente los siguientes puntos:
- Conexión de una cuenta de usuario
- Envío y recepción de un mensaje en un canal público
- Envío de un mensaje directo
- Envío de un archivo adjunto
- Verificación del historial de mensajes anteriores a la actualización
- Funcionamiento de los webhooks entrantes si tiene alguno configuradoEl historial completo debe seguir accesible: es el primer punto que hay que comprobar.
Verificar los plugins
En System Console → Plugins → Plugin Management, compare la lista con las notas tomadas en el paso 4. Para cada plugin activado:
1. Compruebe que sigue apareciendo como activo.
2. Si un plugin aparece desactivado con un mensaje de incompatibilidad, consulte la página de su repositorio para encontrar una versión compatible con la v11.
3. Actualícelo desde el gestor de plugins si hay una nueva versión disponible.Los plugins oficiales (Calls, Boards, Playbooks) tienen sus versiones v11 disponibles en el marketplace integrado.
Limpiar las imágenes Docker antiguas
Una vez validada la actualización, libere el espacio ocupado por las imágenes antiguas:
docker image prune -fEste comando elimina todas las imágenes no referenciadas por un contenedor activo. Puede recuperar varios gigabytes si ha conservado varias versiones de imágenes de Mattermost.
Pruebe siempre la actualización fuera de producción primero
Si administra una instancia en producción con muchos usuarios, reproduzca la operación previamente en un entorno de pruebas. Restaure una copia de su dump de PostgreSQL en un VPS de pruebas, ejecute el procedimiento completo y verifique el resultado. Eso le revela las incompatibilidades de plugins y los posibles errores de migración antes de que afecten a sus usuarios.
Compatibilidad de los plugins después de la actualización
La v11 introdujo cambios en la API de plugins. La mayoría de los plugins oficiales y de los plugins activos de la comunidad son compatibles, pero pueden aparecer incompatibilidades en plugins antiguos sin mantenimiento.
Cómo comprobar la compatibilidad: vaya a System Console → Plugins → Plugin Management. Un plugin incompatible se muestra con un estado de error y un mensaje que indica la versión mínima requerida.
Si un plugin es incompatible:
1. Consulte el repositorio GitHub del plugin para comprobar si se ha publicado una versión compatible con la v11.
2. Si es así, descargue el .tar.gz e instálelo desde System Console → Plugins → Upload Plugin.
3. Si no, evalúe si el plugin es crítico. Si lo es, comuníquelo a los mantenedores y conserve mientras tanto una copia de la v10 (su dump).
Los plugins oficiales de Mattermost (Calls, Boards, Playbooks, Jira, GitHub) se actualizan al mismo tiempo que el servidor y están disponibles directamente en el marketplace integrado — basta con comprobar que están en su última versión disponible.
Solución de problemas: errores habituales
failed to run migrations en los logs
La migración de base de datos ha fallado. Causas frecuentes: el contenedor PostgreSQL no estaba arrancado antes que Mattermost (problema de orden de arranque en Compose), o los permisos sobre la base son incorrectos. Detenga con docker compose down, compruebe que postgres arranca antes que mattermost (cláusula depends_on en docker-compose.yml) y vuelva a lanzar. Si el error persiste, restaure el dump y examine los logs completos con docker compose logs mattermost 2>&1 | grep -i error.
Plugin marcado como incompatible inmediatamente después de la actualización
El plugin depende de una API obsoleta. Desactívelo desde la consola (System Console → Plugins → Plugin Management → Desactivar) para que Mattermost siga siendo funcional y actualice después el plugin por separado.
SIGTERM durante la migración (contenedor detenido en plena tarea)
Si el contenedor de Mattermost se reinicia durante la migración (timeout de Docker, SIGTERM), la base puede quedar en un estado intermedio. Señal: mattermost version muestra un número híbrido o los logs muestran errores de columnas ausentes. Restaure desde el dump de PostgreSQL y vuelva a lanzar asegurándose de que MATTERMOST_UPGRADE_TIMEOUT esté configurado con un valor suficiente (como mínimo 600 segundos para las bases grandes).
Problema de conexión después del reinicio
Si la interfaz responde pero los usuarios no pueden conectarse, compruebe que MM_SERVICESETTINGS_SITEURL en docker-compose.yml está en https:// y coincide exactamente con la URL que utiliza. Un cambio de hostname o de protocolo durante la actualización invalida los tokens de sesión existentes.
Error database schema version mismatch
Mattermost detecta una discrepancia entre la versión del binario y el esquema de la base. Este caso se produce si había fijado una imagen v10 y la migración parcial de un intento anterior dejó el esquema en un estado v11 incompleto. Restaure el dump v10 completo y vuelva a lanzar el procedimiento desde el paso 5.
Después de la actualización: buenas prácticas
Una vez validada la v11 en producción, algunos ajustes mantienen la instancia bajo control.
Fije la versión de la imagen en docker-compose.yml — sustituya latest por la etiqueta exacta (mattermost/mattermost-team-edition:v11.x.x). Así evita que un docker compose pull posterior descargue en silencio una versión futura sin que usted lo haya decidido.
Planifique las copias de seguridad de PostgreSQL — un cron que ejecute pg_dump cada 24 horas y conserve los 7 últimos dumps es el mínimo para una instancia de producción.
Vigile el canal de seguridad de Mattermost — suscríbase a https://mattermost.com/security-updates/ para recibir los anuncios de CVE. El próximo fin de vida de la v11 LTS se anunciará con varios meses de antelación.
Para profundizar, encontrará la guía de instalación inicial en el artículo [Alojar Mattermost en su propio VPS](/blog/heberger-mattermost) y los argumentos para dejar Slack en [Migrar de Slack a Mattermost o Rocket.Chat en VPS](/blog/migration-slack-mattermost-rocketchat-vps).
