Mattermost self-hosted no Brasil: escolha a VPS

Resposta direta

Para rodar Mattermost self-hosted no Brasil com boa experiência, a escolha mais segura costuma começar em uma VPS com 2 vCPUs, 4 GB de RAM, 80 GB de SSD ou NVMe e datacenter próximo dos usuários. Esse perfil atende times pequenos, com poucos canais ativos e anexos moderados. Para produção com 50 a 150 usuários, especialmente com uso intenso de WebSocket, PostgreSQL local e muitos arquivos enviados, faz mais sentido subir para 4 vCPUs, 8 GB de RAM e pelo menos 160 GB de disco rápido. O ponto central não é apenas instalar o Mattermost. É dimensionar aplicação, banco, rede, backup, firewall e crescimento dos arquivos para que o chat continue estável durante picos de mensagens, reuniões internas e integrações com bots.

Resumo rápido

• Mattermost self-hosted funciona bem em VPS, mas precisa de recursos previsíveis para WebSocket, PostgreSQL e armazenamento de anexos.
• Para teste ou laboratório, 2 vCPUs, 2 GB de RAM e 40 GB de disco podem bastar, desde que o uso seja leve.
• Para produção pequena, use como base 2 vCPUs, 4 GB de RAM e 80 GB de SSD ou NVMe.
• Para 50 a 150 usuários, prefira 4 vCPUs, 8 GB de RAM, disco rápido e plano claro de backup.
• Datacenter no Brasil ou próximo do público reduz latência percebida em mensagens, notificações e carregamento de arquivos.
• PostgreSQL precisa de memória, IOPS e rotina de backup testada, não apenas espaço livre.
• Firewall, TLS, SSH seguro, atualizações e snapshots reduzem risco operacional.

O erro comum é tratar Mattermost como se fosse apenas mais uma aplicação web simples. Ele até roda atrás de Nginx como outros serviços, mas o comportamento de chat muda o cálculo. Conexões ficam abertas por WebSocket, mensagens chegam em rajadas, notificações dependem de resposta rápida e uploads crescem mês após mês. Se o servidor também hospeda banco de dados, antivírus, automações e proxy reverso, a folga de RAM desaparece rápido.

Outro ponto prático é a previsibilidade. Uma equipe de 20 pessoas pode parecer pequena, mas se todos usam canais, anexos, integrações e busca com frequência durante o horário comercial, o consumo real fica bem diferente de um ambiente de teste. Por isso, este guia trabalha com perfis de uso e margem operacional, não com uma configuração única que promete servir para qualquer empresa.

Como o Mattermost consome recursos em uma VPS

Mattermost é uma aplicação de colaboração em tempo real. Em uma instalação típica, você terá o serviço Mattermost, um banco PostgreSQL, um proxy reverso como Nginx ou Caddy, certificados TLS, armazenamento local para anexos e rotinas de backup. Em ambientes menores, tudo isso pode ficar na mesma VPS. Em ambientes maiores, banco e arquivos podem ser separados para reduzir disputa por CPU, RAM e I/O de disco.

Aplicação, banco e arquivos no mesmo servidor

A aplicação Mattermost usa CPU para autenticação, renderização de respostas da API, processamento de mensagens, integrações, busca e tarefas internas. O consumo não é constante. Ele sobe quando muitos usuários entram ao mesmo tempo, quando canais grandes recebem mensagens em sequência ou quando integrações publicam eventos em massa. Um bot que envia 300 mensagens por hora em canais diferentes pode gerar mais carga do que dez usuários humanos conversando pouco.

A RAM é usada pelo processo da aplicação, cache, conexões e pelo PostgreSQL. Em uma VPS de 2 GB, o sistema operacional, o proxy reverso e o banco já ocupam uma fatia relevante. Sobra pouco espaço para picos. Quando a memória acaba, o Linux passa a usar swap, e chat em tempo real com swap vira uma experiência ruim. Mensagens demoram, a busca fica lenta e uploads podem falhar.

