Alternativas autoalojadas a Slack: Mattermost y más

Qué alternativa autoalojada a Slack deberías ejecutar

Las alternativas autoalojadas a Slack que merecen el tiempo de un equipo pequeño son Mattermost, Rocket.Chat, Matrix con Synapse y Zulip. Para una herramienta interna de equipo en un solo servidor, ejecuta Mattermost. Para una comunidad pública, ejecuta Zulip. Ejecuta Matrix con Synapse cuando tengas que comunicarte con servidores de terceros, y sólo en ese caso, porque la federación es lo único que las demás no pueden copiar y también lo que cambia tu trabajo como administrador.

Las listas de funciones no permiten distinguir estas cuatro opciones. Todas ofrecen canales, hilos, búsquedas, carga de archivos y aplicaciones móviles. La diferencia está en lo que te exigen cada mes: memoria, una base de datos que debes mantener activa, una ruta de notificaciones push móviles que quizá no controles y una licencia que determina si la función que necesitas requiere un pago. La comparación siguiente usa esos criterios, con diez usuarios y con cien.

Qué es realmente cada una de las cuatro

Mattermost es un servidor escrito en Go con una base de datos PostgreSQL. Un binario, una base de datos y un archivo de configuración. Funciona como Slack, con hilos y comandos slash incluidos, y es la menos interesante de las cuatro en cuanto a operación, lo cual es una cualidad.

Rocket.Chat es una aplicación Node.js sobre MongoDB. Ofrece el conjunto de funciones más amplio de esta lista, incluidas las llamadas de voz y vídeo y una bandeja de entrada omnicanal que reúne las conversaciones de clientes procedentes del correo electrónico y de los canales sociales en la misma interfaz. Si esa bandeja es el motivo de su búsqueda, compárela primero con una mesa de soporte dedicada de Chatwoot, porque un servidor de chat destinado a soporte cumple una función distinta de un servidor de chat destinado al trabajo en equipo.

Matrix es un protocolo, no un producto. Synapse es el servidor de referencia (Python, PostgreSQL) y Element es el cliente que usa la mayoría. Es la única opción de esta lista en la que su servidor puede comunicarse con servidores que usted no administra.

Zulip es un servidor Python (Django y Tornado) con PostgreSQL, RabbitMQ, memcached y Redis, instalado como una unidad mediante su propio script. Su modelo utiliza temas dentro de canales, por lo que una conversación del martes sigue siendo fácil de encontrar el viernes. La versión 12.0 se publicó en abril de 2026.

Cuánta RAM y qué base de datos se necesitan con 10 y 100 usuarios

Todos los números de la tabla siguiente proceden de la documentación de los propios proyectos, consultada en agosto de 2026. Ninguno es una medición mía ni un dato inventado. La base es la misma para todas las filas: la configuración más pequeña que publica cada proyecto, con la base de datos incluida cuando el proyecto la dimensiona por separado.

[
  {
    "label": "Synapse",
    "published_ram_gb": 1,
    "notes": "Synapse install docs: at least 1 GB free RAM if you want to join large public rooms. PostgreSQL is required for production and is not sized."
  },
  {
    "label": "Mattermost",
    "published_ram_gb": 2,
    "notes": "Mattermost requirements: 1 to 1,000 users on 1 vCPU and 2 GB RAM, single server, database included."
  },
  {
    "label": "Zulip",
    "published_ram_gb": 2,
    "notes": "Zulip requirements: under 100 users on 1 CPU, 2 GB RAM and 2 GB swap. 100 users and above needs 2 CPUs and 4 GB."
  },
  {
    "label": "Rocket.Chat",
    "published_ram_gb": 8,
    "notes": "Rocket.Chat requirements: smallest published tier is 4 GiB for the app plus 4 GiB for MongoDB, rated up to 500 concurrent users."
  }
]

Las filas no tienen el mismo alcance, y ese es el primer dato útil. Los 1 GB de Synapse son el mínimo para el proceso de Synapse, con una condición: la documentación pide al menos esa cantidad de RAM libre si quiere unirse a salas públicas grandes. PostgreSQL queda fuera de esa cifra. Los 2 GB de Mattermost corresponden a toda la máquina, con la base de datos incluida, y cubren de 1 a 1,000 usuarios en una sola vCPU. Zulip documenta 2 GB y una CPU para menos de 100 usuarios, además de 2 GB de swap; a partir de 100 usuarios, indica 4 GB y 2 CPU. Rocket.Chat publica aquí la cifra más alta, 8 GB, porque dimensiona la aplicación con 4 GiB y MongoDB con 4 GiB, y ese nivel admite hasta 500 usuarios simultáneos.

