Como dimensionar VPS para Temporal em produção

Resposta direta

Uma VPS para Temporal em produção deve começar, em um cenário pequeno, com 4 vCPUs, 8 GB de RAM, 100 GB de SSD ou NVMe e PostgreSQL separado por processo, mesmo que permaneça na mesma máquina. Essa configuração pode atender poucos namespaces, dezenas de workers externos e uma carga moderada de workflows, desde que exista monitoramento de CPU, memória, latência do banco e crescimento do histórico. Para cargas críticas, uma única VPS não oferece alta disponibilidade: a falha do host interrompe o frontend, o matching, o history service e o banco se todos estiverem concentrados nela.

O Temporal não executa o código das atividades dentro do cluster. Os workers da aplicação fazem polling das task queues e executam atividades em processos próprios. Isso muda o cálculo: um workflow que chama APIs e aguarda timers consome poucos recursos no cluster, enquanto atividades de vídeo, IA ou relatórios pesados pressionam as máquinas dos workers. Um projeto inicial pode manter o servidor Temporal em 4 vCPUs e 8 GB, mas reservar outras instâncias para workers com 2 a 8 vCPUs conforme a tarefa.

Uma VPS única funciona melhor como etapa controlada de adoção, ambiente interno ou produção de baixo impacto. Se a indisponibilidade de quinze minutos causa perda financeira ou quebra de SLA, o desenho precisa evoluir para banco redundante, múltiplas instâncias dos serviços Temporal e balanceamento. Snapshot do disco ajuda em incidentes, mas não substitui backup consistente do banco, teste de restauração e uma estratégia documentada de recuperação.

Quando uma única VPS funciona

Ela faz sentido quando o time aceita uma janela de manutenção, consegue restaurar o serviço e mede a carga antes de crescer. Um sistema interno que processa 20 mil workflows por dia, com atividades curtas em workers separados, é bem diferente de uma plataforma financeira com centenas de execuções por segundo.

O limite operacional

CPU disponível não resolve um banco saturado, assim como NVMe não corrige excesso de histórico ou workers mal configurados. A decisão deve considerar taxa de início de workflows, quantidade de eventos por execução, retenção, consultas de visibilidade e objetivo de recuperação.

Resumo rápido

• Comece com 4 vCPUs e 8 GB de RAM para uma produção pequena. Abaixo disso, o cluster, o banco e o sistema operacional disputam memória com facilidade. Uma configuração de 2 vCPUs e 4 GB serve melhor para desenvolvimento, prova de conceito ou homologação com pouca concorrência.
• Separe o consumo dos workers do consumo do Temporal Server. Workers executam atividades, integrações e lógica de aplicação. Se uma atividade usa 1 GB para gerar um PDF, essa memória pertence ao worker, não ao history service. Colocar tudo na mesma VPS esconde essa diferença e aumenta o risco de falta de memória.
• Use PostgreSQL ou MySQL com armazenamento persistente. Para uma instalação nova e pequena, PostgreSQL costuma ser uma escolha direta por sua operação conhecida e ferramentas maduras. Mantenha os schemas do Temporal sob migrações controladas e nunca trate um contêiner descartável como cópia principal dos dados.
• Reserve ao menos 100 GB de disco e monitore o crescimento. Retenção longa, workflows com milhares de eventos e consultas de visibilidade podem aumentar o volume rapidamente. Alertas em 70% e 85% de ocupação dão tempo para agir antes de o banco parar por falta de espaço.
• Não exponha PostgreSQL, métricas ou painéis administrativos à internet. A porta gRPC 7233 deve ser protegida por rede privada, firewall e, quando houver comunicação entre redes não confiáveis, TLS mútuo. A interface web também precisa de autenticação na camada de acesso.
• Planeje a saída da VPS única. O primeiro salto costuma ser mover o banco para um serviço gerenciado ou servidor dedicado. Depois, os serviços Temporal podem ganhar réplicas e balanceamento. O desenho final depende do impacto de indisponibilidade, não apenas do número de workflows.

