Escolher entre Chatwoot Cloud e self-hosted não é apenas decidir se o sistema ficará “na nuvem” ou no seu servidor. A escolha muda quem opera a infraestrutura, quem executa atualizações, como backups são testados, quais incidentes sua equipe precisa resolver e qual custo total aparece depois da contratação.
O Cloud tende a reduzir o trabalho de manter os componentes principais da aplicação. O self-hosted amplia o controle sobre o ambiente, mas também transfere mais responsabilidades para a empresa ou para um fornecedor contratado. Nenhum dos dois é automaticamente melhor, mais barato ou mais seguro em todos os cenários.
Este guia apresenta uma matriz de decisão para comparar os dois modelos com o mesmo escopo. O objetivo é evitar uma compra baseada apenas na mensalidade, no preço da licença ou no custo de uma VPS.
Chatwoot Cloud vs self-hosted: a diferença não é só onde o software roda
No modelo Cloud, a empresa contrata o serviço hospedado oferecido pelo próprio fornecedor. A infraestrutura principal da aplicação faz parte dessa oferta, conforme plano e condições vigentes. O cliente continua responsável por configuração de usuários, governança, canais, integrações, dados inseridos e processos internos.
No modelo self-hosted, a organização instala o Chatwoot em uma infraestrutura sob sua responsabilidade direta ou delegada. Isso pode ocorrer em uma VPS, ambiente de nuvem, cluster ou arquitetura administrada por um parceiro. A documentação oficial de arquitetura self-hosted do Chatwoot mostra que a operação envolve mais do que um container de aplicação: banco de dados, Redis, workers, armazenamento, email e outros componentes precisam funcionar em conjunto.
A pergunta correta não é “qual versão tem mais controle?”. É:
Quem será responsável por cada camada, com qual capacidade técnica, evidência operacional e custo ao longo do tempo?
O que muda quando você escolhe Chatwoot Cloud
A principal vantagem operacional do Cloud é reduzir o número de componentes que sua equipe precisa hospedar e manter diretamente. Em vez de administrar servidor, banco, filas, storage e ciclos de atualização da aplicação principal, a empresa contrata uma oferta hospedada.
Isso pode ser adequado quando:
- o time quer colocar a operação em funcionamento sem formar uma equipe de DevOps para o produto;
- a política da empresa permite usar um serviço hospedado;
- a prioridade é concentrar pessoas em atendimento, canais e processos;
- a organização aceita as condições, limites, regiões e responsabilidades descritos no plano vigente;
- customizações profundas de infraestrutura não são requisito central.
Cloud, porém, não elimina todo trabalho técnico. A empresa ainda precisa configurar acessos, times, inboxes, canais, webhooks, automações e integrações. Também precisa governar dados, revisar permissões, acompanhar fornecedores externos e manter processos de continuidade do próprio negócio.
Antes de contratar, consulte o pricing oficial do Chatwoot Cloud e confirme recursos, limites, suporte e condições atuais. Não presuma que uma informação vista em uma comparação antiga ainda vale.
O que muda quando você escolhe Chatwoot self-hosted
No self-hosted, a empresa controla o ambiente de execução e pode alinhar rede, acesso, observabilidade e arquitetura às suas políticas. Esse controle vem acompanhado de responsabilidade operacional.
A documentação oficial de requisitos do Chatwoot self-hosted deve ser tratada como referência inicial datada, não como garantia de capacidade para qualquer volume. O dimensionamento real depende de conversas, agentes, canais, anexos, automações, integrações, retenção, picos e nível de disponibilidade esperado.
Self-hosted tende a fazer sentido quando:
- existe requisito claro de controle sobre a infraestrutura;
- a empresa possui equipe interna ou fornecedor responsável por operação;
- backup, restauração, monitoramento e resposta a incidentes já fazem parte da rotina;
- há necessidade validada de integrar o ambiente a redes ou serviços internos;
- a organização aceita administrar atualizações e compatibilidade entre componentes;
- o custo total foi calculado além da VPS.
O erro comum é instalar primeiro e definir responsabilidades depois. Em produção, alguém precisa monitorar aplicação e workers, manter banco e Redis, acompanhar storage, renovar certificados, revisar segurança, aplicar upgrades e executar rollback quando necessário.
A página oficial de ofertas self-hosted do Chatwoot deve ser revalidada antes da decisão. Edição, licença, suporte comercial e operação da infraestrutura são camadas diferentes; uma não inclui automaticamente as outras.
Matriz rápida: Chatwoot Cloud vs self-hosted
| Critério | Chatwoot Cloud | Chatwoot self-hosted | Pergunta de validação |
|---|---|---|---|
| Infraestrutura principal | Incluída na oferta hospedada, conforme contrato | Operada pelo cliente ou fornecedor contratado | Quem responde por aplicação, banco, Redis e storage? |
| Atualizações da aplicação | Conduzidas no serviço hospedado | Planejadas e executadas pelo operador do ambiente | Existe janela, teste e rollback documentados? |
| Controle do ambiente | Limitado ao que a oferta permite | Maior controle sobre rede, acesso e arquitetura | Esse controle é requisito ou apenas preferência? |
| Backup e recuperação | Confirmar escopo e condições do serviço | Precisam ser projetados, executados e testados | Quem prova que a restauração funciona? |
| Observabilidade | Parte da operação do serviço, com visibilidade conforme oferta | Deve ser implementada para todos os componentes relevantes | Quais alertas e logs existem antes de um incidente? |
| Escala | Condicionada aos planos e limites vigentes | Depende de arquitetura, capacidade e operação | Como picos e crescimento serão testados? |
| Suporte | Conforme plano contratado | Comunidade, oferta comercial ou parceiro, conforme escolha | O suporte cobre produto, infraestrutura ou ambos? |
| Custo | Assinatura e custos externos aplicáveis | Infraestrutura, licença aplicável, pessoas, operação e risco | A comparação usa o mesmo horizonte e escopo? |
| Saída | Verificar exportação e condições contratuais | Verificar dados, configurações, backups e dependências | Como será a transição se o modelo mudar? |
A tabela não declara um vencedor. Ela expõe as perguntas que precisam ser respondidas antes de comparar propostas.
Nove critérios para tomar a decisão
1. Controle e governança de dados
Self-hosted oferece mais controle sobre o ambiente em que a aplicação roda, mas isso não significa conformidade automática. Controle sem política, inventário, acesso restrito, logs, retenção e resposta a incidentes pode apenas transferir o risco.
No Cloud, confirme onde os compromissos sobre dados, suboperadores, retenção, exportação e segurança estão documentados. No self-hosted, defina quem administra credenciais, banco, backups, storage, chaves e acessos privilegiados.
Em ambos os casos, LGPD e governança dependem do processo completo, não apenas do local do servidor.
2. Capacidade técnica disponível
A decisão self-hosted precisa de um responsável operacional real. “O desenvolvedor instala” não responde quem cuidará do sistema seis meses depois, durante um incidente ou atualização.
Liste as competências necessárias:
- Linux, containers e rede;
- PostgreSQL e Redis;
- storage, DNS, TLS e email;
- logs, métricas e alertas;
- backup e restauração;
- atualização e rollback;
- segurança e gestão de acessos;
- investigação de integrações e webhooks.
Se essas competências não existem internamente, inclua um fornecedor qualificado no desenho e no TCO. Cloud pode reduzir essa carga, mas não substitui a administração funcional da operação.
3. Atualizações, compatibilidade e rollback
Uma atualização não termina quando a nova imagem ou versão sobe. É preciso verificar banco, filas, workers, integrações, canais, automações e experiência dos agentes.
A documentação oficial de upgrade do Chatwoot é ponto de partida. Em produção, complete-a com:
- leitura de notas da versão;
- backup verificável;
- teste em ambiente compatível;
- janela de mudança;
- critérios de sucesso;
- plano de rollback;
- smoke tests de login, inbox, envio, recebimento e integrações.
No Cloud, o fornecedor conduz o ciclo da aplicação hospedada. Ainda assim, sua equipe deve acompanhar mudanças que afetem processo, integração ou treinamento.
4. Backup e restauração
Backup sem teste de restauração é uma hipótese. No self-hosted, defina escopo, frequência, retenção, criptografia, local de cópia e responsável pelo teste. Banco, anexos e configurações precisam ser tratados de forma coerente para evitar uma recuperação incompleta.
No Cloud, confirme o que a oferta cobre e quais mecanismos de exportação ou recuperação estão disponíveis. Não transforme a existência de backup do fornecedor em promessa de restauração no prazo desejado sem evidência contratual.
A pergunta prática é: se a operação parar hoje, quem recupera o quê, em qual ordem e com qual objetivo de tempo e perda de dados?
5. Observabilidade e resposta a incidentes
Um health check da página não garante que toda a operação está saudável. Workers podem estar atrasados, webhooks podem falhar, disco pode crescer e o banco pode degradar enquanto a interface ainda abre.
No self-hosted, monitore os componentes relevantes e defina alertas acionáveis. Registre severidades, responsáveis, contatos e procedimento de escalonamento. No Cloud, entenda quais status, logs e canais de suporte ficam disponíveis ao cliente e onde começam as responsabilidades de provedores externos.
WhatsApp, email, redes sociais e integrações adicionam fronteiras. Um incidente pode estar na aplicação, no canal, no provedor, na credencial ou na automação.
6. Capacidade, desempenho e crescimento
Não use um requisito mínimo como promessa de desempenho. Faça um piloto com volume representativo, anexos, automações e integrações reais. Observe uso de recursos, filas, latência e comportamento em picos.
No self-hosted, determine como aumentar capacidade e qual componente tende a limitar primeiro. No Cloud, confirme limites e regras de expansão do plano vigente.
A comparação deve considerar não apenas o volume atual, mas a margem necessária para campanhas legítimas com opt-in, sazonalidade, novas equipes e maior retenção de histórico. Nenhum modelo elimina a necessidade de respeitar políticas dos canais e boas práticas de privacidade.
7. Canais, integrações e automações
Cloud e self-hosted não tornam uma integração automaticamente pronta. API e webhooks oferecem meios técnicos; não garantem conector mantido, compatibilidade universal ou ausência de custo de terceiros.
Antes de decidir, catalogue:
- canais obrigatórios e respectivos provedores;
- credenciais e aprovações necessárias;
- CRMs, ERPs, bots e automações;
- proprietário de cada integração;
- retentativas, idempotência, logs e alertas;
- versões e mudanças de API;
- custos e contratos externos.
Para WhatsApp, não baseie a escolha em promessas de bypass, “anti-ban”, envio irrestrito ou contorno de políticas. Arquitetura, opt-in, templates quando aplicáveis, qualidade da operação e regras do provedor continuam relevantes.
8. Suporte e fronteiras de responsabilidade
“Tem suporte” é insuficiente. Separe suporte ao produto de administração da infraestrutura, canais e integrações.
No Cloud, verifique o atendimento incluído no plano. No self-hosted, a ajuda pode vir da comunidade, de uma oferta comercial, da equipe interna ou de um parceiro. Em qualquer caso, registre:
- canal e horário;
- prazo de primeira resposta;
- severidades;
- componentes cobertos;
- exclusões;
- processo de escalonamento;
- responsabilidade por terceiros;
- evidência de SLA, quando contratado.
Enterprise, licença comercial ou suporte prioritário não significam automaticamente hospedagem, DevOps ou operação gerenciada.
9. Custo total e estratégia de saída
Compare os dois modelos no mesmo horizonte e com o mesmo escopo. No Cloud, inclua assinatura, canais, IA, integrações, implantação e operação interna aplicáveis. No self-hosted, inclua também infraestrutura, banco, storage, observabilidade, backup, segurança, horas técnicas, atualização e contingência.
Não existe economia universal. Uma equipe madura pode operar self-hosted de forma eficiente; outra pode gastar mais em incidentes e manutenção do que economiza em assinatura.
Planeje também a saída. Confirme formatos de exportação, dependências, acesso aos dados, documentação e responsabilidades no encerramento ou mudança de modelo. Portabilidade precisa ser testada; não presuma migração automática, zero downtime ou compatibilidade total.
Cenários práticos: qual modelo tende a se encaixar?
Equipe pequena sem operação de infraestrutura
Cloud tende a reduzir a carga inicial. A equipe ainda precisa validar canais, integrações, governança e custo do plano, mas evita assumir diretamente vários componentes técnicos.
Empresa com política de infraestrutura própria
Self-hosted pode atender ao requisito, desde que exista equipe ou parceiro responsável por banco, filas, storage, segurança, observabilidade, backup e atualização. Controle deve vir acompanhado de processo.
Operação que já possui plataforma DevOps madura
Self-hosted pode aproveitar monitoramento, gestão de mudanças, backup e segurança existentes. Ainda é necessário validar capacidade, compatibilidade e custo incremental do Chatwoot.
Empresa que quer previsibilidade operacional
Não escolha apenas pelo rótulo Cloud ou self-hosted. Compare contratos e responsabilidades. Um serviço hospedado pode simplificar a infraestrutura; uma oferta self-hosted gerenciada por parceiro pode reunir outras camadas. A previsibilidade vem do escopo verificável.
Operação com muitas integrações internas
Self-hosted pode oferecer mais opções de rede e arquitetura, mas também aumenta a superfície a manter. Cloud pode continuar viável se APIs e padrões de segurança atenderem ao caso. Faça uma prova de conceito antes de assumir compatibilidade.
Onde o NooviChat entra nessa comparação
O NooviChat é uma distribuição privada/licenciada baseada em fork modificado do Chatwoot, comercializada por licença/acesso à imagem Docker. NooviChat não é open-source.
A licença comercial do NooviChat não é a Chatwoot Enterprise License, não implica afiliação ou endosso da Chatwoot Inc. e não substitui avisos, atribuições e licenças aplicáveis ao código de origem ou a componentes de terceiros.
O NooviChat entra na análise como uma alternativa licenciada para operações que querem avaliar uma experiência mais orientada ao mercado brasileiro. Isso não permite presumir infraestrutura gerenciada, suporte, backup, implantação, integrações ou qualquer recurso sem conferir a oferta vigente.
Antes de contratar, valide nos planos do NooviChat:
- modelo de implantação e infraestrutura;
- responsabilidades do cliente e do fornecedor;
- recursos disponíveis conforme licença e configuração;
- canais, integrações e provedores externos;
- atualização, backup e suporte;
- processo de exportação e continuidade.
Você também pode comparar a proposta de Chatwoot self-hosted no Brasil e o comparativo entre Chatwoot e NooviChat. Use essas páginas como início da diligência, não como substituto do escopo contratual.