Con 10 usuarios, los 4 funcionan en hardware al que no tendría que prestar mucha atención. Con 100 usuarios, las respuestas se separan: Mattermost todavía está dentro de su nivel de 2 GB, Zulip necesita 4 GB y una segunda CPU, y el nivel documentado más pequeño de Rocket.Chat sigue siendo de 8 GB, porque el consumo de memoria de MongoDB depende de la máquina y no del número de usuarios.

La elección de la base de datos condiciona más las ampliaciones futuras que el rendimiento diario. Mattermost necesita PostgreSQL 14 o posterior y ha dejado de admitir MySQL a partir de v11, por lo que una instalación de MySQL hoy implica una migración mañana. Synapse funciona con SQLite, pero su propia documentación indica claramente que SQLite sólo es adecuado para pruebas, porque rinde mal en salas grandes. Rocket.Chat 8 requiere MongoDB 8.0, lo que convierte la actualización de la base de datos y la actualización del chat en un único proyecto en lugar de dos.

Qué ofrece realmente un VPS de 2 GB

El plan de 2 GB es el tamaño inicial de la mayoría de los proveedores y es una opción real para dos de estos cuatro servicios.

• Mattermost funciona. Es el único cuya documentación del proveedor indica exactamente ese tamaño, para hasta 1,000 usuarios, con PostgreSQL en el mismo servidor. Diez personas con 2 GB funcionan con margen.
• Zulip funciona, con swap. La documentación recomienda usar swap en cualquier máquina con menos de 5 GB y advierte que las máquinas con poca RAM sufren errores de falta de memoria durante las actualizaciones, cuando tools/webpack es el paso que falla. Es un fallo real que aparecerá durante una actualización, no durante la instalación.
• Synapse funciona mientras la carga sea baja. El consumo en reposo es reducido. El problema es el aumento puntual de consumo, y la sección sobre federación explica de dónde procede.
• Rocket.Chat es el que debe evitarse con 2 GB, y la causa es el motor de almacenamiento de MongoDB. WiredTiger dimensiona su caché interna con el mayor valor entre el 50% de (RAM menos 1 GB) y 256 MB, por lo que en una máquina de 2 GB reserva aproximadamente 512 MB antes de que Node.js se haya iniciado. El resultado no es un rechazo inmediato. Se instala, funciona, se vuelve más lento a medida que crece el historial y, finalmente, el kernel termina mediante el OOM killer el proceso que sea más grande en ese momento.

Compruebe qué recursos tiene realmente antes de decidir, porque los proveedores contabilizan la RAM de forma distinta a free:

free -h
swapon --show

Recuerde que el servidor de chat no es el único componente de la máquina. La terminación TLS (seguridad de la capa de transporte), las copias de seguridad y un runtime de contenedores también necesitan memoria. Coloque el servidor que elija detrás de un reverse proxy que conozca, Nginx, Caddy o Traefik, y si realiza el despliegue con contenedores, los conceptos básicos de Docker Compose para un VPS son lo primero que conviene configurar correctamente.

¿Las aplicaciones móviles necesitan su propio servidor de notificaciones push?

Este es el aspecto que muchas personas descubren después de desplegar el servicio y el que más suele determinar la respuesta.

Este es el mecanismo. Apple Push Notification service (APNs) y Firebase Cloud Messaging (FCM) sólo aceptan una notificación del titular de las credenciales de firma de esa aplicación concreta. Su servidor no puede enviar notificaciones push a una aplicación que no haya creado. Por tanto, un servidor de chat autohospedado que use la compilación del proveedor distribuida en App Store debe entregar sus notificaciones a la pasarela del proveedor, y el proveedor establece las condiciones.

