Produção segura: VPS para Typebot

Resposta direta

Para rodar Typebot em produção, a escolha mais segura costuma ser uma VPS ou Cloud Server com pelo menos 2 vCPUs, 4 GB de RAM, 60 GB de SSD ou NVMe, Docker, PostgreSQL, proxy reverso com SSL e uma rotina de backup testada. Projetos pequenos podem começar com tudo no mesmo servidor, mas ambientes com muitos leads, webhooks, uploads ou integrações com WhatsApp, CRM e automação devem separar banco, storage e aplicação quando o volume crescer. O ponto central não é apenas instalar o Typebot. É garantir que os fluxos conversacionais continuem respondendo bem, que os dados fiquem persistidos, que os certificados renovem sem dor e que uma falha possa ser revertida em minutos, não em dias.

Resumo rápido

Hospedar Typebot em produção parece simples quando se olha apenas para o container da aplicação, mas o cenário muda quando entram banco de dados, arquivos enviados por usuários, integrações externas, domínios personalizados e picos de acesso em campanhas. Um chatbot usado em landing pages, suporte comercial ou pré-venda precisa responder rápido, registrar eventos corretamente e sobreviver a falhas previsíveis, como falta de espaço em disco ou expiração de certificado SSL.

• Configuração inicial recomendada: 2 vCPUs, 4 GB de RAM e 60 GB de SSD ou NVMe para um projeto pequeno ou médio.
• PostgreSQL deve ter volume persistente, backup diário e restauração testada, não apenas snapshot ocasional.
• Proxy reverso com Nginx, Caddy ou Traefik resolve SSL, múltiplos domínios e roteamento para containers.
• Uploads e assets precisam de estratégia clara, seja volume local bem protegido, seja storage compatível com S3.
• Redis pode ajudar em cenários com filas, cache ou maior concorrência, mas não substitui bom dimensionamento.
• Monitoramento básico de CPU, RAM, disco, logs e latência evita descobrir problemas pela reclamação do usuário.
• VPS no Brasil pode reduzir latência para público brasileiro, mas localização, storage e bandwidth variam por provedor e plano.

Na prática, a decisão passa por três perguntas. Quantas conversas simultâneas você espera? Quanto dado será gravado no PostgreSQL por mês? O Typebot será uma ferramenta interna ou parte crítica de aquisição de leads? A resposta muda bastante entre um funil com 300 acessos mensais e uma operação com anúncios pagos levando milhares de visitantes para formulários conversacionais todos os dias.

Por que o Typebot pede uma VPS bem planejada

Typebot é uma plataforma de criação de fluxos conversacionais, mas em produção ele se comporta como uma aplicação web completa. Há front-end, API, banco de dados, autenticação, publicação de bots, coleta de respostas, webhooks e, em muitos casos, upload de arquivos. Isso significa que uma hospedagem compartilhada tradicional raramente entrega o controle necessário. Você precisa definir variáveis de ambiente, expor portas internas com segurança, rodar containers, configurar domínio próprio e preservar dados entre deploys.

Typebot não é apenas uma página estática

Um erro comum é dimensionar o servidor como se o Typebot fosse só uma landing page. A página do bot até pode parecer leve para o visitante, mas cada interação pode gerar leitura e escrita no PostgreSQL, chamada externa para um CRM, webhook para automação, envio de e-mail ou consulta a uma API. Se o fluxo tem perguntas condicionais, campos personalizados e integrações em sequência, o gargalo pode aparecer no banco ou na rede antes de aparecer na CPU.

Imagine uma campanha com 1.000 visitantes em um dia e taxa de interação de 25%. Se cada conversa gerar 10 eventos persistidos, são 2.500 gravações, sem contar logs, sessões e possíveis integrações. Não é um volume absurdo, mas já exige disco confiável, conexões estáveis e backup. Se a mesma campanha roda junto com automações no n8n, faz sentido ler também o guia de VPS para n8n em produção, porque os cuidados com filas, variáveis de ambiente e banco persistente são parecidos.

Quando VPS vira Cloud Server

VPS tradicional e Cloud Server não são exatamente a mesma coisa. Uma VPS costuma ser uma máquina virtual em um host físico com recursos alocados. Cloud Server, ou cloud instance, normalmente traz provisionamento mais flexível, upgrades mais rápidos, imagens, snapshots e rede integrada a outros serviços. Para Typebot, os dois modelos podem funcionar. A diferença aparece quando você precisa aumentar RAM sem migração manual, criar ambiente de staging em minutos ou recuperar uma instância a partir de snapshot.

