Escolher uma VPS com Chatwoot não deveria começar pelo plano mais barato nem terminar na quantidade de memória exibida pelo provedor. Uma instalação self-hosted precisa sustentar aplicação web, workers, PostgreSQL, Redis, anexos, proxy, conexões em tempo real, integrações e rotinas de manutenção.
A documentação oficial oferece referências de CPU e memória, mas a capacidade real depende do seu uso: quantidade de conversas, atividade dos agentes, canais, anexos, automações, integrações, retenção e picos. A VPS adequada é aquela que passa por um piloto representativo, mantém margem e possui um caminho claro de expansão.
Este guia mostra como transformar “qual servidor devo contratar?” em uma decisão verificável — sem prometer que uma configuração serve para todas as empresas.
Qual VPS usar para Chatwoot? Resposta direta
Use os requisitos oficiais do Chatwoot como ponto de partida e dimensione a VPS com dados do seu cenário. A página de requisitos consultada em 15 de julho de 2026 informa 4 núcleos de CPU como orientação mínima recomendada para um dos cenários exemplificados e 4 GB de RAM como memória mínima exigida. A própria documentação condiciona CPU e memória à carga de trabalho.
Esses números não são um SLA de capacidade. Antes de contratar, estime:
- conversas recebidas por dia e por hora de pico;
- quantidade de agentes simultâneos;
- canais e integrações conectados;
- volume e tamanho de anexos;
- automações, webhooks e tarefas em segundo plano;
- período de retenção de dados;
- margem de crescimento;
- disponibilidade e tempo de recuperação necessários.
Para laboratório, uma arquitetura simples pode ajudar a validar o produto. Para produção, a escolha precisa considerar persistência, backup, monitoramento, segurança e quem responderá quando algum componente ficar saturado.
O que existe por trás de uma VPS com Chatwoot
O Chatwoot não é apenas uma página web. A arquitetura self-hosted envolve componentes com comportamentos diferentes.
Aplicação web
Atende o painel, APIs e requisições dos usuários. O consumo varia com agentes conectados, consultas, mensagens, relatórios e integrações.
Workers em segundo plano
O Sidekiq processa jobs assíncronos. Mensagens, emails, webhooks, automações e outras tarefas podem depender dessa fila. Uma interface que abre normalmente não prova que os workers estão saudáveis.
PostgreSQL
Armazena dados centrais da operação. Precisa de espaço, conexões, backup, observação de crescimento e compatibilidade com a versão adotada.
Redis
Participa de filas e cache. Deve ter memória, conectividade e configuração coerentes com a aplicação e os workers.
Anexos e object storage
Imagens, áudios e documentos podem crescer mais rápido do que o banco. A documentação cita provedores de object storage e serviços compatíveis com API S3 como opções para manter flexibilidade. Storage local também exige volume persistente, backup e margem.
Proxy, TLS e rede
Domínio, HTTPS, WebSockets, limites de upload e tráfego de saída fazem parte da experiência. Uma VPS com CPU livre ainda pode entregar um sistema ruim se disco, rede, proxy ou certificado forem o gargalo.
Como interpretar os requisitos oficiais sem comprar no escuro
A página oficial de requisitos do Chatwoot apresenta exemplos de CPU e memória conforme volume de conversas. Ela também deixa claro que a carga muda com atividade dos usuários, canais e uso esperado.
Trate a tabela como hipótese inicial, não como garantia. Existem pelo menos quatro motivos:
- duas operações com a mesma quantidade de agentes podem gerar volumes muito diferentes;
- anexos, integrações e automações aumentam trabalho fora da interface;
- picos importam mais do que uma média diária isolada;
- banco, Redis, workers e storage podem saturar em momentos diferentes.
Evite transformar “suporta até X conversas” em promessa comercial. O resultado depende da versão, arquitetura, configuração, padrão de uso e critério de desempenho. Faça um piloto e monitore o seu próprio ambiente.
Também consulte a arquitetura self-hosted e o método de deployment com Docker da versão adotada. Exemplos e requisitos podem mudar; registre a data e a fonte usadas na decisão.
VPS única ou serviços separados?
Uma VPS única pode reunir aplicação, workers, PostgreSQL e Redis. Esse desenho simplifica o início, mas compartilha recursos e concentra falhas. Se o banco consumir disco ou memória, toda a operação pode sentir o impacto.
Separar componentes aumenta as opções de escala e isolamento, porém adiciona rede, custo e complexidade. PostgreSQL gerenciado, object storage e nós separados para workers podem fazer sentido quando a criticidade ou o volume justificarem.
Use esta comparação:
| Arquitetura | Quando avaliar | Principal cuidado |
|---|---|---|
| VPS única | Piloto, laboratório ou operação inicial com risco controlado | Contenção de CPU/memória, ponto único de falha e restore completo |
| VPS com object storage | Crescimento relevante de anexos | Credenciais, acesso, CORS quando aplicável, backup e custo de tráfego |
| Aplicação e banco separados | Banco crítico ou necessidade de administração independente | Latência, rede privada, conexões, backup e custo operacional |
| Aplicação e workers separados | Filas ou automações pressionam a aplicação web | Observabilidade, mesma configuração de ambiente e coordenação de deploy |
| Arquitetura horizontal | Volume e criticidade justificam mais de um nó | Balanceamento, sessões, storage compartilhado, banco e operação mais madura |
Não escolha a arquitetura mais complexa apenas por aparência de robustez. Escolha a menor arquitetura que atenda aos critérios de risco, desempenho e recuperação — e que sua equipe consiga operar.
Sete critérios para escolher uma VPS para Chatwoot
1. CPU e memória com margem
Comece pela orientação oficial e teste com agentes, conversas, anexos e automações representativos. Observe uso sustentado e picos. Mantenha margem para atualizações, jobs e crescimento; operar permanentemente perto do limite transforma qualquer pico em incidente.
Considere também como o provedor entrega CPU. “vCPU” pode representar modelos de compartilhamento diferentes. Verifique política de uso, frequência, geração do processador e comportamento sob carga contínua.
2. Disco, IOPS e crescimento
Espaço em GB não conta toda a história. PostgreSQL e anexos também dependem de latência e operações de entrada/saída. Pergunte sobre tipo de disco, IOPS, expansão, snapshots, tráfego e monitoramento.
Projete separadamente:
- banco de dados;
- anexos;
- logs;
- backups locais temporários;
- margem para atualização e migração.
Não deixe backup apenas no mesmo disco ou na mesma VPS que ele precisa recuperar.
3. PostgreSQL, Redis e workers
Defina se banco e Redis compartilharão a VPS ou usarão serviços separados. Em qualquer desenho, monitore conexões, memória, espaço, filas, retries e jobs com falha.
A documentação informa PostgreSQL como banco suportado e descreve Redis como parte das filas e configurações em cache. Confirme versões e requisitos na documentação da release adotada, sem copiar uma configuração antiga para produção.
4. Rede, região e conectividade
Escolha região coerente com usuários, canais, integrações, política de dados e serviços dependentes. Latência entre aplicação, banco, Redis e storage pode afetar a operação.
Valide:
- IP e regras de firewall;
- DNS e HTTPS;
- WebSockets;
- tráfego de entrada e saída;
- conectividade privada entre serviços;
- proteção contra exposição desnecessária do banco e do Redis;
- processo de troca ou recuperação de IP.
5. Backup e restauração
A documentação oficial de backup do Chatwoot inclui banco, storage, configurações e customizações aplicáveis. A VPS precisa fazer parte de uma estratégia que permita recuperar o conjunto, não apenas um snapshot isolado.
Confirme retenção, criptografia, cópia fora do ambiente principal, monitoramento de falhas e teste de restauração. Um backup só se torna evidência operacional quando a equipe restaura e valida dados e anexos em ambiente separado.
6. Observabilidade e suporte do provedor
Antes de contratar, verifique quais métricas o provedor expõe e como incidentes são comunicados. CPU, memória, disco, rede e disponibilidade da VPS precisam ser correlacionados com logs da aplicação, filas, PostgreSQL e Redis.
O suporte da VPS normalmente não significa suporte ao Chatwoot. Registre a fronteira: quem cuida do hipervisor, sistema operacional, containers, aplicação, banco, canais e integrações?
7. Expansão, migração e saída
A VPS inicial não precisa ser a arquitetura definitiva, mas deve ter saída planejada. Pergunte como aumentar CPU, RAM e disco, quanto tempo a mudança exige, se existe redução posterior e como funciona a migração entre planos ou regiões.
Mantenha dados, configurações e backups portáveis. Não presuma upgrade sem indisponibilidade, migração automática ou compatibilidade universal entre provedores.
Método prático para dimensionar antes da contratação
Passo 1: crie um perfil de carga
Registre agentes simultâneos, conversas por hora e por dia, canais, anexos, automações, integrações e retenção. Use faixas e picos reais quando houver histórico.
Passo 2: classifique a criticidade
Defina quanto tempo o atendimento pode ficar indisponível e quanto dado pode ser perdido. Isso influencia redundância, backup, monitoramento e necessidade de serviços separados.
Passo 3: escolha uma hipótese inicial
Use os requisitos oficiais vigentes e a arquitetura mais simples compatível com o risco. Documente CPU, memória, disco, banco, Redis, storage, rede e responsabilidades.
Passo 4: execute um piloto representativo
Não teste apenas login. Simule agentes conectados, recebimento e envio de mensagens, anexos, webhooks, automações e relatórios relevantes. Observe aplicação e workers separadamente.
Passo 5: defina critérios de aceite
Exemplos:
- uso de recursos com margem durante pico;
- filas sem crescimento contínuo;
- latência aceitável para agentes;
- disco e banco com expansão planejada;
- backup concluído e restore validado;
- alertas chegando ao responsável;
- procedimento claro para aumentar capacidade.
Passo 6: revise após o início da operação
Dimensionamento não é decisão única. Revise capacidade quando canais, integrações, equipe, retenção ou volume mudarem. A melhor evidência é a telemetria do ambiente real, não uma recomendação genérica encontrada meses antes.
Perguntas para fazer ao provedor de VPS
- A CPU é compartilhada, dedicada ou sujeita a política de uso?
- Qual tipo de disco e quais limites de IOPS se aplicam?
- Como funcionam expansão de CPU, RAM e disco?
- Snapshots são backups independentes ou ficam no mesmo domínio de falha?
- Existe cópia entre regiões ou isso precisa ser contratado à parte?
- Quais limites e custos de tráfego existem?
- Há rede privada para banco, Redis ou storage?
- Como incidentes e manutenções são comunicados?
- Qual escopo do suporte do provedor?
- Como exportar volumes, snapshots e dados na saída?
- Existe proteção de rede ou serviço adicional contra ataques?
- Quais métricas e alertas ficam disponíveis?
Compare respostas por escrito. “Gerenciado” e “backup incluído” precisam de escopo, retenção, restauração e responsabilidades verificáveis.
Sinais de que a VPS pode estar subdimensionada
Nenhum indicador isolado fecha o diagnóstico. Observe combinações como:
- CPU ou memória próximas do limite de forma sustentada;
- swap intensa e lentidão em atualizações;
- filas e retries crescendo;
- respostas lentas durante picos;
- PostgreSQL com conexões, locks, latência ou disco pressionados;
- upload e download de anexos instáveis;
- falta de espaço para logs, migrações ou backup temporário;
- indisponibilidade quando aplicação e workers disputam recursos;
- alertas frequentes sem margem para crescimento.
Antes de apenas aumentar o plano, identifique o componente limitante. O problema pode estar em consulta, worker, banco, storage, rede, integração ou configuração — não necessariamente na quantidade total de RAM.
Onde o NooviChat entra nessa decisão
O NooviChat não é open-source. É uma distribuição privada/licenciada baseada em fork modificado do Chatwoot, comercializada por licença/acesso à imagem Docker. A licença comercial do NooviChat não é a Chatwoot Enterprise License e não implica afiliação, autorização ou endosso da Chatwoot Inc.
O NooviChat entra como alternativa licenciada para empresas que querem avaliar uma jornada mais orientada à operação brasileira. Isso não significa que VPS, backup, monitoramento, canais, integrações ou suporte estejam automaticamente incluídos. Confirme o escopo no plano, no contrato e na configuração vigentes.
Use a página de Chatwoot self-hosted no Brasil para entender a proposta e consulte os planos do NooviChat. Para comparar modelos e responsabilidades, veja também NooviChat versus Chatwoot.
Perguntas frequentes
Posso rodar Chatwoot em uma única VPS?
Pode ser uma hipótese inicial, desde que CPU, memória, disco, banco, Redis, workers, anexos e recuperação sejam testados para o seu cenário. Uma VPS única simplifica o desenho e concentra recursos e falhas. Produção exige margem, backup externo, observabilidade e plano de expansão.
4 GB de RAM são suficientes para Chatwoot?
A documentação oficial consultada informa 4 GB como memória mínima exigida em sua orientação atual, mas capacidade depende da carga. Trate esse valor como ponto de partida, não promessa. Teste agentes, conversas, anexos, automações e picos reais antes de aprovar produção.
Preciso separar PostgreSQL e Redis?
Não em todos os casos. Separar serviços pode melhorar isolamento e permitir escala independente, mas aumenta complexidade e custo. A decisão deve considerar criticidade, volume, capacidade técnica, rede, backup e recuperação.
Snapshot da VPS substitui backup do Chatwoot?
Não presuma isso. Um backup coerente precisa considerar banco, anexos, configurações e customizações aplicáveis. Mantenha cópia fora do ambiente principal e execute restauração de teste.
VPS mais cara garante Chatwoot mais rápido?
Não. Mais recursos podem ajudar quando existe saturação, mas desempenho também depende de banco, workers, storage, rede, versão, configuração e integrações. Meça o gargalo antes de aumentar o plano.
O NooviChat inclui a VPS?
O escopo deve ser confirmado na oferta vigente. O NooviChat é uma distribuição privada/licenciada vendida por licença/acesso à imagem Docker; infraestrutura, canais, integrações, backup, suporte e responsabilidades variam conforme plano, contrato e configuração.
Conclusão: contrate capacidade com evidência
Uma VPS para Chatwoot deve ser escolhida com perfil de carga, criticidade, piloto e critérios de aceite. Os requisitos oficiais ajudam a começar, mas não substituem medição nem definem a arquitetura ideal para toda empresa.
Mapeie aplicação, workers, PostgreSQL, Redis, anexos e rede; valide backup e expansão; esclareça responsabilidades do provedor e da sua equipe. Se você quer comparar esse caminho com uma distribuição privada/licenciada, conheça o NooviChat self-hosted e leve este checklist para a conversa sobre planos e responsabilidades.