Chatwoot no Brasil: VPS para atendimento estável

Resposta direta

Para rodar Chatwoot no Brasil com estabilidade, a VPS deve ter recursos suficientes para uma aplicação Ruby on Rails, banco PostgreSQL, Redis, filas Sidekiq, SSL e armazenamento persistente. Em produção pequena, pense em 2 vCPUs, 4 GB de RAM e 60 GB de SSD como ponto de partida. Para equipes com vários atendentes, WhatsApp, e-mail, webchat e integrações via API, 4 vCPUs, 8 GB de RAM e disco SSD ou NVMe com backup testado fazem mais sentido. A localização do datacenter também pesa: servidores no Brasil costumam reduzir latência para usuários e operadores locais, mas não substituem boa configuração de banco, filas e monitoramento. O ideal é escolher uma VPS ou Cloud Server que permita upgrade simples, snapshots, firewall, IP fixo, acesso root e rotina clara de restauração.

Resumo rápido

• Chatwoot é uma aplicação Ruby on Rails, não um site estático simples, então CPU, RAM e I/O de disco importam bastante.
• Para produção básica, use no mínimo 2 vCPUs, 4 GB de RAM e 60 GB de SSD, evitando planos muito apertados de 1 GB.
• PostgreSQL e Redis são partes centrais da estabilidade, especialmente com conversas, relatórios, filas e notificações em tempo real.
• Datacenter no Brasil pode melhorar a experiência de atendentes e visitantes locais, principalmente no painel e no widget de chat.
• SSL, DNS correto e webhooks bem configurados reduzem falhas em integrações com canais externos e automações.
• Backups precisam incluir banco, uploads, variáveis de ambiente e configuração do Docker, não apenas uma imagem solta do servidor.
• VPS tradicional pode atender projetos menores, enquanto Cloud Server facilita upgrade, snapshots e recuperação operacional.

Por que o Chatwoot exige mais cuidado que um site comum

Chatwoot parece simples quando visto pelo painel: caixas de entrada, contatos, conversas e relatórios. Por baixo, porém, ele é uma aplicação web completa, com componentes que trabalham ao mesmo tempo. Há o servidor Rails respondendo requisições, o PostgreSQL guardando conversas e usuários, o Redis sustentando cache e filas, o Sidekiq processando tarefas em segundo plano e o Action Cable mantendo recursos em tempo real. Isso muda bastante a escolha da VPS para Chatwoot no Brasil, porque não basta perguntar se o servidor “roda”. A pergunta certa é se ele roda bem durante o horário de pico, com atendentes conectados e mensagens chegando por vários canais.

Em um site institucional pequeno, uma queda de desempenho pode aparecer como página mais lenta. No Chatwoot, o impacto é mais visível. Uma fila travada pode atrasar notificações, um banco saturado pode deixar o painel lento, e falta de memória pode derrubar containers justamente quando a equipe está atendendo clientes. Um cenário comum é começar com 1 vCPU e 1 GB de RAM porque a instalação subiu sem erro. Dias depois, ao conectar WhatsApp via provedor externo, e-mail, webchat e alguns webhooks, o servidor começa a usar swap. O painel abre, mas relatórios demoram e mensagens parecem chegar em lote.

O que roda por baixo do Chatwoot

O Chatwoot é construído sobre Ruby on Rails, por isso herda vários padrões de operação desse ecossistema. Se você já dimensionou infraestrutura Rails, a lógica é parecida: servidor de aplicação, banco relacional, jobs em background e cache precisam trabalhar em equilíbrio. Quem quiser aprofundar a camada Rails pode usar como referência o conteúdo sobre VPS para Ruby on Rails no Brasil, já que muitos cuidados de Puma, memória e deploy se aplicam também ao Chatwoot.