O ponto técnico é não escolher apenas pelo menor preço. Um plano barato com 1 GB de RAM pode até subir o container, mas tende a sofrer quando PostgreSQL, proxy reverso e aplicação concorrem por memória. Em produção, folga operacional importa. Um servidor sempre em 85% de RAM fica vulnerável a travamentos durante deploy, backup compactado ou pico de tráfego.

Arquitetura recomendada para Typebot em produção

A arquitetura mais comum para começar é simples: um servidor Linux, Docker Compose, containers do Typebot, PostgreSQL, proxy reverso e volumes persistentes. Essa abordagem é suficiente para um projeto interno, uma agência pequena ou um funil comercial com tráfego moderado. O segredo é tratar cada peça como componente de produção, não como um experimento abandonado em uma pasta do servidor.

Aplicação, banco e storage

Em uma instalação básica, você terá um container para a aplicação web do Typebot, um container para o builder ou serviços relacionados conforme a versão usada, um PostgreSQL com volume dedicado e um proxy reverso recebendo tráfego nas portas 80 e 443. O proxy encaminha requisições para a porta interna da aplicação, enquanto o banco permanece acessível apenas na rede Docker privada. Essa separação reduz exposição desnecessária.

Para arquivos, há duas opções frequentes. A primeira é usar volume local no próprio servidor, com backups regulares. Funciona bem para poucos uploads, como logos, imagens de marca e anexos ocasionais. A segunda é usar storage externo compatível com S3, melhor para equipes que recebem muitos arquivos de usuários ou precisam escalar a aplicação depois. Se o fluxo permite envio de comprovantes, currículos ou documentos, o volume pode crescer rápido. Cem arquivos de 5 MB por dia viram cerca de 15 GB por mês antes de compactação ou limpeza.

Separar serviços ou manter tudo no mesmo servidor

Manter tudo na mesma VPS reduz custo e complexidade. Para a maioria dos projetos iniciais, 2 vCPUs e 4 GB de RAM são suficientes para Typebot, PostgreSQL e proxy reverso, desde que o servidor não esteja rodando outras aplicações pesadas. Se você também hospeda n8n, Evolution API, Redis, WordPress e banco compartilhado na mesma máquina, a conta muda. Nesse caso, cada serviço compete por memória, conexões e I/O de disco.

Quando o Typebot vira parte de uma operação comercial, separar banco e aplicação melhora manutenção. Você pode atualizar o container sem tocar no PostgreSQL, criar replicas futuras, isolar backups e ajustar recursos com mais precisão. Em um desenho intermediário, a VPS principal roda Typebot e proxy, enquanto o PostgreSQL fica em outra instância ou serviço gerenciado. Isso aumenta custo, mas reduz risco. Para quem usa WhatsApp como canal de entrada, o artigo sobre VPS para Evolution API e automação com WhatsApp ajuda a pensar na separação entre chatbot, mensageria e automações.

CPU, RAM, disco e rede: como dimensionar sem chute

Dimensionar VPS para Typebot exige olhar para simultaneidade, tamanho do banco, integrações e rotina de manutenção. Não adianta calcular apenas visitantes mensais. Um site com 20 mil visitas espalhadas no mês pode ser mais leve que uma campanha de tráfego pago que concentra 300 acessos em meia hora. Chatbots têm esse comportamento: o pico costuma vir após disparo de mídia, anúncio, e-mail ou mensagem em massa.

Configuração mínima realista

Para produção pequena, considere 2 vCPUs, 4 GB de RAM e 60 GB de SSD. Essa configuração deixa espaço para sistema operacional, Docker, Typebot, PostgreSQL, proxy reverso, logs e backups locais temporários. Com 1 vCPU e 1 GB ou 2 GB de RAM, o ambiente pode funcionar em laboratório, mas fica apertado para atualização de containers, compactação de dump do banco ou aumento inesperado de tráfego. Se o servidor usa Ubuntu, Docker, PostgreSQL e Caddy, uma margem de 1 GB livre já faz diferença em momentos de pico.