O disco também entra na conta. PostgreSQL grava dados de mensagens, usuários, canais, sessões e índices. Já os arquivos enviados pelos usuários, como imagens, PDFs, planilhas e gravações, podem crescer muito mais rápido do que o banco. Uma equipe que envia 2 GB de anexos por semana consome mais de 100 GB por ano, sem contar backups. Se você quer entender o lado do banco com mais profundidade, o guia de VPS para banco PostgreSQL ajuda a separar memória, IOPS e rotina de backup de forma mais técnica.

O impacto dos usuários simultâneos

Para Mattermost, usuários cadastrados não significam carga constante. O número que pesa é o de usuários simultâneos, canais ativos e integrações. Um servidor com 200 contas e 20 pessoas online pode ser mais leve do que um servidor com 60 contas e 50 pessoas ativas em horário comercial. O padrão de uso importa bastante.

Um bom primeiro cálculo é dividir o ambiente em três cenários. Laboratório ou uso interno leve, com até 10 usuários simultâneos. Produção pequena, com 10 a 50 simultâneos. Produção média, com 50 a 150 simultâneos, anexos frequentes e integrações com GitLab, Jenkins, Zabbix, Grafana ou sistemas internos. Cada cenário pede uma margem diferente de CPU, RAM, disco e rede.

Dimensionamento de CPU, RAM e disco para Mattermost

O dimensionamento de uma VPS para Mattermost self-hosted no Brasil deve considerar o horário de pico, não a média do mês. Chat corporativo parece leve quando todo mundo está offline, mas fica sensível durante incidentes, deploys, reuniões e atendimento interno. Nesses momentos, canais recebem mensagens rápidas, arquivos são compartilhados e muitas conexões WebSocket ficam abertas ao mesmo tempo.

Configuração mínima realista

Para um laboratório, 2 vCPUs, 2 GB de RAM e 40 GB de SSD podem servir. Esse perfil é adequado para validar SSO, testar plugins, treinar equipe ou manter uma comunidade pequena sem anexos pesados. Não é a melhor base para produção, porque a margem de memória é estreita. Se PostgreSQL, Mattermost e Nginx rodam juntos, qualquer pico pode pressionar o sistema.

Para produção pequena, uma base mais equilibrada é 2 vCPUs, 4 GB de RAM e 80 GB de SSD ou NVMe. Esse perfil atende times de 10 a 40 pessoas, desde que os anexos sejam controlados e o backup esteja bem planejado. Uma configuração prática seria Ubuntu LTS, Mattermost em binário ou Docker Compose, PostgreSQL local com parâmetros conservadores, Nginx com TLS e firewall liberando apenas 22, 80 e 443. Em SSH, a porta 22 pode ficar restrita por IP ou substituída por VPN, dependendo da política da empresa.

Para produção média, use 4 vCPUs, 8 GB de RAM e 160 GB ou mais de disco rápido. Se houver muitos anexos, não pense apenas em aumentar disco local. Avalie object storage compatível com S3, retenção por política interna e backup incremental. Um time de 100 pessoas pode gerar pouco tráfego se usar texto puro, mas pode saturar armazenamento se compartilhar prints, vídeos e relatórios todos os dias.

Quando separar banco, aplicação e arquivos

Separar componentes faz sentido quando o servidor começa a misturar gargalos. Se CPU fica alta por causa da aplicação, PostgreSQL sofre. Se o banco precisa escrever muitos dados, uploads ficam lentos. Se backup compacta arquivos grandes em horário comercial, a aplicação perde resposta. O primeiro passo costuma ser separar arquivos em object storage. O segundo é mover PostgreSQL para uma VPS dedicada ou serviço gerenciado, se a empresa aceitar esse modelo.

Um desenho mais robusto pode usar uma VPS de aplicação com 4 vCPUs e 8 GB de RAM, uma VPS de banco com 4 vCPUs, 8 GB de RAM e disco NVMe, e armazenamento externo para anexos. Esse desenho custa mais e exige monitoramento melhor, mas facilita crescimento. Também reduz risco de um backup de arquivos travar o banco durante o expediente.