Na prática, uma instalação via Docker Compose costuma envolver containers para aplicação, worker, banco, Redis e proxy reverso. Em ambientes maiores, esses serviços podem ser separados em servidores diferentes, mas muitas empresas começam com tudo na mesma VPS. Isso funciona, desde que haja folga. Se a VPS tiver 4 GB de RAM, por exemplo, você precisa reservar memória para o sistema operacional, PostgreSQL, Redis, Rails, Sidekiq, Nginx ou Traefik, além de margem para picos. Sem essa reserva, o kernel pode encerrar processos por falta de memória, e o atendimento vira loteria.

Onde surgem os gargalos em produção

Os gargalos mais comuns aparecem em três pontos: banco de dados, filas e disco. O PostgreSQL cresce com mensagens, anexos referenciados, eventos, contatos e relatórios. O Redis e o Sidekiq entram forte quando há notificações, e-mails, integrações e tarefas agendadas. Já o disco sofre quando existem muitos uploads, logs sem rotação ou backups locais acumulados. Um exemplo realista: uma operação com 12 atendentes, 4 caixas de entrada e 8 mil conversas mensais pode funcionar bem em 4 vCPUs e 8 GB de RAM, mas começar a perder fôlego se os logs ficarem sem rotação por meses e o banco nunca receber vacuum e manutenção.

Arquitetura recomendada para Chatwoot self-hosted

A arquitetura mais comum para Chatwoot self-hosted em VPS é baseada em Docker Compose. Ela facilita instalação, atualização e isolamento de serviços, além de tornar a recuperação mais previsível quando existe backup dos volumes e do arquivo de configuração. Um desenho básico inclui Nginx ou Traefik na frente, container web do Chatwoot, container worker para Sidekiq, PostgreSQL, Redis e volumes persistentes. Em um ambiente pequeno, tudo pode ficar em um único Cloud Server. Em produção mais séria, separar banco e aplicação reduz risco e melhora manutenção.

Para começar com segurança, prefira uma distribuição LTS, como Ubuntu Server 22.04 LTS ou 24.04 LTS, Docker atualizado, firewall ativo e acesso SSH por chave. Evite instalar serviços extras no mesmo servidor, como painel de hospedagem pesado, múltiplos sites WordPress e ferramentas de monitoramento mal configuradas. Chatwoot precisa de previsibilidade. Se o servidor também hospeda outras aplicações que consomem CPU e RAM, fica mais difícil entender quem causou lentidão durante o pico.

Componentes mínimos

Um exemplo de stack enxuta inclui Docker Engine, Docker Compose, Nginx como proxy reverso, Certbot ou Traefik para SSL, PostgreSQL 14 ou superior, Redis 6 ou superior e containers do Chatwoot. O domínio pode seguir um padrão como atendimento.exemplo.com.br, com registro A apontando para o IP da VPS. Em seguida, o proxy recebe tráfego HTTPS na porta 443 e encaminha para o serviço web interno. O worker Sidekiq não precisa ficar exposto à internet, mas precisa acessar Redis, PostgreSQL e as variáveis de ambiente corretas.

As variáveis sensíveis, como chaves secretas, credenciais SMTP e tokens de integrações, devem ficar em arquivo .env protegido, nunca em repositório público. Um erro comum é copiar tutoriais e deixar credenciais em histórico de Git. Outro é expor o PostgreSQL na porta 5432 para a internet sem necessidade. Se banco e aplicação estão na mesma VPS, use rede interna do Docker e bloqueie acesso externo. Se o banco estiver separado, restrinja por IP e use senha forte.

Separar serviços ou manter tudo na mesma VPS

Manter tudo na mesma VPS simplifica o começo. É uma boa opção para times pequenos, validação interna e atendimento com baixo volume. A desvantagem é que qualquer pico afeta todos os componentes. Se o PostgreSQL consumir I/O por causa de relatório pesado, o Rails e o Sidekiq também sentem. Separar serviços melhora isolamento: uma VPS para aplicação e workers, outra para PostgreSQL, e eventualmente Redis gerenciado ou dedicado. Essa divisão traz custo operacional maior, mas também facilita manutenção, upgrade e restauração.

