Qual é a configuração mínima de VPS para uma API Go em produção?

Para uma API Go pequena em produção, o mínimo prático costuma ser 2 vCPUs, 2 GB de RAM e 40 GB de SSD. Essa configuração atende APIs internas, webhooks leves e MVPs com tráfego moderado, principalmente quando o banco de dados está fora da VPS. Se PostgreSQL, MySQL ou Redis rodarem no mesmo servidor, 4 GB de RAM é uma escolha mais segura. A aplicação Go pode consumir pouca memória, mas proxy, logs, monitoramento, conexões de banco e tarefas agendadas também entram na conta.

Go precisa de menos RAM que Node.js, Java ou PHP?

Em muitos cenários, aplicações Go usam menos memória que stacks com runtimes mais pesados, mas isso depende do código, das bibliotecas e da carga. Um binário Go simples pode ficar abaixo de 200 MB em repouso, enquanto uma aplicação com cache, filas, buffers grandes e muitas conexões pode consumir bem mais. A comparação isolada entre linguagens engana. O que define a VPS é o conjunto completo: aplicação, banco, proxy, workers, logs, monitoramento, sistema operacional e margem para picos.

Vale a pena usar Docker para aplicações Go em VPS?

Docker vale a pena quando você precisa padronizar ambiente, rodar múltiplos serviços ou facilitar deploy por CI. Para uma única API Go, systemd com binário compilado pode ser mais simples e consumir menos recursos operacionais. Em times pequenos, Docker Compose ajuda a organizar API, worker, Redis e proxy, desde que existam limites de CPU, memória e rotação de logs. O ponto central é evitar complexidade desnecessária. Kubernetes em uma única VPS raramente compensa para projetos pequenos.

Datacenter no Brasil faz diferença para aplicações Go?

Faz diferença quando o usuário ou sistema consumidor está no Brasil e a API responde de forma síncrona. A localização pode reduzir latência de rede antes mesmo de a aplicação processar a requisição. Isso impacta painéis, SaaS B2B, gateways, webhooks e sistemas que fazem várias chamadas em sequência. Em jobs assíncronos ou integrações com banco fora do país, o ganho pode ser menor. O ideal é medir com ping, mtr, curl e testes reais a partir das regiões onde seus usuários estão.

Quando devo separar banco de dados e aplicação Go em servidores diferentes?

Separe quando o banco começar a disputar CPU, RAM ou disco com a aplicação, quando o backup ficar crítico ou quando a restauração precisar ser mais previsível. Em MVPs, banco e API na mesma VPS podem funcionar bem, principalmente com 4 GB ou 8 GB de RAM. Em produção com clientes pagantes, filas, relatórios ou crescimento contínuo, separar o banco reduz risco operacional. Outra razão forte é escalabilidade: você pode aumentar aplicação e banco de formas diferentes, sem mover tudo ao mesmo tempo.

Como saber se minha VPS Go está subdimensionada?

Os sinais mais comuns são latência subindo em horário de pico, aumento de erros 5xx, CPU acima de 80 por cento por longos períodos, uso de swap, disco perto de lotar, banco com conexões saturadas e workers acumulando fila. Em Go, monitore também goroutines, tempo de resposta por rota, alocações e erros externos. Antes de fazer upgrade, identifique o gargalo. Às vezes 2 GB a mais de RAM resolvem swap. Em outros casos, o problema está em query lenta, pool mal configurado ou disco com I/O insuficiente.

Como escolher VPS para aplicações Go no Brasil

Resposta direta

Para rodar aplicações Go em produção no Brasil, uma VPS inicial costuma funcionar bem com 2 vCPUs, 2 GB a 4 GB de RAM, 40 GB a 80 GB de SSD ou NVMe e datacenter próximo do público, de preferência no Brasil quando a latência pesa na experiência. Go é eficiente em CPU e memória, mas APIs com banco de dados, filas, cache, TLS, logs e workers concorrentes precisam de folga operacional. Para uma API pequena, 2 vCPUs e 2 GB de RAM podem bastar. Para uma API com workers, filas e picos previsíveis, 4 vCPUs e 8 GB de RAM dão margem melhor. A escolha deve considerar tráfego, tempo médio de resposta, conexões simultâneas, I/O de disco, rede, backup, monitoramento e facilidade de upgrade.