WebSocket, latência e rede no Brasil

Mattermost depende de comunicação em tempo real. O usuário espera que mensagens apareçam quase imediatamente, que notificações cheguem sem atraso e que o status online faça sentido. Essa experiência passa por WebSocket, latência, estabilidade de rede, proxy reverso e limites de conexões do sistema operacional. Não basta ter muita CPU se o caminho de rede é ruim ou se o Nginx está configurado de forma inadequada.

Por que chat em tempo real sente latência

Em páginas web comuns, uma diferença de 100 ms pode passar despercebida. Em chat, ela aparece no acúmulo de pequenas esperas. Abrir canal, enviar mensagem, receber confirmação, carregar histórico e baixar anexo são ações repetidas várias vezes por dia. Para equipes no Brasil, hospedar em São Paulo, Fortaleza ou outra região nacional disponível pode reduzir a latência em comparação com servidores nos Estados Unidos ou Europa. Ainda assim, localização precisa ser confirmada no site oficial do provedor antes de qualquer recomendação fechada.

Se a equipe está no Nordeste, um datacenter em Fortaleza pode fazer sentido quando disponível. Se a maior parte está no Sudeste, São Paulo costuma ser uma escolha natural. Para times distribuídos entre Brasil, América Latina e Estados Unidos, Miami pode ser um compromisso aceitável. O ponto é medir. Um teste simples com ping, traceroute e acesso real pelo navegador já revela muito sobre a percepção do usuário.

Como Mattermost mantém conexões abertas, a leitura do guia de VPS para WebSocket e aplicações em tempo real é útil para entender limites de conexão, keepalive, proxy e balanceamento. Esses detalhes são pequenos no papel, mas aparecem rápido quando 80 pessoas deixam o chat aberto durante o dia inteiro.

Nginx, TLS e limites de conexão

Em produção, Nginx ou Caddy normalmente ficam na frente do Mattermost. O proxy precisa repassar corretamente os headers de upgrade do WebSocket. Em Nginx, isso inclui proxy_set_header Upgrade $http_upgrade;, proxy_set_header Connection "upgrade"; e tempos de timeout coerentes com conexões longas. Timeouts muito curtos derrubam sessões. Timeouts exagerados sem controle podem manter conexões mortas por tempo demais.

Também existe o limite de arquivos abertos. Cada conexão usa descritores no sistema operacional. Em uma VPS pequena, limites padrão podem funcionar para 20 usuários, mas falhar com 200 conexões simultâneas entre navegador, app mobile, API e banco. Ajustes em ulimit, systemd e Nginx podem ser necessários. Não é tuning exótico. É higiene operacional para aplicação em tempo real.

TLS também consome CPU, principalmente em handshakes e reconexões. Em servidores modernos isso raramente é o principal gargalo para times pequenos, mas deve entrar na análise quando há muitos clientes móveis alternando rede. Certificados via Let’s Encrypt são uma escolha comum, com renovação automática e checagem periódica. O pior cenário é descobrir no início do expediente que o certificado expirou e ninguém consegue acessar o chat corporativo.

PostgreSQL, armazenamento de arquivos e backup

Mattermost usa PostgreSQL como banco recomendado nas instalações atuais. O banco guarda mensagens, usuários, canais, permissões, sessões, preferências e vários metadados da aplicação. Em paralelo, os anexos podem ficar em disco local ou em armazenamento externo. Esses dois mundos têm perfis diferentes. Banco precisa de baixa latência, consistência e backup transacional. Arquivos precisam de capacidade, retenção e restauração simples.

Banco de dados não é só espaço em disco