Um meio-termo interessante é começar com uma VPS maior, por exemplo 4 vCPUs e 8 GB de RAM, mantendo tudo junto, mas já organizar backups e Docker Compose como se fosse migrar depois. Quando o volume crescer, o banco pode ir para uma instância dedicada sem refazer toda a operação. Essa preparação evita migrações emergenciais na sexta-feira à tarde, quando o suporte está cheio e ninguém quer descobrir dependências esquecidas.

Como dimensionar CPU, RAM, disco e rede

Dimensionar uma VPS para Chatwoot no Brasil exige olhar para número de atendentes simultâneos, canais conectados, volume de conversas, uso de anexos e quantidade de automações. Não existe uma configuração única, porque duas empresas com 10 atendentes podem ter cargas bem diferentes. Uma operação que usa apenas webchat e e-mail tende a exigir menos processamento do que outra com WhatsApp, integrações de CRM, webhooks e relatórios frequentes. Ainda assim, dá para trabalhar com faixas realistas.

Para um ambiente de teste, 1 vCPU e 2 GB de RAM podem ser suficientes, desde que você não trate isso como produção. Para produção pequena, 2 vCPUs e 4 GB de RAM são uma base mais confortável. Com menos que isso, o servidor pode subir, mas terá pouca margem para PostgreSQL, Redis e workers. Em produção média, 4 vCPUs e 8 GB de RAM oferecem espaço para mais conexões simultâneas e processamento de filas. Para atendimento crítico, considere 8 vCPUs, 16 GB de RAM, banco separado e monitoramento ativo.

Configurações por volume de atendimento

Pense em um time com 3 atendentes, 2 caixas de entrada e até 1.500 conversas por mês. Nesse caso, 2 vCPUs, 4 GB de RAM e 60 GB de SSD podem atender bem, se houver logs rotacionados e backups externos. Agora imagine 15 atendentes, WhatsApp, e-mail, webchat e automações que chamam APIs externas. A configuração de 4 vCPUs, 8 GB de RAM e 100 GB de SSD ou NVMe fica mais adequada. Para 40 atendentes e alto volume de anexos, o gargalo provavelmente deixa de ser apenas CPU e passa a envolver banco, disco, rede e desenho da arquitetura.

Disco merece atenção especial. SSD é o mínimo recomendado. NVMe pode ajudar em cargas com mais I/O, como consultas frequentes, escrita de logs, backups e operações intensas no PostgreSQL, mas não resolve tudo sozinho. Se a aplicação faz consultas ruins, se o banco está sem manutenção ou se o servidor está sem RAM, trocar SSD por NVMe pode gerar ganho limitado. Avalie também espaço para anexos, dumps de banco, logs e snapshots. Uma VPS com 40 GB pode parecer suficiente no primeiro mês e ficar apertada depois de uma campanha de atendimento com muitos arquivos.

Tabela de perfis de infraestrutura

Perfil de uso	Configuração sugerida	Volume aproximado	Arquitetura indicada	Observações operacionais
Teste e homologação	1 vCPU, 2 GB RAM, 30 GB SSD	1 a 3 usuários internos	Tudo na mesma VPS	Não usar como produção, sem anexos pesados
Produção pequena	2 vCPUs, 4 GB RAM, 60 GB SSD	3 a 8 atendentes	Chatwoot, PostgreSQL e Redis juntos	Backup externo diário e monitoramento básico
Produção média	4 vCPUs, 8 GB RAM, 100 GB SSD ou NVMe	8 a 25 atendentes	Tudo junto com folga ou banco separado	Boa faixa para WhatsApp, e-mail, webchat e filas
Produção crítica	8 vCPUs, 16 GB RAM, 160 GB NVMe	25 ou mais atendentes	Aplicação, banco e Redis separados	Exige rotina de restauração, métricas e alertas

Rede também entra na conta. O Chatwoot não costuma exigir banda extrema como streaming de vídeo, mas anexos, imagens, históricos e integrações consomem tráfego. Verifique limites de transferência mensal, política de abuso e velocidade de porta no provedor. Dados de bandwidth, preço e disponibilidade por região mudam com frequência, então devem ser confirmados no site oficial antes da contratação.