Resumo rápido

Go costuma consumir menos memória que runtimes mais pesados, mas isso não dispensa dimensionamento cuidadoso.
Para produção básica, comece com 2 vCPUs, 2 GB a 4 GB de RAM e 40 GB de disco SSD.
APIs públicas, webhooks e serviços com picos ficam mais seguros com 4 vCPUs e 8 GB de RAM.
Datacenter no Brasil pode reduzir latência para usuários brasileiros, principalmente em APIs síncronas.
NVMe ajuda quando há logs intensos, filas locais, uploads, bancos no mesmo servidor ou muita leitura e escrita.
systemd é suficiente para muitos binários Go, enquanto Docker facilita padronização e deploy em times.
Backup, métricas, alertas e plano de rollback são parte do servidor, não tarefas para depois.

Por que Go combina bem com VPS no Brasil

Go é uma linguagem muito confortável para VPS porque o resultado final costuma ser um binário único, previsível e simples de distribuir. Em muitos projetos, você compila a aplicação em uma máquina de CI, envia o binário para o servidor, reinicia um serviço e pronto. Não há necessidade de manter um runtime pesado no servidor, nem instalar dezenas de extensões para cada deploy. Isso reduz atrito para times pequenos e facilita a operação em VPS tradicionais, Cloud Servers e instâncias cloud.

Essa simplicidade, no entanto, não significa que qualquer plano barato resolve. Uma API Go com 20 rotas internas e 50 requisições por minuto é uma coisa. Um serviço público com autenticação JWT, chamadas a banco PostgreSQL, Redis, webhooks, compressão gzip e logs estruturados é outra. A aplicação pode continuar usando pouca memória, mas o ecossistema em volta cresce rápido. Nginx ou Caddy para TLS, banco de dados, agente de monitoramento, coletor de logs e processos de worker disputam CPU, RAM, disco e rede.

Go entrega binários simples, mas não elimina operação

Um exemplo comum é uma API de pedidos escrita em Go com Gin, Echo, Fiber ou net/http puro. O binário pode consumir 80 MB a 250 MB de RAM em repouso, dependendo das bibliotecas e caches internos. Quando entram 200 conexões simultâneas, consultas SQL lentas e serialização de JSON grande, a pressão muda. O gargalo talvez não esteja no Go, mas no banco, no limite de conexões, no pool HTTP ou na latência de rede.

Quando a localização do servidor muda a experiência

Para público brasileiro, a localização pesa mais em APIs síncronas, painéis administrativos, gateways próprios, SaaS B2B e integrações que precisam responder rápido. Uma ida e volta de rede para os Estados Unidos pode adicionar dezenas ou centenas de milissegundos antes mesmo da aplicação processar a requisição. Em serviços internos ou jobs assíncronos, isso incomoda menos. Se o seu projeto depende de baixa latência, o artigo sobre VPS para baixa latência no Brasil aprofunda esse recorte com foco em rede, rota e datacenter.

Como dimensionar CPU, RAM, disco e rede

Dimensionar VPS para aplicações Go no Brasil começa separando o que é carga de aplicação, carga de banco e carga operacional. Go lida muito bem com concorrência, mas goroutines não tornam CPU infinita. Uma API que faz cálculo pesado, criptografia frequente, compressão de respostas grandes ou manipulação de imagens pode consumir CPU de forma intensa. Já uma API CRUD típica, com a maior parte do tempo esperando banco de dados ou serviços externos, precisa mais de boa rede, pool de conexões bem configurado e memória suficiente para evitar swap.

CPU para APIs concorrentes