• Mattermost. La opción gratuita es Test Push Notification Service (TPNS) en https://push-test.mattermost.com, que la documentación no recomienda para producción y que no ofrece ningún acuerdo de nivel de servicio (SLA). Sólo funciona con las compilaciones de App Store y Play Store. Hosted Push Notification Service (HPNS) está preparado para producción y requiere una suscripción de pago. La tercera opción es compilar usted mismo el proxy de notificaciones push, lo que requiere crear sus propias aplicaciones con sus propias credenciales de APNs y FCM.
• Rocket.Chat. Las notificaciones push requieren registrar el workspace en Rocket.Chat Cloud, y los workspaces de la comunidad tienen un límite de 10,000 notificaciones push al mes. Eso equivale a unas 330 al día para todo el workspace. Cuando se agota la cuota, las notificaciones dejan de llegar hasta que se reinicia el mes, por lo que los usuarios perciben que la aplicación ha dejado de funcionar.
• Matrix con Element. Synapse envía las notificaciones a una pasarela push, y las aplicaciones oficiales de Element apuntan a la pasarela que ejecuta matrix.org en https://matrix.org/_matrix/push/v1/notify. La carga útil contiene los identificadores del evento y de la sala, no el texto del mensaje, y la aplicación obtiene el contenido de su servidor. Por tanto, la pasarela ve metadatos, no las conversaciones. Se admite ejecutar su propia pasarela Sygnal, pero eso implica crear y distribuir sus propias aplicaciones. En Android existe una opción intermedia: UnifiedPush con un servidor ntfy alojado por usted.
• Zulip. El plan gratuito incluye el servicio de notificaciones push móviles para un máximo de 10 usuarios. Por encima de 10 usuarios necesita un plan, y el plan gratuito Community cubre muchas organizaciones sin fines comerciales. Zulip 12.0, en abril de 2026, añadió cifrado de extremo a extremo para las cargas útiles de las notificaciones push.

Con diez usuarios, todas estas opciones ofrecen notificaciones funcionales sin coste. Con cien usuarios, la situación cambia: Zulip requiere un plan, Mattermost sigue funcionando con el servicio de prueba, pero sin SLA ni soporte, el límite mensual de Rocket.Chat se convierte en la restricción y Matrix no se ve afectado porque la pasarela se puede usar gratuitamente.

Qué opciones ofrecen inicio de sesión único sin coste

El modelo de negocio de núcleo abierto se muestra con mayor claridad en el inicio de sesión único (SSO).

• Zulip incluye SAML (security assertion markup language) y LDAP (lightweight directory access protocol) en el servidor autohospedado sin coste. No es necesario adquirir un nivel independiente.
• Synapse admite OpenID Connect (OIDC), SAML y CAS en su propio archivo de configuración, sin coste. Las implementaciones nuevas usan cada vez más Matrix Authentication Service, un servicio independiente con una migración unidireccional desde la autenticación clásica de Synapse. Planifique ese cambio para no descubrirlo más adelante.
• Rocket.Chat Community Edition ofrece inicio de sesión básico mediante LDAP y SAML. La sincronización de atributos de usuario ampliados, la asignación de grupos y equipos, y la sincronización en segundo plano requieren una licencia Enterprise.
• Mattermost Team Edition gratuita sólo ofrece OAuth de GitLab. SAML, AD/LDAP y OpenID Connect son funciones de pago.

Si tiene previsto ejecutar varios servicios detrás de un único inicio de sesión, coloque un proveedor de identidad Authentik autohospedado delante de ellos y compruebe cuáles de los cuatro pueden comunicarse realmente con él según la licencia que tenga.

El coste real de la federación

La federación es la razón de ser de Matrix. Un usuario se une a una sala alojada en el servidor de otra persona y habla con usuarios cuyas cuentas están allí, igual que los servidores de correo intercambian mensajes. Ninguna otra opción de esta página hace esto. Si lo necesita, ninguna otra opción de esta página es un sustituto.

También es la razón por la que Synapse tiene un tipo de carga de trabajo diferente. Cuando un usuario se une a una sala federada, su servidor conserva una copia del estado y de los eventos de esa sala. También almacena en caché los archivos multimedia que publican usuarios de otros servidores: avatares, imágenes y archivos. Por tanto, el uso de disco depende de salas que usted no creó y de personas que no tienen cuentas en su servidor. Por eso las instalaciones de Synapse pueden hacer crecer el almacén multimedia hasta superar ampliamente el volumen de mensajes enviados por sus propios usuarios. También por eso la documentación asocia una condición de memoria específica a la acción de unirse a una sala pública grande.

Defina la política de retención desde el primer día, no cuando se llene el disco:

media_retention:
  local_media_lifetime: 90d
  remote_media_lifetime: 14d