Ao escolher a VPS, muita gente olha apenas para gigabytes de disco. Para PostgreSQL, IOPS, latência de escrita e memória disponível importam muito. Um banco pequeno, com 5 GB de dados, pode ficar lento se o disco tem baixa performance sob concorrência. Já um banco de 30 GB pode rodar bem se há cache suficiente e disco rápido. Em Mattermost, consultas de canais grandes, busca e histórico ficam mais pesados conforme o volume de mensagens cresce.

Em uma produção pequena, você pode começar com PostgreSQL local e parâmetros conservadores. Um exemplo prático seria reservar algo entre 25% e 40% da RAM para o banco, mantendo folga para o Mattermost e o sistema. Em uma VPS de 8 GB, shared_buffers em torno de 2 GB pode ser um ponto inicial, mas não deve ser copiado cegamente. Monitore cache hit ratio, tempo de consultas, uso de CPU e I/O antes de ajustar.

Backups precisam ser restauráveis. Parece óbvio, mas muita operação só descobre falhas no dia do incidente. Para PostgreSQL, combine dump lógico periódico para ambientes menores com backup físico ou estratégia de PITR quando o chat é crítico. Teste restauração em uma VPS separada pelo menos uma vez por trimestre. Um arquivo .sql.gz que nunca foi restaurado é apenas uma esperança compactada.

Uploads, anexos e retenção

Arquivos crescem de forma menos previsível que o banco. Um time de engenharia pode enviar logs, prints e pacotes pequenos. Um time de marketing pode compartilhar vídeos, imagens em alta resolução e apresentações. Se a política da empresa permite anexos de 100 MB, dez usuários conseguem consumir 1 GB em poucos minutos. Multiplique isso por meses e a conta muda.

Para disco local, monitore uso com alerta em 70%, 80% e 90%. Em 70%, você planeja. Em 80%, você age. Em 90%, você já está perto de causar indisponibilidade. Bancos de dados não gostam de disco cheio, e Mattermost também não. Se anexos são críticos, object storage compatível com S3 pode ser melhor do que aumentar a VPS indefinidamente. Ele facilita expansão, políticas de retenção e replicação, embora adicione dependência externa e custo variável.

Snapshots ajudam, mas não substituem backup de aplicação e banco. Snapshot de disco pode capturar um estado inconsistente se o banco estiver escrevendo no momento. Use snapshots como camada adicional, não como única proteção. Para Mattermost, uma rotina saudável inclui backup do PostgreSQL, backup dos arquivos, cópia da configuração, documentação de variáveis sensíveis e ensaio de restauração.

Segurança e operação em produção

Um chat corporativo guarda conversas internas, arquivos, decisões, credenciais acidentais e histórico de incidentes. Por isso, a VPS do Mattermost não deve ser tratada como um servidor qualquer. Segurança começa antes da instalação, com escolha de imagem atualizada, acesso SSH controlado, firewall restritivo, chaves fortes e política clara de atualização. Depois continua com logs, backup, monitoramento e resposta a incidentes.

Firewall, SSH e hardening básico

Em uma instalação comum, a VPS precisa expor 80 e 443 para web e, se necessário, SSH para administração. O PostgreSQL não deve ficar aberto para a internet. Se banco e aplicação estão no mesmo servidor, escute em localhost. Se estão separados, use rede privada do provedor, VPN ou regras restritas por IP. Abrir a porta 5432 publicamente é pedir problema.

No SSH, desative login por senha, use chaves, crie usuário administrativo sem login root direto e considere autenticação por VPN ou lista de IPs permitidos. Ferramentas como UFW, nftables ou firewall do provedor ajudam a reduzir superfície de ataque. Para uma base prática, o conteúdo sobre VPS com firewall e hardening de segurança cobre decisões úteis como portas expostas, fail2ban, atualizações automáticas e separação de usuários.

Mattermost também precisa de configuração segura. Use TLS válido, defina domínio fixo, revise permissões de criação de contas, configure SSO quando fizer sentido e limite integrações de terceiros. Webhooks são poderosos, mas podem vazar dados se usados sem critério. Plugins devem ser instalados com parcimônia. Quanto mais extensões, maior a superfície de manutenção.