Como a arquitetura do Temporal afeta a infraestrutura

Temporal é uma plataforma de execução durável. O cluster mantém estado, agenda timers, entrega tarefas e registra o histórico necessário para reconstruir a execução de um workflow. Ele não deve ser confundido com uma fila simples. RabbitMQ e NATS resolvem problemas de mensageria, enquanto Temporal coordena processos que podem durar segundos, dias ou meses. Quem ainda está escolhendo a camada de comunicação pode comparar esse desenho com uma VPS para RabbitMQ e filas de mensagens e com um Cloud Server para NATS e mensageria em tempo real.

Serviços do cluster

Uma implantação self-hosted distribui responsabilidades entre frontend, history, matching e worker service. O frontend recebe chamadas gRPC dos SDKs e ferramentas administrativas. O history service gerencia o estado dos workflows. O matching conecta task queues aos workers da aplicação. O worker service executa tarefas internas do próprio cluster, não as atividades de negócio escritas pelo time.

Em uma VPS pequena, esses componentes podem rodar como processos ou contêineres separados no mesmo host. Isso simplifica a instalação, mas não cria isolamento contra falha física. Um reboot interrompe todos os serviços. Em um ambiente maior, múltiplas réplicas podem ser distribuídas entre nós, apoiadas por banco persistente e descoberta de membros corretamente configurada.

Workers ficam fora do servidor Temporal

Considere três exemplos. Um workflow de aprovação de cadastro pode passar dois dias aguardando uma ação humana e quase não usar CPU durante a espera. Um workflow de cobrança que dispara 30 chamadas HTTP exige mais concorrência dos workers, mas continua leve no cluster se o histórico for controlado. Já uma atividade que converte vídeos pode ocupar 4 vCPUs e vários gigabytes de RAM por execução. Nesse último caso, escale os workers de mídia, não o frontend do Temporal.

Essa separação combina bem com arquiteturas descritas no conteúdo sobre VPS para APIs e microsserviços no Brasil. API, workers e cluster podem ter ciclos de escala diferentes. Misturar os três na mesma máquina é aceitável em laboratório, mas dificulta medir gargalos e transforma uma atividade defeituosa em risco para toda a orquestração.

CPU e RAM para cada estágio do projeto

O dimensionamento começa pela taxa de eventos, não pela quantidade bruta de workflows. Uma execução que espera um timer e termina com 15 eventos pesa menos do que outra que acumula 10 mil eventos, recebe sinais frequentes e faz consultas repetidas. Também entram na conta a retenção, o número de namespaces, a concorrência de polling e a carga de visibilidade.

Memória mínima realista

Para desenvolvimento, 2 vCPUs e 4 GB de RAM permitem executar Temporal, PostgreSQL e interface web com tráfego reduzido. É uma configuração apertada. Depois do sistema operacional e do banco, a margem para picos pode ficar abaixo de 2 GB. Swap de 2 a 4 GB evita encerramento abrupto em um pico curto, mas não deve mascarar pressão contínua de memória.

Em produção pequena, 4 vCPUs e 8 GB oferecem espaço mais saudável. Um ponto inicial pode reservar aproximadamente 2 a 3 GB para PostgreSQL, 3 a 4 GB para os serviços Temporal e o restante para sistema, cache e agentes de monitoramento. Não trate esses números como limites fixos. Meça RSS dos processos, page cache, latência de consultas e ocorrências de OOM.

Perfil	Cluster Temporal	Banco e disco	Workers da aplicação	Indicação operacional
Desenvolvimento	2 vCPUs, 4 GB RAM	40 a 60 GB SSD local	1 a 2 vCPUs no mesmo host	Testes funcionais e baixo volume
Produção pequena	4 vCPUs, 8 GB RAM	100 GB SSD ou NVMe	2 a 4 vCPUs separados	Serviço interno ou carga moderada
Produção em crescimento	8 vCPUs, 16 GB RAM	200 GB ou mais, banco separado	Pool escalável de 4 a 16 vCPUs	Vários serviços e maior concorrência
Produção crítica	Três ou mais nós dimensionados por teste	Banco redundante e backups externos	Pools separados por task queue	Alta disponibilidade e recuperação testada

