← Voltar ao Blog
ChatwootSelf-hostedDevOpsGo-liveBackupMonitoramentoNooviChat

Chatwoot self-hosted em produção: checklist de go-live

11 min de leitura

Use este checklist técnico para validar arquitetura, backup, segurança, monitoramento e canais antes de liberar o Chatwoot self-hosted em produção.

Colocar o Chatwoot self-hosted em produção exige mais do que abrir a tela de login. Antes de receber conversas reais, a equipe precisa validar aplicação, workers, PostgreSQL, Redis, armazenamento de anexos, domínio, TLS, email, backups, monitoramento, atualizações e canais.

Este guia parte de uma premissa clara: a empresa já escolheu o modelo self-hosted. O objetivo não é decidir se Chatwoot vale a pena, comparar edições ou calcular preço. É transformar o pré-go-live em um processo verificável, com responsável, evidência e critério de aceite.

Quando o Chatwoot self-hosted está pronto para produção?

Uma instalação está pronta quando os componentes críticos funcionam juntos, os dados podem ser recuperados, os responsáveis sabem agir em falhas e os canais contratados passaram por testes de ponta a ponta.

O acesso ao painel é apenas um dos sinais. O go-live também precisa provar que:

  • aplicação web e workers processam tarefas sem filas travadas;
  • PostgreSQL, Redis e anexos possuem persistência adequada;
  • domínio, HTTPS, WebSockets e proxy reverso estão corretos;
  • email transacional e inbox de email, quando usados, enviam e recebem;
  • backups existem e um restore já foi executado em ambiente isolado;
  • logs, métricas e alertas chegam a alguém capaz de responder;
  • existe procedimento de atualização, migração e rollback;
  • cada canal funciona com credenciais e políticas válidas;
  • a equipe registrou uma decisão formal de go ou no-go.

Se um item crítico não tem responsável ou evidência, ele ainda não foi validado.

O que existe por trás de uma instalação self-hosted

A arquitetura oficial do Chatwoot descreve servidores web, workers em segundo plano, PostgreSQL, Redis, serviço de email e object storage. Dependendo do método de implantação, esses componentes podem estar na mesma máquina, em serviços separados ou dentro de um cluster.

Docker Compose, Linux VM e Kubernetes com Helm são caminhos documentados, mas o método de instalação não elimina a responsabilidade operacional. Em produção, alguém continua cuidando de:

  • sistema operacional ou cluster;
  • aplicação e workers;
  • banco de dados e cache/filas;
  • storage de anexos;
  • rede, DNS, proxy e certificados;
  • secrets e credenciais;
  • backup e recuperação;
  • monitoramento, atualização e incidentes.

Use a documentação da versão adotada como fonte primária. Exemplos em páginas, imagens ou arquivos apontados para branches mutáveis podem mudar. Registre a versão implantada e evite depender silenciosamente de tags como latest em produção.