Como ponto de partida, 2 vCPUs atendem MVPs, APIs internas e projetos com tráfego moderado. Pense em algo como 50 a 150 requisições por minuto, respostas pequenas, banco externo e poucos workers. Para uma API pública com picos, webhooks de pagamento e tarefas de background, 4 vCPUs dão margem melhor. Em Go, configure limites conscientemente. O runtime usa GOMAXPROCS com base nos CPUs disponíveis, mas containers e limites de cgroup podem mudar esse comportamento. Em Docker, teste a aplicação com os mesmos limites que existirão em produção.

RAM para processos, cache e workers

A RAM mínima razoável para produção é 2 GB, mas 4 GB costuma ser o primeiro ponto confortável. Um servidor com Caddy ou Nginx, aplicação Go, agente de métricas, logs e pequenas rotinas de backup já consome uma parte fixa. Se o banco de dados estiver na mesma VPS, suba o patamar. PostgreSQL ou MySQL no mesmo host com 2 GB de RAM funciona em projetos pequenos, mas a margem para picos fica curta. Workers também contam. Dez workers processando filas, cada um mantendo conexões e buffers, podem dobrar o consumo real.

Disco e rede em aplicações reais

Disco SSD é suficiente para muitas APIs. NVMe faz diferença quando há muito I/O local, como banco de dados no mesmo servidor, gravação de logs em alto volume, filas persistentes, uploads, cache em disco ou processamento de arquivos. Para produção, 40 GB é o mínimo prático, 80 GB é mais confortável e 160 GB ou mais entra quando há arquivos de usuário ou retenção de logs. A rede também precisa entrar na conta. APIs com respostas JSON pequenas raramente esgotam banda, mas uploads, webhooks em massa e integrações com arquivos mudam o perfil. Para aprofundar a lógica de recursos, veja também o guia sobre como escolher CPU, RAM e NVMe, que ajuda a traduzir sintomas de gargalo em upgrades reais.

Arquitetura de produção para APIs e workers em Go

A arquitetura mais segura para começar não é necessariamente a mais complexa. Em muitos casos, uma VPS bem configurada com reverse proxy, aplicação Go, logs, firewall e backup já coloca uma API pequena em produção com previsibilidade. O erro comum é misturar tudo sem limites: API, worker, banco, Redis, cron, painel, monitoramento e upload de arquivos competindo no mesmo servidor sem nenhuma reserva de CPU ou memória. Funciona no lançamento, falha no primeiro pico.

Separar API, worker e banco de dados

Mesmo quando tudo roda na mesma VPS, trate cada componente como serviço separado. A API deve responder rápido e não pode travar porque um job de importação consumiu toda a CPU. Workers devem ter concorrência configurável, por exemplo WORKER_CONCURRENCY=4 em um plano com 4 vCPUs, ajustando para baixo se o banco começar a saturar. O banco de dados precisa de limites próprios de conexão. Uma API Go com pool de 100 conexões pode derrubar um PostgreSQL pequeno sem que a CPU da aplicação pareça alta.

Em produção simples, use um desenho assim: Caddy ou Nginx na porta 443, aplicação Go ouvindo em 127.0.0.1:8080, worker como serviço systemd separado, PostgreSQL gerenciado fora da VPS ou instalado localmente em projetos menores, Redis opcional para cache e filas leves. Essa divisão deixa logs mais claros, reinícios menos arriscados e troubleshooting mais rápido.

Exemplo de topologia inicial

Imagine um SaaS B2B com 1.500 usuários cadastrados, 150 usuários ativos por dia e picos de 20 requisições por segundo em horário comercial. Uma VPS com 4 vCPUs, 8 GB de RAM e 80 GB de SSD ou NVMe é um começo realista se o banco estiver no mesmo servidor. Se o banco for gerenciado externamente, 2 vCPUs e 4 GB podem segurar o começo, desde que haja métricas e opção de upgrade rápido.