PostgreSQL, Redis e filas: o trio que define estabilidade

Quando o Chatwoot fica lento, muita gente olha primeiro para CPU. Às vezes é CPU mesmo. Só que, em boa parte dos casos, o problema está no banco, no Redis ou nas filas. O PostgreSQL guarda o coração da operação: contatos, mensagens, caixas de entrada, usuários, relatórios e eventos. O Redis ajuda em cache e processamento assíncrono. O Sidekiq executa tarefas em background, como envio de e-mails, integrações e jobs internos. Se um desses componentes fica sem recurso, o painel pode continuar abrindo, mas a experiência degrada.

Para PostgreSQL, RAM e disco rápido são decisivos. Um banco pequeno roda em configuração modesta, mas cresce com o tempo. Conversas antigas, metadados, eventos e anexos referenciados aumentam a quantidade de leituras e escritas. Um bom ponto de partida é reservar pelo menos 1 GB de RAM efetivamente disponível para PostgreSQL em instalações pequenas, subindo conforme o uso. Em uma VPS de 4 GB, isso já exige cuidado, porque sistema operacional, Rails, Sidekiq e Redis também precisam respirar. Se você quer aprofundar esse ponto, o guia de VPS para banco PostgreSQL ajuda a entender IOPS, memória, backup e isolamento do banco.

PostgreSQL sem virar ponto único de falha

O banco não pode depender apenas de snapshot eventual. Snapshot da VPS é útil para recuperação rápida, mas backup lógico do PostgreSQL continua necessário. Uma rotina simples pode gerar dump diário com pg_dump, compactar o arquivo, enviar para armazenamento externo e manter retenção de 7, 14 ou 30 dias. Para operações maiores, o ideal é testar restore em ambiente separado, porque backup que nunca foi restaurado é apenas uma promessa.

Também faz sentido monitorar crescimento do banco. Se o dump tinha 800 MB em janeiro e passou para 8 GB em agosto, algo mudou. Pode ser crescimento natural, excesso de logs, anexos, integrações ou retenção sem política definida. No PostgreSQL, manutenção com vacuum, análise de consultas e índices adequados ajuda a evitar lentidão. Não é preciso transformar a equipe de atendimento em DBA, mas alguém precisa olhar métricas mínimas: uso de disco, conexões, tempo de consulta e tamanho das tabelas.

Redis e Sidekiq no atendimento em tempo real

Redis costuma ser leve, mas não deve ser ignorado. Se ele ficar sem memória ou reiniciar em momento ruim, filas e recursos em tempo real podem sofrer. Em Chatwoot com volume moderado, reservar algumas centenas de MB para Redis pode bastar. Em ambientes maiores, configure limites, persistência conforme necessidade e monitoramento. O conteúdo sobre VPS para Redis e cache é uma boa leitura complementar para entender quando Redis precisa ficar separado e quando pode dividir servidor.

Sidekiq é outro ponto sensível. Se há muitos jobs acumulados, mensagens e notificações podem atrasar. Um exemplo prático: depois de uma instabilidade no provedor de e-mail, a fila pode crescer com tentativas de reenvio. Quando o serviço volta, o worker tenta processar tudo e consome CPU. Nessa hora, ter 2 vCPUs sem folga pode deixar o painel pesado. Em uma instalação média, rodar worker separado do processo web, ainda que no mesmo servidor, já melhora a previsibilidade. Em produção crítica, workers dedicados são mais seguros.

Brasil, latência, SSL e entregabilidade

Escolher uma VPS para Chatwoot no Brasil não é apenas uma questão de patriotismo de infraestrutura. Latência afeta a experiência de atendentes que passam o dia no painel, clientes que abrem o widget no site e integrações que dependem de webhooks rápidos. Um servidor em São Paulo, por exemplo, pode responder com latências bem menores para usuários brasileiros do que uma instância em regiões distantes dos Estados Unidos ou Europa. Ainda assim, localização não compensa configuração ruim. Um servidor brasileiro saturado será pior que uma instância estrangeira bem dimensionada.