Os números da tabela são pontos de partida, não benchmarks. Execute um teste com workflows parecidos com os reais. Por exemplo, inicie 50 mil execuções com 20 eventos cada, mantenha 200 atividades concorrentes nos workers e observe CPU, memória e latência do banco por pelo menos uma hora. Outro teste útil é aumentar a frequência de sinais e consultas, pois eles podem revelar gargalos que um workflow linear não mostra.

Quando a CPU permanece acima de 70% durante vários intervalos, investigue antes de ampliar a máquina. Consultas lentas, histórico excessivo e logging detalhado podem ser a causa. Se a memória cresce sem recuar, capture métricas por serviço e confirme se o problema está no cluster, no banco ou em workers colocados indevidamente no mesmo host.

Banco de dados, disco e rede

O banco é parte central da durabilidade do Temporal. Reiniciar um frontend é simples quando o estado persistente continua íntegro. Perder ou corromper o banco é um incidente de outra escala. PostgreSQL e MySQL são opções comuns para persistência, mas a versão suportada deve ser confirmada na documentação da versão do Temporal que será instalada. Atualizar o servidor sem conferir compatibilidade de schema pode bloquear a inicialização ou introduzir comportamento inesperado.

PostgreSQL ou MySQL

PostgreSQL é uma escolha prática quando o time já domina pg_dump, restauração, replicação e análise de consultas. Para uma VPS de 8 GB, não entregue toda a memória ao banco. Um ponto inicial conservador pode usar shared_buffers em torno de 1 a 2 GB, effective_cache_size entre 3 e 4 GB e conexões limitadas de acordo com os serviços ativos. Esses valores exigem ajuste após observar a carga.

O primeiro exemplo de crescimento é simples: o cluster permanece na VPS, mas o PostgreSQL vai para uma instância privada de 2 a 4 vCPUs e 8 GB. Isso reduz disputa por memória e permite reiniciar o Temporal sem afetar o banco. Em um segundo cenário, um banco gerenciado acrescenta backups e opções de redundância, embora disponibilidade, retenção e restauração dependam do produto contratado.

Latência e armazenamento persistente

Use volumes persistentes e monitore IOPS, latência de escrita e espaço livre. NVMe pode reduzir espera em cargas intensivas, mas não corrige índices inadequados ou retenção exagerada. Uma latência de armazenamento que sobe durante checkpoints, backup ou compactação pode aparecer como aumento na resposta do cluster. Defina alertas para disco acima de 70%, latência de consulta e conexões próximas do limite.

A comunicação entre workers e frontend usa gRPC, normalmente pela porta 7233. Colocar workers brasileiros diante de um cluster em outra região adiciona atraso a polling, comandos e atividades. Um RTT de 10 ms e outro de 150 ms produzem experiências diferentes, principalmente em workflows com muitas transições curtas. Para operações regionais, prefira rede privada e proximidade entre cluster, banco e workers. Bandwidth anunciado, localidade exata e tipo de disco variam por provedor e plano, por isso esses dados precisam ser confirmados antes da contratação.

Dois testes ajudam na decisão. Rode fio em um volume vazio de homologação, nunca no banco em produção, para entender latência de escrita. Depois, use pg_stat_statements para localizar consultas que acumulam tempo. Medir os dois lados evita culpar o disco por um problema de consulta ou aumentar RAM quando o gargalo real está na rede.

Como montar o ambiente de produção

Docker Compose acelera uma prova de conceito, mas não oferece sozinho alta disponibilidade, política de atualização ou recuperação. Em uma VPS única, ele ainda pode ser usado com disciplina: versões fixadas, volumes persistentes, limites de recursos, health checks e arquivos de configuração sob controle de versão. Evite a tag latest, pois uma recriação do contêiner pode introduzir uma versão não testada.