Para APIs e microsserviços, o raciocínio muda quando há vários serviços pequenos. Três binários Go consumindo 150 MB cada parecem leves, mas cada um tem conexões, logs, health checks e deploy próprio. O conteúdo sobre VPS para APIs e microsserviços no Brasil complementa essa decisão quando o problema deixa de ser uma única API e vira um conjunto de serviços conversando entre si.

Deploy, systemd, Docker e configuração segura

O deploy de aplicações Go em VPS pode ser muito simples. Um caminho direto é compilar para Linux, enviar o binário, criar um usuário sem privilégios, configurar systemd e colocar Nginx ou Caddy na frente para TLS. Esse modelo tem menos partes móveis que Docker e funciona muito bem para APIs únicas. O segredo é padronizar o processo, não depender de comandos manuais esquecidos em um terminal.

Binário Go com systemd

Uma configuração comum usa /opt/minha-api/app como binário, /etc/minha-api/env para variáveis de ambiente e um serviço systemd rodando com usuário dedicado. O serviço pode definir restart automático, limite de arquivos abertos e diretório de trabalho. Em produção, evite rodar como root. Use User=minhaapi, Restart=always, RestartSec=5 e logs pelo journald ou por um coletor externo. Para configuração sensível, nunca coloque chaves no repositório. Variáveis como DATABASE_URL, JWT_SECRET e tokens de terceiros devem ficar em arquivo protegido, secret manager ou variáveis do ambiente de deploy.

Um fluxo simples de deploy seria: compilar com GOOS=linux GOARCH=amd64 go build, enviar o binário por pipeline, validar checksum, trocar symlink de release, rodar migrações controladas e reiniciar o serviço. Em projetos pequenos, isso já reduz bastante o risco de deploy quebrado. Para rollback, mantenha pelo menos a versão anterior no servidor.

Docker quando o projeto tem dependências

Docker entra bem quando o time quer ambiente replicável, quando há múltiplos serviços ou quando a aplicação depende de sidecars. Um Dockerfile multi-stage compila o binário em uma imagem Go e copia apenas o executável para uma imagem final menor, como distroless ou Alpine quando compatível. Isso reduz superfície de ataque e deixa o deploy mais previsível. Ainda assim, Docker não elimina operação. Você precisa limitar CPU e memória, cuidar de logs, reiniciar containers, atualizar imagens base e proteger portas.

Em VPS pequena, evite subir um stack exagerado com Kubernetes, service mesh e banco pesado no mesmo host. Para uma única aplicação Go, Docker Compose com API, worker, Redis e Nginx já é suficiente em muitos casos. Kubernetes só faz sentido quando há equipe, múltiplos nós, automação madura e necessidade real de orquestração.

Tabela prática de perfis de VPS para Go

A tabela abaixo resume perfis de dimensionamento para aplicações Go em produção. Ela não substitui teste de carga, mas ajuda a sair do chute. Use os números como ponto de partida e ajuste com métricas reais. Um endpoint que responde em 20 ms com cache tem comportamento muito diferente de um endpoint que consulta três tabelas grandes, chama um serviço externo e gera PDF.

Perfil de uso	Configuração sugerida	Cenário típico	Atenção principal	Próximo upgrade provável
API pequena ou MVP	2 vCPUs, 2 GB RAM, 40 GB SSD	API interna, webhook leve, painel administrativo com poucos usuários	Evitar banco pesado no mesmo servidor e monitorar swap	Subir para 4 GB RAM antes de adicionar workers
API pública com workers	4 vCPUs, 8 GB RAM, 80 GB SSD ou NVMe	SaaS pequeno, filas, jobs, integrações de pagamento, 10 a 50 req/s em pico	Pool de conexões, concorrência de workers e logs	Separar banco ou aumentar CPU para picos
Serviço com I/O intenso	4 a 8 vCPUs, 8 GB a 16 GB RAM, 160 GB NVMe	Uploads, relatórios, filas persistentes, banco local, processamento de arquivos	Disco, retenção de logs, backup e throughput de rede	Banco gerenciado, storage separado ou servidor dedicado
Microsserviços pequenos	4 vCPUs, 8 GB RAM, 80 GB SSD	3 a 6 binários Go, reverse proxy, Redis e observabilidade básica	Overhead operacional e deploy coordenado	Separar serviços críticos em outra VPS

