Como usar Vultr para n8n e Evolution API em 2026: servidor por hora sem pagar o mês inteiro

Resposta curta: o que você terá pronto e o que precisa antes de começar

💡 Vai rodar Evolution API numa VPS? A gente comparou o preço real em cada provedor — com renovação e requisitos — em VPS para Evolution API.

Ao final deste roteiro, você terá uma checklist verificável para provisionar uma VPS, organizar uma stack persistente de n8n e Evolution API, proteger o acesso, testar um webhook por HTTPS e encerrar os recursos do experimento. Não é um relato de instalação pessoal: o Runzos não cronometrou este setup nem registra métricas próprias dele. Os passos foram montados a partir das documentações oficiais citadas.

Você precisa de uma conta Vultr, cartão ou forma de pagamento aceita pela plataforma, um domínio para HTTPS, acesso SSH por chave, noções de Linux e Docker Compose. O custo de referência para 24 horas no snapshot de 30 de julho de 2026 é US$ 0,33 no plano Regular de 2 GB. Esse valor não inclui câmbio, IOF aplicável, backup, snapshot ou itens adicionais.

Não há um tempo honesto único para concluir a instalação. Ele depende do domínio, DNS, firewall, versões das imagens e familiaridade com Linux. Planeje a Hora de Validação como uma janela com começo, teste e destruição definidos. Se a VPS ficará ligada 24 horas por dia, compare o custo total, o dólar, o IOF aplicável e o trabalho de operação.

Se esse é o seu cenário, comece pela oferta interna do Runzos: ver planos por hora da Vultr. Confira região, preço, cobrança adicional e qualquer elegibilidade de crédito diretamente no painel antes de provisionar.

O que você está subindo: VPS, Docker, n8n, Evolution, banco e Redis

É fácil tratar a instalação como dois containers e um comando. Essa simplificação costuma virar problema no primeiro reinício, no primeiro webhook perdido ou quando falta memória. A VPS é a infraestrutura. Docker Compose organiza os serviços. O n8n orquestra automações e pode ser comparado ao Make no nosso guia de n8n vs Make. A Evolution API integra fluxos de mensageria. PostgreSQL e Redis guardam ou coordenam estados necessários à operação.

O guia oficial do n8n para Docker Compose é a base certa para entender variáveis e persistência. Já a documentação da Evolution API para Docker trata a aplicação como parte de uma stack, não como um binário isolado.

A VPS de Três Camadas

Pense nessa VPS em três camadas. A primeira é o runtime: Ubuntu, Docker e Compose. A segunda é a integração: n8n, Evolution API, domínio, proxy reverso e webhooks. A terceira é a persistência: volumes, PostgreSQL, Redis, backups e chaves de criptografia.

Essa divisão evita um erro recorrente. Subir o container não é o mesmo que colocar a automação em produção. Sem volume persistente, uma recriação pode apagar dados. Sem proxy e HTTPS, você expõe serviços que não deveriam ficar abertos. Sem backup exportável, um snapshot isolado não resolve todo cenário de recuperação.

A escolha também preserva portabilidade. Docker Compose, imagens OCI, PostgreSQL, Redis, SSH e HTTPS podem ser levados para outro provedor. IP, snapshots, cobrança e API são específicos da plataforma. Por isso, manter o Compose versionado sem segredos e exportar dados reduz o custo de troca.

Por que 1 GB não é plano de produção

O plano de 1 GB pode servir para abrir um laboratório pequeno. Ele não é uma recomendação universal para n8n, Evolution API, banco e Redis no mesmo host. A soma de serviços cria disputa por memória e aumenta o risco de encerramento por falta de recursos.

O piso editorial mais prudente para um experimento com Docker é 2 GB. Isso não é uma promessa de capacidade para produção, nem um número oficial de RAM por container. É uma decisão prática: você precisa observar consumo real antes de colocar mais fluxos, instâncias ou workers na mesma VPS.

No queue mode, o n8n documenta Redis e recomenda PostgreSQL 13 ou superior. SQLite não é recomendado nesse modo. Essa é a linha entre um experimento simples e uma arquitetura que já precisa ser planejada para crescer.

Como escolher região São Paulo e plano de 2 GB sem comprar no escuro