Separação de processos

Mantenha ao menos quatro grupos lógicos: Temporal Server, PostgreSQL, interface web e observabilidade. Os workers de negócio devem ficar em outro host quando executarem atividades pesadas. Uma divisão inicial em uma máquina de 8 GB pode limitar o banco a 3 GB, o conjunto Temporal a 4 GB e reservar cerca de 1 GB para sistema e monitoramento. Esses limites devem ser ajustados se houver reinicializações por falta de memória.

Um diretório simples pode separar dados e configuração:

/opt/temporal/config
/opt/temporal/dynamicconfig
/var/lib/postgresql
/var/lib/prometheus
/var/backups/temporal

Permissões devem impedir leitura por usuários sem função operacional. Variáveis sensíveis não pertencem ao repositório. Use arquivos protegidos, secrets do orquestrador ou um gerenciador de segredos. Nunca grave senha do banco em imagem, script público ou exemplo compartilhado.

Portas, proxy e configuração inicial

No firewall, aceite SSH apenas de IPs administrativos ou por VPN. A porta 7233 deve ficar na rede privada ou restrita aos workers conhecidos. PostgreSQL, em geral na porta 5432, não deve receber conexões públicas. A interface web costuma usar uma porta HTTP própria, frequentemente 8080 conforme a implantação, e pode ser publicada atrás de Nginx ou Caddy com TLS e autenticação.

Depois de iniciar o ambiente, valide o cluster com uma ferramenta compatível com a versão instalada:

temporal operator cluster health --address temporal.internal:7233
temporal namespace list --address temporal.internal:7233

Crie namespaces com retenção adequada ao negócio. Sete dias podem bastar para processos curtos, enquanto auditoria ou investigação pode exigir mais tempo e mais disco. Antes de liberar clientes, execute três ensaios: um workflow curto, outro com timer de algumas horas e um terceiro interrompido durante uma atividade. Reinicie o worker e confirme que a execução continua a partir do histórico, sem repetir efeitos externos que não sejam idempotentes.

Em upgrades, leia as notas de versão, faça backup consistente, aplique migrações conforme a documentação e atualize em homologação primeiro. Saltos grandes de versão pedem ainda mais cautela. O rollback do binário não garante rollback automático de schema.

Segurança, backup e operação sem surpresas

Um cluster Temporal controla processos de negócio, portanto seu endpoint gRPC não deve ser tratado como uma API pública comum. Restrinja a rede com firewall, VPN ou sub-redes privadas. Quando workers atravessam redes diferentes, considere TLS mútuo para autenticar cliente e servidor. A autorização precisa acompanhar namespaces e responsabilidades do time, evitando que qualquer serviço possa iniciar, consultar ou encerrar workflows de todos os domínios.

Proteção do plano de controle

Execute processos sem usuário root sempre que a imagem e a instalação permitirem. Atualize o sistema operacional, desative login SSH por senha e use chaves protegidas. Fail2ban pode reduzir tentativas automatizadas, mas não substitui uma política de rede. A interface web merece proteção própria, pois expõe nomes de workflows, entradas, resultados e histórico operacional.

Backup precisa ser consistente com o banco. Em PostgreSQL, uma estratégia pode combinar backup completo, arquivamento de WAL e cópia externa criptografada. Um snapshot do volume feito sem coordenação pode capturar dados em estado inadequado ou não atender ao ponto de recuperação desejado. Defina RPO e RTO. Um serviço interno pode aceitar RPO de 24 horas e RTO de quatro horas. Uma operação de pagamentos talvez exija RPO de minutos e recuperação muito mais rápida.

Faça um teste trimestral em ambiente isolado: restaure o banco, suba a mesma versão compatível do Temporal, valide namespaces e consulte workflows conhecidos. O backup só está comprovado depois desse exercício.

Métricas e troubleshooting