Atualizações, logs e recuperação

Operação segura depende de rotina. Atualize o sistema operacional com janela definida, acompanhe releases do Mattermost, teste upgrade em ambiente de homologação quando o chat for crítico e mantenha um plano de rollback. Em Docker Compose, versionar o arquivo de configuração ajuda. Em instalação por binário, documente diretórios, usuário de serviço, variáveis e comandos de restart.

Logs devem ser úteis sem virar depósito infinito. Monitore erros do Mattermost, Nginx, PostgreSQL e autenticação do sistema. Configure rotação de logs para evitar disco cheio. Em uma VPS de 80 GB, logs verbosos podem parecer inofensivos no início e virar problema em poucos meses.

Monitoramento básico inclui CPU, RAM, uso de swap, espaço em disco, I/O, latência HTTP, conexões ativas, status do serviço Mattermost e saúde do PostgreSQL. Alertas por e-mail, Telegram, Slack alternativo ou outro canal externo são recomendáveis. Se o Mattermost cair, alertar dentro do próprio Mattermost não resolve.

Comparativo de perfis de VPS para Mattermost

A tabela abaixo resume perfis de dimensionamento para Mattermost self-hosted. Ela não substitui teste de carga nem avaliação do padrão real de uso, mas ajuda a evitar subdimensionamento óbvio. Os valores consideram aplicação, PostgreSQL e arquivos na mesma VPS, exceto quando indicado. Em ambientes regulados, com retenção longa ou anexos grandes, aumente disco e separe componentes mais cedo.

Perfil de uso	Usuários simultâneos estimados	Configuração sugerida	Armazenamento	Observações operacionais
Laboratório ou piloto	1 a 10	2 vCPUs, 2 GB RAM, 40 GB SSD	Disco local	Bom para testes, plugins e validação de SSO, com pouca margem para pico
Produção pequena	10 a 50	2 vCPUs, 4 GB RAM, 80 GB SSD ou NVMe	Disco local com backup externo	Equilibra custo e estabilidade para times pequenos com anexos moderados
Produção média	50 a 150	4 vCPUs, 8 GB RAM, 160 GB SSD ou NVMe	Disco local ou object storage	Requer monitoramento, ajuste de PostgreSQL e política de retenção
Produção crítica	150 ou mais	Aplicação e banco separados, 4 a 8 vCPUs por camada	Object storage e backup dedicado	Indicado quando chat é canal essencial e precisa de restauração testada

Tabela de dimensionamento

O perfil de laboratório é útil para validar o Mattermost sem compromisso de SLA interno. Ele permite testar login, canais, apps mobile, integrações e backup básico. Ainda assim, não é uma boa ideia transformar esse piloto em produção apenas porque funcionou na primeira semana. O uso real muda quando o chat vira ferramenta oficial.

A produção pequena é o ponto de partida mais comum. Com 4 GB de RAM, você consegue manter Mattermost, PostgreSQL e Nginx com alguma folga. O segredo é monitorar desde o primeiro dia. Se o uso de swap aparece com frequência, se o banco começa a responder lentamente ou se o disco passa de 70%, o servidor está pedindo ajuste.

Na produção média, 8 GB de RAM e 4 vCPUs reduzem risco de gargalo em horários de pico. Também abrem espaço para rotinas de backup menos agressivas e cache melhor no PostgreSQL. Nesse estágio, object storage para anexos já deve entrar na conversa, principalmente se a empresa compartilha arquivos grandes.

Notas sobre provedores e dados voláteis

Provedores como DigitalOcean, Vultr, Linode, AWS Lightsail, Hostinger, Locaweb, HostGator e LetsCloud podem aparecer na lista de avaliação, dependendo de orçamento, região, painel, suporte e forma de pagamento. Não publique preço específico sem revisão humana, porque planos, promoções, bandwidth e regiões mudam com frequência. Para LetsCloud, localidade, tipo de disco, disponibilidade de NVMe, snapshots e backups devem ser confirmados por plano e região antes de qualquer afirmação fechada.

