Alternativas ao Slack auto-hospedadas: comparação prática

Qual alternativa auto-hospedada ao Slack deve executar

As alternativas auto-hospedadas ao Slack que justificam o tempo de uma equipa pequena são Mattermost, Rocket.Chat, Matrix com Synapse e Zulip. Para uma ferramenta interna de equipa num único servidor, execute Mattermost. Para uma comunidade pública, execute Zulip. Execute Matrix com Synapse quando precisar de comunicar com servidores administrados por terceiros, e apenas nesse caso, porque a federação é a única capacidade que as outras opções não conseguem reproduzir e também é o que altera o seu trabalho como administrador.

As listas de funcionalidades não distinguem estas quatro opções. Todas oferecem canais, threads, pesquisa, carregamento de ficheiros e aplicações móveis. O que as distingue é aquilo que exigem de si todos os meses: memória, uma base de dados que tem de manter em execução, um mecanismo de notificações push móveis que pode não controlar e uma licença que determina se a funcionalidade de que precisa está sujeita a pagamento. A comparação abaixo usa esses critérios, com dez utilizadores e com cem.

O que cada um dos quatro é na prática

Mattermost é um servidor Go com uma base de dados PostgreSQL. Um binário, uma base de dados e um ficheiro de configuração. Funciona como o Slack, incluindo threads e comandos slash, e é o menos interessante dos quatro para operar, o que é um elogio.

Rocket.Chat é uma aplicação Node.js sobre MongoDB. Tem o conjunto de funcionalidades mais amplo desta lista, incluindo chamadas de voz e vídeo e uma caixa de entrada omnicanal que reúne conversas de clientes provenientes de email e canais sociais na mesma interface. Se essa caixa de entrada é o motivo da sua pesquisa, compare-a primeiro com uma central de suporte Chatwoot dedicada, porque um servidor de chat usado para prestar suporte tem uma finalidade diferente de um servidor de chat usado para o trabalho da equipa.

Matrix é um protocolo, não um produto. Synapse é o servidor de referência (Python, PostgreSQL) e Element é o cliente usado pela maioria das pessoas. Esta é a única opção desta lista em que o seu servidor pode comunicar com servidores que não são administrados por si.

Zulip é um servidor Python (Django e Tornado) com PostgreSQL, RabbitMQ, memcached e Redis, instalado como uma unidade pelo seu próprio script. O seu modelo organiza tópicos dentro de canais, por isso uma conversa de terça-feira continua fácil de encontrar na sexta-feira. A versão 12.0 foi lançada em abril de 2026.

Quanta RAM e qual base de dados, com 10 e com 100 utilizadores

Todos os números da tabela abaixo vêm da documentação dos próprios projetos, consultada em agosto de 2026. Nenhum é uma medição minha e nenhum foi inventado. A base é a mesma em todas as linhas: a configuração mais pequena publicada por cada projeto, com a base de dados incluída quando o projeto a dimensiona separadamente.

[
  {
    "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."
  }
]

As linhas não têm todas a mesma estrutura, e essa é a primeira conclusão útil. Os 1 GB do Synapse são um mínimo para o processo do Synapse, com uma condição: a documentação recomenda pelo menos essa quantidade de RAM livre se quiser entrar em salas públicas grandes. O PostgreSQL fica fora desse valor. Os 2 GB do Mattermost correspondem à máquina inteira, com a base de dados incluída, e abrangem de 1 a 1.000 utilizadores numa única vCPU. O Zulip documenta 2 GB e uma CPU para menos de 100 utilizadores, além de 2 GB de swap; a partir de 100 utilizadores, recomenda 4 GB e duas CPUs. O Rocket.Chat publica o maior valor, 8 GB, porque dimensiona a aplicação com 4 GiB e o MongoDB com 4 GiB. Esse nível suporta até 500 utilizadores concorrentes.

Com dez utilizadores, todos os 4 funcionam em hardware ao qual não daria muita importância. Com cem, as necessidades divergem: o Mattermost continua dentro do nível de 2 GB, o Zulip precisa de 4 GB e de uma segunda CPU, e o nível documentado mais pequeno do Rocket.Chat mantém-se nos 8 GB, porque o consumo de memória do MongoDB depende da máquina e não da quantidade de utilizadores.