Para empresas com operação nacional, datacenter no Brasil ou em região próxima pode reduzir tempo de carregamento do painel, abertura de conversas e envio de anexos. Em atendimento, pequenos atrasos incomodam. Um operador que alterna entre dezenas de conversas percebe quando cada clique demora 800 ms a mais. Se a equipe usa VPN corporativa, rede interna ou integrações com sistemas hospedados no Brasil, manter o Chatwoot próximo desses serviços também pode melhorar a consistência.

Quando datacenter no Brasil faz diferença

O ganho tende a ser mais claro quando atendentes e clientes estão majoritariamente no Brasil. Uma loja virtual brasileira usando widget de chat, e-mail transacional e integração com CRM nacional se beneficia de menor latência. Já uma empresa com equipe distribuída entre Brasil, Europa e América do Norte precisa avaliar onde está o público principal e quais integrações são mais críticas. Nesses casos, medir ping, traceroute e tempo real de resposta da aplicação é melhor do que escolher região no escuro.

Provedores como DigitalOcean, Vultr, AWS Lightsail, Linode/Akamai, Hostinger, Locaweb, HostGator e LetsCloud podem entrar no radar, cada um com diferenças de painel, regiões, suporte, rede e recursos. Dados de localidade, storage, bandwidth e planos variam, então a comparação final precisa ser conferida nas páginas oficiais na data da contratação. No caso da LetsCloud, faz sentido avaliar quando o projeto busca operação próxima ao público brasileiro, pagamento local ou regiões específicas, mas disponibilidade de NVMe, snapshots, backup e localidades deve ser confirmada por plano.

SSL, DNS e webhooks

SSL precisa estar correto desde o primeiro dia. Chatwoot lida com login, dados de clientes e integrações, então HTTPS não é opcional. Use certificados válidos, renove automaticamente e monitore expiração. Com Nginx e Certbot, uma configuração típica redireciona HTTP para HTTPS e encaminha tráfego para o container web. Com Traefik, o próprio proxy pode emitir certificados via Let’s Encrypt. O importante é manter domínio, APP_URL e configurações de proxy coerentes, porque URLs erradas quebram callbacks, links de e-mail e webhooks.

DNS também merece cuidado. Um registro A apontando para IP fixo é o básico. Se houver Cloudflare ou outro proxy, revise limites de upload, modo SSL e cache. Webhooks de canais externos precisam chegar ao servidor sem bloqueio. Firewalls agressivos, WAF mal configurado ou portas fechadas podem impedir integrações. Para e-mail, configure SMTP autenticado, SPF, DKIM e DMARC no domínio remetente. Isso não é glamour técnico, mas evita que notificações caiam em spam ou simplesmente não cheguem.

Segurança, backup e operação diária

Hospedar Chatwoot por conta própria dá controle, mas também transfere responsabilidades para a equipe. Segurança começa com o básico: SSH por chave, senha de root desabilitada, firewall permitindo apenas portas necessárias, atualizações de sistema, Docker sem containers privilegiados desnecessários e variáveis de ambiente protegidas. Em uma instalação padrão, portas públicas comuns seriam 80 e 443 para web, 22 restrita por IP ou protegida com medidas adicionais, e nada de PostgreSQL ou Redis expostos à internet.

Acesso administrativo também precisa de política. Não compartilhe o mesmo usuário entre várias pessoas. Use senhas fortes, 2FA quando disponível e revisão periódica de usuários. Em times com rotatividade, desligar um atendente do Chatwoot é fácil, mas esquecer acesso SSH, painel cloud ou repositório de deploy é um risco maior. Documente quem tem acesso ao provedor, ao domínio, ao SMTP e ao armazenamento de backups.

Checklist básico de hardening