Em vez de escolher apenas pelo menor preço, compare quatro pontos: região próxima dos usuários, previsibilidade de CPU, tipo de armazenamento e facilidade de backup. Para Mattermost, um plano barato com disco apertado pode sair caro quando os anexos crescem. Da mesma forma, uma instância poderosa em região distante pode parecer boa no painel, mas entregar uma experiência pior para usuários brasileiros por causa da latência.

Recomendações por perfil

Dev solo e laboratório interno

Se você é desenvolvedor, consultor ou administrador testando Mattermost para uma empresa, comece simples. Uma VPS com 2 vCPUs, 2 GB de RAM e 40 GB de SSD é suficiente para instalar, configurar domínio, testar Nginx, TLS, SMTP, apps mobile e integrações básicas. Use dados fictícios ou uma base pequena. Evite colocar conversas críticas nesse ambiente antes de definir backup, atualização e política de acesso.

Nesse perfil, Docker Compose facilita testes porque concentra Mattermost e PostgreSQL em arquivos reproduzíveis. Mesmo assim, mantenha volumes persistentes fora dos containers e documente variáveis. Faça pelo menos um teste de restauração. Se você não consegue restaurar o piloto em outra VPS, ainda não está pronto para produção.

Time pequeno com uso diário

Para uma equipe de 10 a 40 pessoas, trate Mattermost como serviço interno de produção. A configuração de referência é 2 vCPUs, 4 GB de RAM e 80 GB de SSD ou NVMe, com datacenter no Brasil ou próximo da maioria dos usuários. Configure firewall, TLS, backup diário do PostgreSQL, cópia dos arquivos e alertas de disco. Se houver integrações com GitLab, monitoramento ou bots, acompanhe CPU e conexões WebSocket nos primeiros dias.

Esse perfil pode manter aplicação, banco e arquivos na mesma VPS, desde que exista margem. Defina limite de tamanho para uploads, política de retenção e rotina de limpeza quando aplicável. Para empresas pequenas, a maior ameaça nem sempre é falta de CPU. Muitas vezes é disco cheio, certificado expirado, backup nunca testado ou acesso SSH aberto demais.

Produção corporativa com compliance

Quando Mattermost vira canal oficial de uma operação com 80, 150 ou mais usuários, a arquitetura precisa amadurecer. Considere separar aplicação e PostgreSQL, usar object storage para anexos, configurar backups com retenção definida e testar restauração em janela documentada. Uma base comum seria 4 vCPUs e 8 GB de RAM para aplicação, banco em instância separada com disco rápido e monitoramento contínuo.

Nesse cenário, segurança pesa tanto quanto performance. Use SSO, controle de permissões, revisão de plugins, política de logs, atualização planejada e acesso administrativo restrito. Também defina quem responde a incidentes. Se o chat cair durante uma crise, a empresa precisa saber onde coordenar a recuperação. Infraestrutura self-hosted dá controle, mas esse controle vem acompanhado de responsabilidade operacional.

Quando uma VPS no Brasil faz mais sentido

Uma VPS no Brasil faz mais sentido quando a equipe está majoritariamente no país, quando a latência afeta a experiência diária e quando requisitos internos favorecem manter dados em infraestrutura nacional ou próxima. Para Mattermost, a diferença aparece em ações pequenas, como abrir canais, enviar mensagens, carregar histórico e baixar anexos. Em times que usam chat o dia todo, essas pequenas diferenças acumulam.

Também há fatores práticos. Pagamento em moeda local, suporte no mesmo fuso, emissão de nota e conectividade com usuários brasileiros podem pesar na decisão. Esses pontos variam por provedor e plano, então devem ser verificados antes da contratação. O ideal é testar uma instância por alguns dias, medir latência real, simular usuários simultâneos e validar backup. Uma boa VPS para Mattermost não é a que parece maior no papel, e sim a que entrega estabilidade, recuperação e crescimento sem surpresas.