A escolha da base de dados condiciona mais as atualizações futuras do que o desempenho diário. O Mattermost precisa de PostgreSQL 14 ou mais recente e deixou de suportar MySQL a partir da v11, por isso uma instalação MySQL feita hoje transforma-se numa migração amanhã. O Synapse funciona com SQLite, mas a própria documentação afirma claramente que SQLite só é aceitável para testes, porque tem um desempenho fraco em salas grandes. O Rocket.Chat 8 requer MongoDB 8.0, o que significa que a atualização da base de dados e a atualização do chat fazem parte do mesmo projeto, e não de dois projetos separados.

O que um VPS com 2 GB oferece na prática

O plano de 2 GB é o tamanho de entrada na maioria dos provedores e é uma opção real para dois destes quatro serviços.

• Mattermost cabe. É o único cuja documentação do fornecedor menciona exatamente esse tamanho, para até 1,000 utilizadores, com PostgreSQL no mesmo servidor. Dez pessoas em 2 GB trabalham com folga.
• Zulip cabe, com swap. A documentação recomenda swap em qualquer máquina com menos de 5 GB e avisa que máquinas com pouca RAM apresentam erros de falta de memória durante as atualizações, quando tools/webpack é a etapa que falha. Essa é uma falha real que encontrará no momento da atualização, não na instalação.
• Synapse cabe enquanto está pouco ativo. O consumo em repouso é baixo. O problema é o pico, e a secção sobre federação abaixo explica a sua origem.
• Rocket.Chat é o serviço a evitar com 2 GB, e a causa é o mecanismo de armazenamento do MongoDB. O WiredTiger dimensiona a sua cache interna para o maior valor entre 50% de (RAM menos 1 GB) e 256 MB. Assim, numa máquina com 2 GB, reserva aproximadamente 512 MB antes de o Node.js arrancar. O resultado não é uma recusa imediata. O serviço instala, arranca, fica mais lento à medida que o histórico cresce e, por fim, o kernel out of memory killer termina o processo que for maior naquele momento.

Verifique o que realmente tem antes de decidir, porque os provedores contabilizam a RAM de forma diferente de free:

free -h
swapon --show

Lembre-se de que o servidor de chat não é o único serviço no servidor. A terminação TLS (transport layer security), as cópias de segurança e um runtime de contentores também precisam de memória. Coloque o servidor escolhido atrás de um reverse proxy que conheça, Nginx, Caddy ou Traefik e, se implementar com contentores, os fundamentos do Docker Compose para um VPS são a parte que deve configurar corretamente primeiro.

Os aplicativos móveis precisam do seu próprio servidor de push

Este é o fator que muitas pessoas descobrem depois da implementação e que, com mais frequência, determina a resposta.

O mecanismo é o seguinte. O Apple Push Notification service (APNs) e o Firebase Cloud Messaging (FCM) aceitam uma notificação apenas de quem possui as credenciais de assinatura da aplicação específica. O seu servidor não pode enviar notificações para uma aplicação que não foi desenvolvida por si. Por isso, um servidor de chat autoalojado que utilize a versão da aplicação fornecida na App Store tem de enviar as notificações para o gateway do fornecedor, que define as condições.