Synapse incorporó media_retention en la versión 1.61, con tiempos de vida independientes para los archivos multimedia locales y remotos. Los archivos multimedia remotos son una caché. Si un usuario vuelve a solicitar un archivo eliminado, Synapse lo solicita de nuevo al servidor de origen. Los archivos multimedia locales no son una caché. Por tanto, un local_media_lifetime corto elimina permanentemente los archivos subidos por sus propios usuarios.

El resumen es claro: si sus usuarios sólo hablan entre ellos, la federación no le aporta nada y consume disco, ancho de banda y una ruta de actualización más compleja. Desactívela o elija otro servidor.

Cómo se realizan las actualizaciones

Zulip es la opción más sencilla. Un script y el tiempo de inactividad documentado es inferior a 30 segundos, salvo que haya una migración de base de datos grande. La instalación y la actualización se realizan así, ejecutando los comandos en el servidor:

cd $(mktemp -d)
curl -fLO https://download.zulip.com/server/zulip-server-latest.tar.gz
tar -xf zulip-server-latest.tar.gz

Ejecute el instalador como root. La opción --push-notifications registra el servidor en el servicio de notificaciones push para móviles durante la instalación y le solicita aceptar los términos del servicio en ese momento. Léalos antes de comenzar.

sudo ./zulip-server-*/scripts/setup/install --push-notifications --certbot \
    --email=YOUR_EMAIL --hostname=YOUR_HOSTNAME

Las actualizaciones posteriores usan el mismo tarball y un único comando:

curl -fLO https://download.zulip.com/server/zulip-server-latest.tar.gz
sudo /home/zulip/deployments/current/scripts/upgrade-zulip zulip-server-latest.tar.gz

Mattermost es predecible. Sustituya el binario, reinicie el servicio y las migraciones se ejecutarán durante el arranque. Desde las versiones publicadas en August 2025, la rama Extended Support Release (ESR) se publica cada 9 meses y tiene 12 meses de soporte. La ruta probada consiste en actualizar de una versión ESR a la siguiente. Se admite omitir varias versiones ESR, pero no está probado. En la práctica, eso significa que usted debe probarlo.

Rocket.Chat combina tres actualizaciones. En August 2026, la rama 8.x es la actual. La versión 8.7.0 se publicó el 6 August 2026 y requiere MongoDB 8.0 y una versión compatible de Node.js. Omitir una versión principal puede dejar una base de datos que la aplicación se niega a abrir. La guía de instalación de Rocket.Chat con Docker Compose fija estas versiones conjuntamente, que es el principal argumento para usar contenedores en este caso.

Synapse requiere leer la documentación. Cada versión incluye notas de actualización. Debe leer las notas de cada versión por la que pase, no sólo las de la versión de destino. Después de la actualización, Synapse ejecuta actualizaciones en segundo plano sobre la base de datos. En un servidor pequeño, estas tareas pueden mantener el equipo lento durante horas. Es un comportamiento esperado, no un fallo.

Condiciones de licencia, en términos sencillos

Mattermost distribuye sus compilaciones de Team Edition bajo la licencia MIT, mientras que el código fuente se ofrece bajo AGPLv3 o una licencia comercial. Algunas partes del repositorio usan Mattermost Source Available License, que exige una licencia de pago para ejecutar el software en producción. Rocket.Chat usa MIT, excepto los directorios ee/, que tienen su propia licencia empresarial. Synapse cambió de Apache 2.0 a AGPLv3 en la versión 1.99.0. Además, los colaboradores firman un CLA que permite a Element vender excepciones a esa licencia. Zulip usa Apache 2.0 y no tiene ningún directorio empresarial. Por eso, su compatibilidad con SSO no tiene excepciones.

En la práctica, AGPL sólo le afecta si planea modificar el servidor y ofrecerlo a otras personas como servicio. Para un equipo pequeño, es mucho más importante el modelo de núcleo abierto: qué funciones faltan en la compilación gratuita. Zulip es el que tiene menos limitaciones y Mattermost, el que tiene más.

Cuál debería elegir

Una herramienta para equipos internos. Mattermost. Tiene la menor huella documentada, las actualizaciones más previsibles y una interfaz conocida que no necesita explicaciones. Planifique contratar un plan de pago cuando SSO se convierta en un requisito, porque ese momento llega para la mayoría de los equipos.