Na prática, o perfil mais comum para produção inicial fica entre a primeira e a segunda linha. Se a aplicação está em fase de validação, 2 vCPUs e 4 GB de RAM dão bom equilíbrio. Se já existe cliente pagando, workers ativos e integração com meios de pagamento, 4 vCPUs e 8 GB reduzem o risco de saturar por economia pequena.

Também olhe para limites menos óbvios. Alguns provedores aplicam políticas de uso justo em CPU compartilhada. Outros oferecem CPU dedicada em planos específicos. Bandwidth, snapshots, backup automático, IPv6, firewall gerenciado e regiões disponíveis variam por provedor e por plano. Esses dados mudam com frequência e precisam ser confirmados no site oficial antes da compra, principalmente quando entram custos recorrentes.

Observabilidade, backup e resposta a incidentes

Uma aplicação Go em produção precisa ser observável desde o primeiro deploy. Sem métricas, você só descobre problema quando o usuário reclama. O básico inclui uso de CPU, memória, disco, rede, taxa de erro HTTP, latência por rota, número de goroutines, conexões abertas e tempo de resposta do banco. Go facilita parte disso com net/http/pprof, expvar, OpenTelemetry e bibliotecas de métricas para Prometheus. O cuidado é não expor endpoints de diagnóstico publicamente. Restrinja por firewall, rede privada ou autenticação.

Métricas que ajudam de verdade

Comece com quatro perguntas simples. A API está respondendo? Quanto demora? Quantas respostas 5xx aparecem? O servidor está perto de saturar? Para responder, colete métricas com Prometheus Node Exporter, Grafana Agent, OpenTelemetry Collector ou serviço gerenciado. Em uma VPS de 2 GB, cuidado com stacks pesadas. Um Prometheus local com retenção longa pode consumir disco e memória demais. Para projetos pequenos, retenção de 7 a 15 dias já ajuda bastante.

Logs também precisam de critério. Logar cada payload completo parece útil até o disco encher ou dados sensíveis aparecerem em texto puro. Prefira logs estruturados com nível, rota, status, duração, request ID e erro resumido. Em Go, bibliotecas como slog, zap e zerolog ajudam a manter baixa alocação e formato consistente. Para incidentes, request ID economiza horas.

Backup não é snapshot isolado

Snapshot é útil para restaurar uma VPS inteira, mas não substitui backup testado de banco de dados. Para PostgreSQL, tenha dump lógico ou backup físico conforme o tamanho e a criticidade. Para MySQL, use ferramenta adequada e teste restauração em ambiente separado. Arquivos de usuário devem ter política própria, com cópia fora da VPS. Uma regra prática: se você nunca restaurou, você não sabe se tem backup.

Também defina resposta a incidentes. Quem recebe alerta? Qual métrica dispara ação? Quando escalar a VPS? Quando fazer rollback? Para uma API Go, um runbook simples pode listar comandos como verificar systemctl status, consultar logs com journalctl, checar uso de disco com df -h, ver memória com free -m e identificar conexões com ss -tulpn. Parece básico, mas em madrugada de incidente o básico salva.

Concorrentes e critérios de escolha no mercado brasileiro

Ao escolher VPS para aplicações Go no Brasil, não compare só preço mensal. Compare região, latência, tipo de CPU, política de uso de CPU compartilhada, disco, largura de banda, snapshots, backup, firewall, API, console de emergência, IPv6, documentação e suporte. Provedores como DigitalOcean, Vultr, Linode/Akamai, AWS Lightsail, Google Cloud, Azure, Oracle Cloud, Hostinger, HostGator, Locaweb, Contabo, Hetzner e LetsCloud aparecem com frequência nas pesquisas, mas cada um atende melhor um perfil diferente.