Disco também merece atenção. SSD já atende muitos cenários, enquanto NVMe pode reduzir latência de I/O em bancos com muitas leituras e escritas pequenas. Isso não transforma uma aplicação mal configurada em rápida, mas ajuda quando o PostgreSQL registra muitas interações. Uma base com 5 GB de dados, índices e logs pode parecer pequena, porém backups diários retidos por 7 dias podem ocupar mais 35 GB se não houver compactação e envio externo. Por isso, 25 GB de disco total é pouco para produção real.

Quando subir para 4 vCPUs ou mais

Suba para 4 vCPUs e 8 GB de RAM quando houver múltiplos bots publicados, muitos domínios personalizados, integrações com APIs lentas ou tráfego simultâneo frequente. Um exemplo: uma agência gerencia 20 clientes, cada um com um funil ativo, e roda campanhas de captação em horários parecidos. Mesmo que cada bot seja simples, o conjunto aumenta conexões, logs e uso do banco.

A rede entra na conta quando o Typebot conversa com serviços externos. Webhooks para CRM, ferramentas de automação, gateways de pagamento e APIs de WhatsApp dependem de latência e disponibilidade. Para público brasileiro, uma VPS no Brasil pode melhorar tempo de resposta percebido, especialmente na abertura do bot e nas primeiras interações. Ainda assim, localização de datacenter, franquia de transferência e qualidade de rota são dados variáveis. Devem ser conferidos nas páginas oficiais dos provedores antes de qualquer decisão de compra.

Proxy reverso, SSL e deploy com Docker

Rodar Typebot sem proxy reverso em produção é pedir manutenção difícil. O proxy é a peça que recebe o tráfego público, aplica HTTPS, direciona cada domínio para o container correto e permite colocar outras aplicações na mesma VPS sem brigar por porta. Nginx, Caddy e Traefik são opções maduras, cada uma com um estilo diferente.

Nginx, Caddy ou Traefik

Nginx é previsível, muito documentado e comum em ambientes Linux. Ele exige configuração manual de server blocks e certificados, normalmente com Certbot. Caddy simplifica bastante o SSL, porque em muitos casos obtém e renova certificados automaticamente. Traefik combina bem com Docker, labels e múltiplos serviços dinâmicos, mas pede uma curva de aprendizado maior. Se você ainda está escolhendo a camada de entrada, o guia de VPS para reverse proxy com Nginx, Caddy e Traefik aprofunda essa decisão.

Em Typebot, o proxy precisa lidar com o domínio do builder, o domínio público dos bots e, em alguns casos, subdomínios por cliente. Um desenho comum usa app.seudominio.com para administração e bot.seudominio.com para fluxos publicados. Agências podem preferir cliente1.agencia.com.br, cliente2.agencia.com.br e assim por diante. O proxy evita expor portas internas e centraliza cabeçalhos como X-Forwarded-Proto, úteis para a aplicação entender que está atrás de HTTPS.

Exemplo de stack para produção

Um exemplo prático de deploy inclui Ubuntu 24.04 LTS, Docker Engine, Docker Compose, Caddy na porta 443, Typebot em rede Docker privada e PostgreSQL com volume em /var/lib/docker/volumes. A estrutura de diretórios pode ser simples: /opt/typebot/docker-compose.yml, /opt/typebot/.env, /opt/typebot/backups e /opt/typebot/caddy. O arquivo .env não deve ser versionado em repositório público e nunca deve expor chaves de API, segredos de autenticação ou credenciais de banco.

Comandos básicos de operação ajudam no dia a dia. docker compose ps mostra containers ativos. docker compose logs -f app ajuda a investigar erro de aplicação. docker stats indica consumo de CPU e memória em tempo real. Para atualizações, uma rotina segura inclui dump do PostgreSQL, pull das imagens, subida controlada e teste do builder e de um bot publicado. Em produção, não atualize antes de uma campanha importante. Faça a janela em horário de menor tráfego e tenha um plano de rollback.

Banco de dados, uploads e integrações externas

O PostgreSQL é o coração persistente de uma instalação Typebot. Se ele falha, você não perde apenas configuração técnica. Pode perder respostas de leads, histórico de conversas, estrutura dos fluxos e dados usados por integrações. Por isso, o banco não deve ser tratado como container descartável. Ele precisa de volume persistente, credenciais fortes, acesso restrito e rotina de backup que gere arquivos restauráveis.

PostgreSQL e política de conexão