A região deve seguir a rota do seu tráfego, não uma etiqueta de marketing. O registro interno da oferta Vultr aponta São Paulo entre as localidades disponíveis. Antes de criar a máquina, confirme a disponibilidade no seletor de regiões e avalie se seus usuários, seu operador ou seus webhooks realmente se beneficiam da proximidade.

Não prometa a si mesmo uma latência específica. A proximidade pode ajudar, mas só uma medição no caso real responde sobre rota, serviço externo e público. Se sua automação conversa com APIs globais, a localização da VPS é apenas uma parte do caminho.

Para o primeiro teste, escolha uma imagem Ubuntu LTS, configure chave SSH e evite operar apenas com login root e senha. Defina um limite de gasto no painel, anote a configuração e use nomes claros para VM, volume e snapshots. Isso parece burocracia até chegar a hora de descobrir o que ainda está cobrando.

O plano Regular de 2 GB é uma referência razoável para o piloto. O snapshot interno de 30 de julho de 2026 registrava 2 GB, 55 GB de disco e 1 TB de banda por US$ 10 mensais. Havia também uma referência High Frequency de 2 GB, 64 GB, por US$ 12 mensais. Esses valores são históricos do registro, não preços atuais garantidos. Revalide na página de preços da Vultr e no painel antes de criar o recurso.

Quanto custa testar por 24 horas, 7 dias ou 30 dias

Cobrança por hora não significa que um servidor permanente fica mais barato. Ela torna visível o custo de um experimento curto. Com 720 horas como aproximação de 30 dias, o snapshot de US$ 10 por mês equivale a cerca de US$ 0,013889 por hora. O plano de US$ 12 equivale a cerca de US$ 0,016667 por hora.

Essas contas usam o snapshot interno e servem para comparar durações. A fatura brasileira depende da cotação do cartão e do IOF aplicável. Use esta fórmula antes de decidir: USD consumido × cotação do cartão × (1 + IOF aplicável). Não há uma cotação ou alíquota fixa neste artigo porque ambas variam.

O preço de saída também entra na conta

O custo real não termina quando você para os containers. VM, IP, disco, snapshot e backup podem permanecer ativos, conforme o recurso e a política vigente. O registro interno da oferta indica que backups automáticos e snapshots são adicionais por servidor. Confirme valores, retenção e itens cobrados no painel.

A Hora de Validação só funciona com uma saída concreta. Crie a VPS, rode o fluxo, anote memória, CPU, disco, logs e custo. Faça backup ou exporte o que precisa ser preservado. Depois, destrua a VM e confira se volumes, IPs, snapshots e backups não ficaram para trás.

Esse procedimento evita o “teste barato” que vira uma cobrança esquecida por meses. Também produz um dado útil: sua automação realmente precisa de mais recursos ou o problema era configuração, webhook ou banco?

Tutorial documental: deploy, validação e saída do experimento

Siga a ordem abaixo. Onde há configuração de aplicação, use os exemplos e variáveis da documentação oficial em vez de copiar comandos genéricos de um post. Versões, imagens e parâmetros podem mudar.

Passo 1: delimite o experimento antes de criar a VPS

Crie a conta, defina um alerta de gasto e anote o objetivo do teste. Exemplo: validar se um webhook chega ao n8n por HTTPS e se os dados persistem após reiniciar os containers. Confirme a elegibilidade de qualquer crédito antes do provisionamento; este artigo não considera crédito como garantido.

Passo 2: escolha região, plano e acesso administrativo

No painel, confirme se São Paulo está disponível e escolha a região apenas se ela fizer sentido para sua rota. Crie uma VM com Ubuntu LTS, chave SSH e um usuário administrativo. Prefira acesso por chave e não use o login root como rotina. Registre o nome da VM, o plano e o horário de criação para comparar o consumo depois.

Passo 3: reduza a superfície exposta antes do Compose

Configure o firewall para restringir SSH e expor somente 80 e 443 pelo proxy quando isso for necessário. Não publique portas administrativas como 5678, do n8n, ou 8080, usada no exemplo da Evolution API, diretamente na internet sem proteção adequada.