Um checklist enxuto já reduz bastante a superfície de ataque. Configure UFW ou firewall do provedor, limite SSH, aplique atualizações de segurança, revise permissões do .env, ative logs e use fail2ban quando fizer sentido. Se usar Docker, mantenha imagens atualizadas e acompanhe notas de release do Chatwoot antes de atualizar em produção. Uma atualização sem leitura pode quebrar dependências, mas ficar meses sem atualizar também aumenta risco.

Outro cuidado é separar ambientes. Homologação e produção não deveriam compartilhar o mesmo banco. Testes de integração com WhatsApp, automações e webhooks podem gerar dados estranhos ou filas inesperadas. Se a empresa depende do Chatwoot para vender e prestar suporte, vale ter uma VPS menor para homologação. Ela não precisa ter o mesmo tamanho da produção, mas precisa reproduzir a stack principal.

Backups que realmente podem ser restaurados

Backup bom tem três partes: dados, configuração e teste. No Chatwoot, isso inclui dump do PostgreSQL, volumes de upload, arquivo .env, docker-compose.yml, configuração do proxy e registros de versão. Snapshots da VPS ajudam quando uma atualização falha, mas não substituem backup granular. Se o servidor for comprometido, um snapshot no mesmo provedor e na mesma conta pode não ser suficiente. Armazenamento externo, com retenção e acesso separado, é mais seguro.

Um exemplo prático de rotina: dump diário às 3h, envio para bucket externo, retenção de 14 dias, snapshot antes de atualizações e teste mensal de restauração em ambiente isolado. Para operações críticas, reduza o RPO com backups mais frequentes ou replicação de banco. Também monitore espaço livre. Backup que falha por falta de disco costuma falhar em silêncio quando ninguém configurou alerta. Use métricas simples, como CPU, RAM, disco, fila Sidekiq, status HTTP e validade do SSL.

Recomendações por perfil

Dev solo ou projeto interno

Para um dev solo, consultoria pequena ou time que quer validar Chatwoot internamente, a prioridade deve ser simplicidade sem cair em configuração frágil. Uma VPS com 2 vCPUs, 4 GB de RAM e 60 GB de SSD já oferece margem razoável para Docker, PostgreSQL, Redis e um volume baixo de conversas. Use Ubuntu LTS, Docker Compose, domínio próprio e SSL automático. Evite gastar tempo separando todos os serviços no primeiro dia, mas documente a instalação e mantenha backups fora da VPS. Se o projeto ainda é piloto, monitore principalmente uso de RAM, disco e fila Sidekiq. Quando a equipe começar a depender do Chatwoot diariamente, trate a instância como produção, não como laboratório permanente.

Time de atendimento em crescimento

Para uma equipe com 8 a 25 atendentes, múltiplas caixas de entrada e canais como e-mail, webchat e WhatsApp, o ponto de partida mais equilibrado costuma ser 4 vCPUs, 8 GB de RAM e 100 GB de SSD ou NVMe. Nessa faixa, você consegue manter aplicação, worker, PostgreSQL e Redis no mesmo Cloud Server com alguma folga, desde que os backups sejam externos e os logs estejam sob controle. Se relatórios ficarem lentos ou a fila crescer com frequência, considere separar PostgreSQL primeiro. Também vale criar ambiente de homologação para testar atualizações do Chatwoot, integrações e mudanças de SMTP antes de mexer na produção.

Produção crítica com múltiplos canais

Para empresas que dependem do Chatwoot como central de atendimento, vendas e suporte, a infraestrutura precisa ser pensada como serviço crítico. Use pelo menos 8 vCPUs e 16 GB de RAM na camada principal ou separe aplicação, workers, PostgreSQL e Redis em instâncias diferentes. Banco dedicado, backups testados, snapshots antes de deploys, monitoramento com alertas e plano de rollback deixam de ser luxo. Também faz sentido revisar retenção de dados, política de anexos, permissões administrativas e entregabilidade de e-mail. Se a operação atende em horário comercial amplo ou 24 por 7, defina responsáveis por incidentes e mantenha documentação de restauração acessível. O custo de uma hora fora do ar pode superar a economia de um plano subdimensionado.