Em uma VPS pequena, PostgreSQL e Typebot dividem os mesmos recursos. Isso funciona, mas exige disciplina. Defina limites razoáveis de memória, acompanhe conexões abertas e evite que outros serviços usem o mesmo banco sem necessidade. Se você roda n8n, Evolution API e Typebot no mesmo PostgreSQL, separar databases e usuários é o mínimo. Melhor ainda é separar instâncias quando o ambiente vira produção crítica.

Um problema comum aparece em integrações lentas. O usuário responde uma etapa, o Typebot chama um webhook externo e a resposta demora. Se muitos usuários fazem isso ao mesmo tempo, conexões podem ficar ocupadas por mais tempo. A solução não é apenas aumentar CPU. Pode ser necessário rever fluxo, usar timeout, simplificar chamadas externas ou enviar eventos para uma automação assíncrona. Em um funil de vendas, por exemplo, o Typebot pode coletar dados e disparar webhook para uma ferramenta externa, enquanto o processamento pesado fica em outro serviço.

Arquivos, webhooks e filas

Uploads precisam de regra clara. Se o bot recebe imagens, PDFs ou comprovantes, defina tamanho máximo por arquivo e política de retenção. Um limite de 10 MB parece pequeno, mas 1.000 uploads por mês já podem somar 10 GB. Se os arquivos são importantes para o negócio, faça backup externo. Se são temporários, automatize limpeza. O pior cenário é misturar arquivos críticos e descartáveis no mesmo volume sem documentação.

Webhooks também merecem cuidado. Configure endpoints com HTTPS, tokens ou cabeçalhos secretos, e logs suficientes para auditoria. Não coloque chaves diretamente em URLs compartilháveis. Se uma integração falha, o time precisa saber se o erro ocorreu no Typebot, no proxy, no serviço de destino ou na rede. Logs com horário, status HTTP e identificador do fluxo economizam horas de investigação. Para operações maiores, considere monitoramento de endpoints e alertas por e-mail, Slack ou outro canal usado pelo time.

Backups, segurança e operação diária

Backup bom é aquele que você já testou restaurar. Em Typebot, isso significa validar dump do PostgreSQL, volumes de arquivos, configurações do proxy, docker-compose.yml e variáveis de ambiente. Snapshot da VPS ajuda, mas não substitui backup lógico do banco. Um snapshot corrompido, antigo ou preso ao mesmo provedor pode não resolver uma exclusão acidental percebida dois dias depois.

Backup que dá para restaurar

Uma rotina básica pode combinar dump diário do PostgreSQL, compactação, retenção local curta e envio para storage externo. Por exemplo: manter 3 backups locais para recuperação rápida e 14 ou 30 cópias externas para incidentes mais sérios. O arquivo deve receber data no nome, como typebot-postgres-2026-08-21.sql.gz. Também faz sentido registrar o tamanho do dump e testar uma restauração mensal em ambiente separado.

A política muda conforme o risco. Um bot interno de pesquisa pode aceitar perda de algumas horas. Um bot de captação de leads pagos talvez precise de RPO menor, com backups mais frequentes ou replicação. RPO é quanto dado você aceita perder. RTO é quanto tempo você aceita ficar fora do ar. Para uma pequena agência, RPO de 24 horas e RTO de 4 horas pode ser aceitável. Para uma operação de vendas com mídia ativa, pode ser pouco.

Hardening básico da VPS

Segurança começa antes do Typebot. Use acesso SSH por chave, desative login root direto, mantenha firewall liberando apenas 22, 80 e 443 quando necessário, e atualize o sistema. Se SSH puder ficar em porta diferente ou restrito por IP, melhor. Instale fail2ban ou mecanismo equivalente para reduzir tentativas automatizadas. No Docker, não exponha PostgreSQL publicamente. Ele deve ficar acessível apenas pela rede interna da aplicação ou por túnel seguro em manutenção.

Também cuide das credenciais. Senhas de banco, secrets de autenticação, tokens de SMTP e chaves de storage devem ficar no .env com permissão restrita. Nada de colar segredo em print, issue pública ou repositório. Para auditoria simples, documente onde estão os arquivos, como fazer deploy, como restaurar backup e quem tem acesso. Parece burocracia, mas salva o projeto quando o responsável técnico está ausente.

Comparação prática de perfis de servidor

A tabela abaixo ajuda a transformar a escolha da VPS em decisão operacional. Os números são referências técnicas, não substituem teste de carga nem revisão dos planos oficiais de cada provedor. Preço, região, armazenamento, transferência e recursos como snapshots ou backups variam com o tempo e precisam ser conferidos antes da publicação ou contratação.