• Mattermost. A opção gratuita é o Test Push Notification Service (TPNS) em https://push-test.mattermost.com. A documentação indica que não é recomendado para produção e que não inclui um acordo de nível de serviço (SLA). Funciona apenas com as versões da App Store e da Play Store. O Hosted Push Notification Service (HPNS) é adequado para produção e requer uma subscrição paga. A terceira opção é compilar o proxy de push por conta própria. Nesse caso, também precisa das suas próprias versões da aplicação, com as suas próprias credenciais APNs e FCM.
• Rocket.Chat. O push requer o registo do workspace no Rocket.Chat Cloud. Os workspaces da comunidade têm um limite de 10,000 notificações push por mês. Isso corresponde a cerca de 330 por dia para todo o workspace. Quando a quota é consumida, as notificações deixam de chegar até ao início do mês seguinte. Para os utilizadores, isto parece que a aplicação deixou de funcionar.
• Matrix com Element. O Synapse envia notificações para um gateway de push, e as aplicações oficiais do Element estão configuradas para utilizar o gateway operado por matrix.org em https://matrix.org/_matrix/push/v1/notify. A carga útil contém os identificadores do evento e da sala, e não o texto da mensagem. A aplicação obtém o conteúdo a partir do seu servidor. Assim, o gateway vê metadados, não as conversas. É suportado executar o seu próprio gateway Sygnal, mas isso implica criar e distribuir as suas próprias aplicações. No Android, existe uma opção intermédia: UnifiedPush com um servidor ntfy alojado por si.
• Zulip. O plano gratuito inclui o serviço de push móvel para até 10 utilizadores. Acima de 10 utilizadores, precisa de um plano. O plano gratuito Community abrange muitas organizações sem fins lucrativos. O Zulip 12.0, em abril de 2026, adicionou encriptação ponta a ponta para as cargas úteis de push.

Com dez utilizadores, todas estas opções fornecem notificações funcionais sem custos. Com cem utilizadores, o cenário muda: o Zulip requer um plano; o Mattermost continua a funcionar no serviço de teste, mas sem SLA nem suporte; o limite mensal do Rocket.Chat torna-se a restrição; e o Matrix não é afetado, porque o gateway pode ser utilizado gratuitamente.

Quais oferecem single sign-on sem custo

O modelo de negócio de núcleo aberto fica mais evidente no single sign-on (SSO).

• Zulip inclui SAML (security assertion markup language) e LDAP (lightweight directory access protocol) no servidor self-hosted, sem custo. Não é necessário adquirir um nível separado.
• Synapse suporta OpenID Connect (OIDC), SAML e CAS no próprio ficheiro de configuração, sem custo. As implementações mais recentes usam cada vez mais o Matrix Authentication Service, um serviço separado com uma migração unidirecional da autenticação clássica do Synapse. Planeie essa migração para não ser surpreendido posteriormente.
• A edição comunitária do Rocket.Chat oferece login básico com LDAP e SAML. A sincronização de atributos de utilizador adicionais, o mapeamento de grupos e equipas e a sincronização em segundo plano exigem uma licença empresarial.
• A Team Edition gratuita do Mattermost oferece GitLab OAuth e nada mais. SAML, AD/LDAP e OpenID Connect são funcionalidades pagas.

Se planeia executar vários serviços atrás de um único login, coloque um fornecedor de identidade Authentik self-hosted à frente deles e confirme quais dos quatro conseguem comunicar com ele com a licença que possui.

O custo real da federação

A federação é a razão de existir do Matrix. O seu utilizador entra numa sala alojada no servidor de outra pessoa e fala com pessoas cujas contas estão nesse servidor, tal como os servidores de email trocam mensagens. Nenhuma das outras opções aqui apresentadas faz isto. Se precisa desta funcionalidade, nada mais nesta página a substitui.

É também por isso que o Synapse representa um tipo de carga de trabalho diferente. Quando o seu utilizador entra numa sala federada, o seu servidor mantém uma cópia do estado e dos eventos dessa sala. Também coloca em cache os conteúdos multimédia publicados por utilizadores de outros servidores: avatares, imagens e ficheiros. O uso do disco passa a ser determinado por salas que não criou e por pessoas que não têm contas no seu servidor. É por isso que as instalações do Synapse acumulam um media store muito maior do que o volume de mensagens enviadas pelos próprios utilizadores. É também por isso que a entrada numa sala pública grande é a operação à qual a documentação associa uma condição de memória.

Defina a política de retenção no primeiro dia, e não no dia em que o disco ficar cheio:

media_retention:
  local_media_lifetime: 90d
  remote_media_lifetime: 14d