Monitore CPU, memória, disco, reinicializações, latência do banco, tamanho das task queues e atrasos de processamento. Prometheus e Grafana podem coletar e apresentar métricas expostas pela implantação, desde que os endpoints não fiquem públicos. Registre também métricas dos workers, como atividades iniciadas, concluídas, com timeout e tentativas por task queue.

Se workflows ficam parados, siga uma ordem. Primeiro, confirme que há workers fazendo polling na task queue correta. Depois, verifique conectividade com a porta 7233 e compatibilidade de namespace. Em seguida, observe backlog, timeouts e erros de aplicação. Se todo o cluster estiver lento, examine banco, CPU e disco. Três exemplos comuns são nome divergente de task queue, worker sem capacidade de concorrência e atividade não idempotente repetindo chamadas após timeout.

Use Continue-As-New em execuções que acumulam histórico muito longo. Ajuste retries com intervalos coerentes e não repita indefinidamente erros permanentes, como dados inválidos. Essas decisões reduzem pressão no cluster e evitam que um incidente externo produza milhões de tentativas inúteis.

Recomendações por perfil

A melhor infraestrutura depende do custo da interrupção e da experiência operacional disponível. Não existe uma quantidade de RAM que transforme um único host em alta disponibilidade. A recomendação abaixo separa ambientes por responsabilidade e apresenta um caminho de evolução sem exigir um cluster complexo no primeiro dia.

Desenvolvedor solo e homologação

Use 2 vCPUs, 4 GB de RAM e 40 a 60 GB de SSD. Temporal, PostgreSQL e interface web podem compartilhar a máquina, com swap pequena e alertas de ocupação. Limite a concorrência dos workers e evite atividades que consumam muita memória no mesmo host. Essa configuração atende desenvolvimento, demonstrações e testes de integração, mas não deve sustentar um processo cujo atraso afete clientes.

Um exemplo é uma automação interna com 500 workflows por dia, retenção de três dias e atividades HTTP curtas. Faça backup diário do PostgreSQL e teste a restauração antes de considerar a migração para produção. Se o sistema começar a usar mais de 70% da memória por períodos longos, passe para 8 GB antes de adicionar funcionalidades.

Time pequeno com serviço em produção

Adote 4 vCPUs, 8 GB de RAM e pelo menos 100 GB de SSD ou NVMe. Execute workers em outra instância, especialmente quando processarem arquivos, IA, relatórios ou integrações lentas. Proteja o gRPC por rede privada, publique a interface web atrás de autenticação e envie backups criptografados para armazenamento externo.

Um SaaS pequeno pode iniciar 20 mil workflows diários, manter 100 a 300 atividades concorrentes em workers separados e usar retenção de sete dias. Teste essa carga em homologação, incluindo sinais e retries. Se o banco disputar memória com o history service, mova PostgreSQL para uma instância de 2 a 4 vCPUs e 8 GB. Essa costuma ser uma evolução mais previsível do que apenas dobrar a VPS principal.

Produção crítica ou vários microsserviços

Evite depender de uma VPS única. Distribua serviços Temporal em múltiplos nós ou use uma plataforma de orquestração bem operada, mantenha banco redundante e coloque um balanceador diante dos frontends. Separe pools de workers por task queue e tipo de carga. Atividades de cobrança não devem competir por CPU com processamento de vídeo ou geração de relatórios.

Comece testes com nós de 4 a 8 vCPUs e 8 a 16 GB, depois ajuste com métricas reais. Simule perda de um nó, indisponibilidade do banco, fila acumulada e restauração completa. Para um ecossistema com dez microsserviços, milhões de eventos diários e exigência de continuidade, capacidade de failover e procedimentos de incidente pesam mais do que escolher o maior plano disponível.

Ao avaliar provedores, confirme região, armazenamento, limites de tráfego, snapshots, backup e SLA nas páginas oficiais. LetsCloud, DigitalOcean, Vultr, Akamai, AWS e outros podem atender partes desse desenho, mas recursos variam por plano e localidade. Nenhum deles deve ser considerado superior sem benchmark reproduzível, análise de suporte e validação da arquitetura específica.