Aviso de segurança: não cole tokens, senhas, QR codes, chaves privadas ou o arquivo .env em repositórios, logs públicos ou screenshots. Trate esses dados como segredos operacionais.

Passo 4: monte a stack persistente conforme as documentações oficiais

Crie diretórios e volumes persistentes para n8n, PostgreSQL, Redis e Evolution API. Guarde o .env fora do Git, defina credenciais fortes e configure N8N_ENCRYPTION_KEY conforme o guia de Docker Compose do n8n. Para a Evolution API, siga a documentação de instalação com Docker e seus requisitos de banco e Redis.

Fixe as versões das imagens escolhidas no Compose. Isso não impede atualizações, mas torna a mudança deliberada e reversível. Em queue mode, o n8n documenta Redis e recomenda PostgreSQL 13 ou superior; SQLite não é recomendado nesse modo.

Passo 5: coloque o tráfego atrás de HTTPS

Configure domínio, TLS e proxy reverso. A documentação da Evolution API traz um exemplo com Nginx para o upstream local. Adapte-o à sua topologia e confirme que o serviço administrativo não ficou público sem autenticação.

Passo 6: valide o resultado em vez de confiar no container iniciado

Com os serviços ativos, envie um evento de teste autorizado ao endpoint HTTPS e confirme três pontos: o proxy responde sem erro de certificado, o n8n recebe e processa o webhook esperado, e os dados necessários continuam disponíveis após um reinício controlado dos containers. Registre também uso de memória, disco e logs com docker stats e as ferramentas do sistema.

Passo 7: faça backup e execute a saída planejada

Antes de atualizar imagens ou encerrar o laboratório, exporte o banco e os fluxos que precisam sobreviver. Um snapshot pode ajudar a recuperar uma VM, mas não substitui backup exportável. Ao terminar, remova a VM e revise o painel para verificar volumes, IPs, snapshots e backups que possam continuar cobrando.

Aviso de destruição: confirme que seus exports podem ser restaurados antes de apagar recursos. Excluir uma VM sem verificar volumes e backups pode causar perda de dados ou cobrança residual.

Há também um limite de produto. A Evolution API não remove as obrigações de política da Meta. A página de enforcement de mensageria da Meta deixa claro que violações e usos proibidos podem trazer limitações. Infraestrutura própria não transforma automação em autorização para spam.

Problemas comuns e como investigar

Webhook não chega: confira DNS, certificado TLS, rota do proxy e se o firewall permite apenas o tráfego necessário. Teste com um evento autorizado e leia o log do proxy antes de alterar a aplicação.

Dados somem após reiniciar: confirme se os diretórios persistentes estão mapeados para os serviços corretos. Recriar um container não deveria apagar os dados que precisam sobreviver; se apaga, pare e revise volumes antes de continuar.

Memória ou disco cresce rápido: identifique o serviço que cresce com docker stats, revise logs e confirme se banco, Redis ou workers estão concentrados no mesmo host. Não conclua que a VPS falhou antes de observar o consumo.

Porta administrativa aparece aberta: remova a exposição pública, revise regras do firewall e deixe o acesso passar pelo proxy com HTTPS e autenticação quando aplicável.

Como medir e destruir o experimento sem deixar cobrança esquecida

Este guia não afirma um período pessoal de observação. Defina uma janela compatível com o fluxo que você precisa validar e registre versões das imagens, mudanças no Compose, uso de disco, logs, consumo de memória e chamadas de webhook. Essa observação não prova disponibilidade de longo prazo, mas transforma a decisão em evidência do seu ambiente.

Se a VM ficar sem memória, não conclua automaticamente que a Vultr é ruim. Primeiro identifique qual serviço cresceu, se o banco recebeu volume persistente, se logs estão ocupando disco e se há workers concorrendo pelos mesmos recursos. A infraestrutura pode estar correta e o dimensionamento, não.

Ao finalizar, exporte banco e fluxos que precisam sobreviver. Depois remova a VM e revise a conta. O objetivo do teste é tomar uma decisão com evidência operacional, não manter um ambiente sem dono porque ele “está funcionando”.

Vultr, Hostinger, Servla ou HostGator: escolha pela fricção certa