Perfil de uso	Recursos sugeridos	Arquitetura indicada	Quando faz sentido	Pontos de atenção
Projeto pequeno ou interno	2 vCPUs, 4 GB RAM, 60 GB SSD	Typebot, PostgreSQL e proxy na mesma VPS	MVP, bot interno, até alguns milhares de interações mensais	Monitorar RAM, disco e backups locais
Agência com vários clientes	4 vCPUs, 8 GB RAM, 100 GB SSD ou NVMe	Typebot e proxy na VPS, banco com volume dedicado ou instância separada	Múltiplos domínios, campanhas simultâneas, integrações com CRM	Padronizar deploy, logs e limites de upload
Produção crítica	4 a 8 vCPUs, 8 a 16 GB RAM, 160 GB NVMe ou banco gerenciado	Aplicação, banco, storage e backups separados	Leads pagos, operação comercial diária, alto volume de webhooks	Teste de restauração, alertas e plano de rollback
Stack de automação completa	4 vCPUs, 8 GB RAM no mínimo, mais se houver WhatsApp e n8n	Typebot, n8n, Evolution API e banco com isolamento por serviço	Funis conversacionais conectados a automações e mensageria	Evitar colocar tudo no mesmo banco e sem limites

Em provedores globais como DigitalOcean, Vultr, Linode/Akamai, AWS Lightsail, Hetzner e Contabo, confira região disponível, tipo de disco, limites de transferência e política de backup nas páginas oficiais. Em provedores com presença ou foco no Brasil, como LetsCloud, valide localidade, tipo de storage por plano, snapshots, backups e suporte antes de afirmar qualquer recurso específico. A vantagem potencial de datacenter no Brasil é latência menor para usuários locais, mas isso depende de rota, provedor de acesso e região efetiva da instância.

Se a aplicação for simples, a melhor escolha costuma ser uma VPS intermediária bem configurada, não o maior plano disponível. Se o tráfego cresce, upgrade vertical pode resolver a primeira fase. Depois, a evolução natural é separar banco, storage e serviços auxiliares. O que não funciona bem é começar sem backup, sem monitoramento e sem documentação, porque a economia inicial vira custo quando há falha.

Recomendações por perfil

Dev solo ou projeto interno

Para um dev solo, startup em validação ou equipe que quer usar Typebot internamente, uma VPS de 2 vCPUs, 4 GB de RAM e 60 GB de SSD é um ponto de partida equilibrado. Rode Typebot, PostgreSQL e Caddy ou Nginx no mesmo servidor, com Docker Compose e volumes persistentes. Configure backup diário do banco para um local externo, mesmo que seja um bucket simples. O objetivo é reduzir complexidade sem abrir mão do básico: HTTPS, firewall, SSH por chave, logs e restauração testada. Se o bot ainda tem baixo tráfego, gaste mais energia documentando deploy e backup do que tentando criar uma arquitetura distribuída cedo demais.

Agência com múltiplos clientes

Para agência, o problema não é apenas volume. É organização. Cada cliente pode ter domínio, identidade visual, webhooks, SMTP e regras de retenção diferentes. Nesse cenário, comece com 4 vCPUs, 8 GB de RAM e 100 GB de SSD ou NVMe, mantendo uma estrutura de diretórios padronizada e backups separados. Se vários clientes enviam arquivos, considere storage externo desde o início. Também vale criar ambiente de staging para testar fluxos antes de publicar. O proxy reverso precisa ser bem desenhado, porque múltiplos subdomínios e certificados aumentam a chance de erro operacional. Documente quem pode acessar o painel, como remover cliente antigo e como exportar dados quando necessário.

Produção com tráfego e integrações críticas

Para produção crítica, trate Typebot como parte do funil de receita. Use pelo menos 4 vCPUs e 8 GB de RAM, subindo para 8 vCPUs e 16 GB se houver picos, muitos webhooks ou stack de automação no mesmo ambiente. Separe PostgreSQL em instância própria ou serviço gerenciado quando o volume justificar. Use storage externo para uploads importantes, monitore disponibilidade do endpoint público e crie alertas para CPU, RAM, disco, erro 5xx e falha de backup. Antes de campanhas grandes, teste o fluxo completo: abertura do bot, envio de resposta, webhook, gravação no banco e consulta posterior. A pergunta certa não é se o Typebot sobe. É se ele continua confiável quando o tráfego chega de verdade.