O Synapse passou a incluir media_retention na versão 1.61, com tempos de vida separados para conteúdos multimédia locais e remotos. Os conteúdos multimédia remotos são uma cache. Se um utilizador pedir novamente um ficheiro eliminado, o Synapse volta a pedi-lo ao servidor de origem. Os conteúdos multimédia locais não são uma cache. Por isso, um local_media_lifetime curto elimina permanentemente os uploads dos seus próprios utilizadores.

O resumo honesto é este: se os seus utilizadores comunicarem apenas entre si, a federação não lhes traz qualquer benefício e aumenta o consumo de disco, a largura de banda e a complexidade das atualizações. Desative-a ou escolha outro servidor.

Como são feitas as atualizações

Zulip é a opção mais simples. Um script basta, e o tempo de indisponibilidade documentado é inferior a 30 segundos, exceto quando é necessária uma migração de base de dados grande. A instalação e a atualização são feitas assim, por si no servidor:

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

Execute o instalador como root. A opção --push-notifications regista o servidor no serviço de notificações push para dispositivos móveis durante a instalação. Nesse momento, o instalador pede que aceite os termos de serviço. Leia-os antes de começar.

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

As atualizações posteriores usam o mesmo tarball e mais um 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 é previsível. Substitua o binário, reinicie o serviço e as migrações serão executadas no arranque. Desde os releases de agosto de 2025, o canal Extended Support Release (ESR) é disponibilizado a cada 9 meses e tem 12 meses de suporte. As atualizações entre versões ESR são o percurso testado. É possível saltar várias versões ESR de uma vez, mas esse percurso não é testado. Na prática, isso significa que será você a testá-lo.

Rocket.Chat combina três atualizações. Em agosto de 2026, a linha 8.x é a atual. A versão 8.7.0 foi disponibilizada em 6 de agosto de 2026 e requer MongoDB 8.0 e uma versão compatível de Node.js. Saltar uma versão principal pode deixar a base de dados num estado que a aplicação se recusa a abrir. O guia de instalação do Rocket.Chat com Docker Compose fixa estas versões em conjunto, que é o principal argumento a favor da utilização de contentores neste caso.

Synapse exige leitura. Cada release tem notas de atualização. Deve ler as notas de cada versão pela qual passar, e não apenas as da versão final. Depois da atualização, o Synapse executa atualizações em segundo plano na base de dados. Num servidor pequeno, estas operações podem manter a máquina lenta durante horas. Esse comportamento é esperado, não é uma falha.

Termos das licenças, em linguagem simples

O Mattermost distribui as suas compilações Team Edition sob a licença MIT, enquanto o código-fonte é disponibilizado sob a AGPLv3 ou uma licença comercial. Algumas partes do repositório estão sob a Mattermost Source Available License, que exige uma licença paga para executar o software em produção. O Rocket.Chat usa a licença MIT, exceto nos diretórios ee/, que têm a sua própria licença empresarial. O Synapse passou da Apache 2.0 para a AGPLv3 na versão 1.99.0, e os contribuidores assinam um CLA que permite à Element vender exceções a essa licença. O Zulip usa a Apache 2.0 e não tem um diretório empresarial. Por isso, a sua oferta de SSO não tem ressalvas.

A leitura prática é esta: a AGPL só é relevante se planeia modificar o servidor e disponibilizá-lo a terceiros como um serviço. Para uma equipa pequena, é muito mais importante saber quais funcionalidades faltam na versão gratuita do modelo open core. O Zulip tem menos funcionalidades em falta. O Mattermost tem mais.

Qual escolher

Uma ferramenta interna para a equipa. Mattermost. Tem a menor pegada documentada, as atualizações mais previsíveis e uma interface familiar que não precisa de explicações. Planeie um plano pago quando o SSO se tornar um requisito, porque isso acontece com a maioria das equipas.

Um servidor comunitário. Zulip. Os tópicos mantêm um canal público movimentado legível meses depois, SAML e LDAP não têm custos adicionais e a atualização é feita com um comando. Se a sua comunidade estiver mais próxima de publicações e respostas do que de chat em tempo real, compare primeiro software de fórum autoalojado, porque um fórum é melhor indexado nas pesquisas e não precisa de infraestrutura push. Escolha Rocket.Chat quando quiser funcionalidades de voz, vídeo e omnicanal e puder disponibilizar os 8 GB indicados na documentação do próprio produto.