A melhor opção não é universal. Vultr é forte quando você quer uma VM crua, controle de Linux, teste por hora e possibilidade de automatizar provisionamento. Esse controle cobra uma contrapartida: você administra sistema, containers, segredos, atualizações e recuperação.

A Hostinger documenta um template “Ubuntu 24.04 with n8n” e o uso de n8n em Docker. Se seu objetivo é automatizar sem montar todo o ambiente do zero, veja a oferta Hostinger VPS n8n. Para quem prioriza PIX, boleto e suporte em português, a oferta Servla VPS n8n merece entrar na comparação.

Quando o problema central é a operação de WhatsApp e Evolution API, há também a oferta HostGator para Evolution API. Essas alternativas não eliminam a necessidade de segurança e backup. Elas podem reduzir a fricção de pagamento, suporte ou configuração inicial.

DigitalOcean continua sendo uma referência técnica para comparar VPS, mas não é a CTA principal deste guia. A decisão comercial do Runzos prioriza rotas com oferta compatível com o cenário brasileiro e com a monetização do conteúdo.

Se a comparação deixou claro que você prefere uma plataforma gerenciada, e não uma VPS crua, veja também como Vercel, Railway e Render se diferenciam de uma infraestrutura autogerenciada. Para fluxos n8n que chamam modelos de IA, o custo do servidor também não substitui o custo da API; nosso guia sobre a taxa de conveniência do OpenRouter ajuda a separar essas duas contas.

Para quem eu usaria e para quem eu não usaria

Eu usaria Vultr se precisasse validar uma automação self-hosted, tivesse conforto com Linux e Docker, aceitasse cobrar em dólar e estivesse disposto a apagar recursos após o teste. Também faz sentido para quem quer repetir a criação com API ou Terraform e manter uma arquitetura portátil.

Eu não escolheria Vultr como resposta automática para alguém que quer apenas ligar um n8n, pagar em reais e evitar administrar firewall, proxy, backup e atualizações. Nesse caso, a economia aparente de uma VM pode desaparecer no tempo de operação ou no câmbio.

A análise do Runzos não trata 2 GB como solução definitiva. Ela trata esse tamanho como início prudente para medir uma stack que reúne automação, integração e serviços de estado. Quando o uso cresce, separe responsabilidades, teste carga e redimensione com dados do seu ambiente.

FAQ

A Vultr tem região em São Paulo?

O registro interno da oferta Runzos indica uma região em São Paulo. Como disponibilidade e catálogo podem mudar, confirme no seletor de localidades da Vultr antes de provisionar. Região próxima não autoriza prometer latência específica sem teste.

2 GB bastam para n8n e Evolution API?

Dois GB são um piso editorial para um experimento monitorado com Docker. Não são garantia para produção, múltiplos workers ou qualquer volume de fluxos. Observe memória, CPU, disco e logs durante o piloto.

Quanto custa um teste de 24 horas?

No snapshot interno de 30 de julho de 2026, uma referência de US$ 10 por mês equivalia a cerca de US$ 0,33 em 24 horas. Esse cálculo não inclui conversão do cartão nem IOF aplicável. Confirme o preço vigente antes de criar a VPS.

Crédito Vultr ainda existe e expira?

O Runzos não confirma uma condição de crédito atual neste artigo. Promoções, elegibilidade e prazos mudam. Consulte as condições vigentes no painel da Vultr antes de colocar qualquer crédito no cálculo do seu experimento.

Posso deixar a porta 8080 exposta?

Não é uma boa prática para produção. A documentação da Evolution API inclui proxy reverso com Nginx. Restrinja o firewall e exponha apenas o necessário, normalmente 80 e 443 pelo proxy, com HTTPS e autenticação adequada.

Conclusão: teste com data de validade

A Vultr pode ser uma boa ferramenta para descobrir se a sua stack cabe em uma VPS, quanto ela consome e se uma região próxima ajuda na rota real. O diferencial não é a palavra “hora”. É a capacidade de conduzir um experimento disciplinado: criar, medir, exportar e destruir.

Se você quer esse controle e aceita operar uma VPS em dólar, comece comparando os recursos e condições na oferta Vultr VPS Cloud no Runzos. Confira o painel no dia, estabeleça um teto de gasto e só deixe o servidor contínuo depois de provar que ele atende ao seu fluxo.