Un servidor comunitario. Zulip. Los temas mantienen legible un canal público activo incluso meses después, SAML y LDAP no tienen coste y la actualización requiere un solo comando. Si su comunidad se parece más a publicaciones y respuestas que a un chat en tiempo real, compare primero el software de foros autoalojado, porque un foro se indexa mejor en las búsquedas y no necesita infraestructura de notificaciones push. Elija Rocket.Chat si necesita funciones de voz, vídeo y comunicación omnicanal, y puede asignarle los 8 GB que exige su propia documentación.

Una red que debe interoperar. Matrix con Synapse y Element. Acepte el crecimiento del contenido multimedia, configure la retención desde el primer día, asígnele PostgreSQL y más espacio en disco del que cree necesario, y aproveche la posibilidad de comunicarse con servidores que no controla. Elegir Synapse para un equipo que nunca federa es asumir ese coste sin obtener ningún beneficio.

FAQ

¿Cuál es la mejor alternativa autoalojada a Slack para un equipo pequeño?

Mattermost, para la mayoría de los equipos internos. Su documentación contempla de 1 a 1,000 usuarios en 1 vCPU y 2 GB de RAM con PostgreSQL en el mismo equipo, por lo que encaja en el plan VPS básico que ofrecen la mayoría de los proveedores. La limitación es el inicio de sesión único: la edición gratuita Team Edition sólo admite GitLab OAuth, mientras que SAML, AD/LDAP y OpenID Connect requieren un plan de pago. Si el SSO gratuito es más importante que una interfaz similar a Slack, use Zulip.

¿Puedo ejecutar un servidor de chat autoalojado en un VPS de 2 GB?

Mattermost sí, y Zulip también si añade swap, que la propia documentación de Zulip recomienda por debajo de 5 GB. Rocket.Chat es el que puede decepcionarle, porque el motor WiredTiger de MongoDB reclama para su caché el mayor valor entre el 50% de (RAM menos 1 GB) y 256 MB. Por tanto, aproximadamente 512 MB de un equipo de 2 GB desaparecen antes de que se inicie la aplicación. Se instalará y después se degradará a medida que crezca el historial, hasta terminar con una terminación por falta de memoria. El nivel mínimo publicado por Rocket.Chat es de 4 GiB para la aplicación y 4 GiB para MongoDB.

¿Los servidores de chat autoalojados necesitan su propio servidor de notificaciones push para móviles?

Normalmente no, porque APNs de Apple y FCM de Google sólo aceptan notificaciones del firmante de la aplicación. Por eso, la aplicación del proveedor usa la pasarela del proveedor. Las condiciones varían. Mattermost ofrece un servicio de prueba gratuito sin SLA y un servicio alojado de pago. Rocket.Chat limita los espacios de trabajo de la edición Community a 10,000 notificaciones push al mes. Después, la entrega se detiene hasta que se reinicia el mes. Zulip incluye push gratuito para un máximo de 10 usuarios y exige un plan superior a partir de esa cantidad. Los homeservers de Matrix envían las notificaciones mediante la pasarela que usan las aplicaciones Element, sin coste. Sólo necesita su propia pasarela si también distribuye sus propias compilaciones de la aplicación.

¿Debería autoalojar Matrix y Synapse para un equipo que nunca se comunica con otros servidores?

No. Synapse está diseñado para la federación, que también hace que sea más pesado de ejecutar. Unirse a salas de otros servidores descarga su estado y almacena en caché sus archivos multimedia en el disco. Por eso, el almacenamiento crece por motivos ajenos a sus propios usuarios. Configure media_retention con un remote_media_lifetime breve antes de que ocurra. Un equipo que sólo se comunica consigo mismo asume el coste operativo sin obtener ninguna ventaja, y Mattermost o Zulip realizan el mismo trabajo con menos hardware.

¿Qué alternativa autoalojada a Slack ofrece inicio de sesión único gratuito?

Zulip y Synapse. Zulip incluye SAML y LDAP en el servidor autoalojado sin coste, y Synapse admite OpenID Connect, SAML y CAS en su configuración. En las instalaciones más recientes, esta función se traslada al servicio independiente Matrix Authentication Service. La edición Community de Rocket.Chat permite el inicio de sesión básico mediante LDAP y SAML, pero reserva la sincronización de atributos, la asignación de grupos y la sincronización en segundo plano para una licencia empresarial. La edición gratuita Team Edition de Mattermost sólo admite GitLab OAuth.