O que comparar antes de contratar

DigitalOcean, Vultr e Linode/Akamai são populares entre desenvolvedores por painel simples, documentação ampla e APIs maduras. AWS Lightsail simplifica a entrada no ecossistema AWS, mas pode ficar limitado quando o projeto cresce para arquiteturas mais específicas. Google Cloud, Azure e AWS EC2 oferecem catálogo enorme, redes globais e serviços gerenciados, com curva de aprendizado e cobrança mais complexas. Hetzner e Contabo costumam chamar atenção por recursos generosos em alguns planos, mas localização, latência para o Brasil e suporte precisam ser avaliados conforme o caso.

Para aplicações Go no Brasil, região é um ponto sensível. Se o público está em São Paulo, Belo Horizonte, Curitiba ou Recife, um datacenter no Brasil pode melhorar tempo de ida e volta. Se a maioria dos usuários está nos EUA ou se o banco gerenciado fica fora do Brasil, talvez faça mais sentido hospedar a aplicação perto do banco. Medir é melhor que supor. Testes com ping, mtr, curl -w e carga sintética ajudam a separar marketing de resultado.

Onde LetsCloud pode entrar na análise

LetsCloud pode ser considerada quando o projeto valoriza presença regional, cobrança local ou uma operação mais próxima do mercado brasileiro, desde que plano, localidade, tipo de storage, backup, snapshots, bandwidth e suporte sejam confirmados nas páginas oficiais antes da publicação ou contratação. Não trate NVMe, backups automáticos ou qualquer recurso como universal sem verificar o plano específico. Para Go, o encaixe depende menos da linguagem e mais da combinação entre latência, recursos, previsibilidade de upgrade e operação diária.

Evite comparativos de preço sem revisão humana. Valores promocionais, impostos, renovação, câmbio e franquias mudam. O critério editorial mais seguro é comparar perfis de uso e requisitos técnicos, deixando preço específico para páginas revisadas com data de coleta recente.

Recomendações por perfil

Dev solo

Para um dev solo colocando uma API Go no ar, a melhor escolha costuma ser uma VPS simples, previsível e fácil de operar. Comece com 2 vCPUs, 2 GB ou 4 GB de RAM e 40 GB de SSD. Use Caddy para TLS automático ou Nginx se você já domina a configuração. Rode o binário com systemd, mantenha firewall fechado para tudo exceto SSH, HTTP e HTTPS, e configure backup do banco desde o primeiro dia. Se o banco estiver na mesma VPS, prefira 4 GB de RAM. Não coloque Kubernetes no início. Invista em deploy reproduzível e logs claros.

Time pequeno

Para um time pequeno, com duas a seis pessoas mexendo na aplicação, a prioridade passa a ser padronização. Uma VPS com 4 vCPUs, 8 GB de RAM e 80 GB de SSD ou NVMe dá espaço para API, worker, Redis leve, observabilidade básica e deploy via CI. Docker Compose pode ajudar a alinhar ambiente local, staging e produção, desde que os limites de recursos sejam definidos. Use branches protegidas, migrações revisadas e rollback documentado. Se a aplicação já atende clientes pagantes, considere separar banco de dados ou pelo menos manter backup externo testado semanalmente.

Produção crítica

Para produção crítica, trate VPS como parte de uma arquitetura, não como uma máquina isolada. Considere 4 a 8 vCPUs, 8 GB a 16 GB de RAM, disco NVMe quando houver I/O intenso, monitoramento externo e plano de recuperação. O banco deve ter backup consistente, restauração testada e, dependendo do SLA, replicação ou serviço gerenciado. Workers devem ter limites de concorrência e filas com retry controlado. Deploy precisa ter rollback rápido. Se a aplicação exige disponibilidade alta, uma única VPS pode ser ponto único de falha. Nesse caso, avalie balanceamento, múltiplas instâncias e banco fora do host da aplicação.