Uma rede que tem de interoperar. Matrix com Synapse e Element. Aceite o crescimento do armazenamento de media, defina a retenção desde o primeiro dia, use PostgreSQL e mais espaço em disco do que considera necessário, e tire verdadeiro partido da comunicação com servidores que não controla. Escolher Synapse para uma equipa que nunca usa federação significa suportar esse custo sem obter qualquer benefício.

FAQ

Qual é a melhor alternativa autoalojada ao Slack para uma equipa pequena?

Mattermost, para a maioria das equipas internas. A documentação cobre de 1 a 1.000 utilizadores numa vCPU e com 2 GB de RAM, usando PostgreSQL na mesma máquina, pelo que se adapta ao plano VPS inicial que a maioria dos fornecedores disponibiliza. A limitação é o início de sessão único: a edição gratuita Team Edition suporta apenas GitLab OAuth, enquanto SAML, AD/LDAP e OpenID Connect exigem um plano pago. Se o SSO gratuito for mais importante do que uma interface semelhante à do Slack, use Zulip.

Posso executar um servidor de chat autoalojado numa VPS com 2 GB?

Sim com Mattermost e também com Zulip se adicionar swap, algo que a própria documentação do Zulip recomenda abaixo de 5 GB. Rocket.Chat é a opção que provavelmente irá desiludir, porque o motor WiredTiger do MongoDB reserva para a cache o maior valor entre 50% de (RAM menos 1 GB) e 256 MB. Assim, aproximadamente 512 MB de uma máquina com 2 GB desaparecem antes de a aplicação arrancar. O serviço será instalado, mas irá degradar-se à medida que o histórico crescer e acabará com um encerramento por falta de memória. O nível mínimo publicado pelo Rocket.Chat é de 4 GiB para a aplicação mais 4 GiB para o MongoDB.

Os servidores de chat autoalojados precisam do seu próprio servidor de notificações push para dispositivos móveis?

Normalmente, não, porque os APNs da Apple e o FCM da Google só aceitam notificações de quem assinou a aplicação. Por isso, a aplicação do fornecedor usa o gateway do fornecedor. As condições variam. Mattermost disponibiliza um serviço de teste gratuito sem SLA e um serviço alojado pago. Rocket.Chat limita os workspaces comunitários a 10.000 notificações push por mês. Depois desse limite, a entrega para até o mês ser reiniciado. Zulip inclui push gratuito para até 10 utilizadores e exige um plano superior acima desse limite. Os homeservers Matrix enviam notificações através do gateway usado pelas aplicações Element, sem custos. Só precisa do seu próprio gateway se também distribuir as suas próprias builds da aplicação.

Devo autoalojar Matrix e Synapse para uma equipa que nunca comunica com outros servidores?

Não. A federação é a finalidade do Synapse e também é o que o torna mais pesado de executar. Entrar em salas noutros servidores transfere o respetivo estado e coloca os seus conteúdos multimédia em cache no disco. Por isso, o armazenamento cresce por razões não relacionadas com os seus próprios utilizadores. Configure media_retention com um remote_media_lifetime curto antes que isso aconteça. Uma equipa que comunica apenas internamente suporta o custo operacional sem obter qualquer benefício. Mattermost ou Zulip executam a mesma função com menos hardware.

Qual é a alternativa autoalojada ao Slack que tem início de sessão único gratuito?

Zulip e Synapse. Zulip inclui SAML e LDAP no servidor autoalojado sem custos. Synapse suporta OpenID Connect, SAML e CAS na configuração. Nas instalações mais recentes, esta função está a passar para o serviço separado Matrix Authentication Service. A edição comunitária do Rocket.Chat permite autenticação básica por LDAP e SAML, mas reserva a sincronização de atributos, o mapeamento de grupos e a sincronização em segundo plano para uma licença empresarial. A edição gratuita Team Edition do Mattermost suporta apenas GitLab OAuth.