VPS para Java Spring Boot no Brasil: guia prático

Resposta direta

Para hospedar Java Spring Boot em uma VPS no Brasil, comece com pelo menos 2 vCPUs, 4 GB de RAM, 40 a 80 GB de SSD ou NVMe e Ubuntu LTS, Debian estável ou Rocky Linux. Essa base atende APIs pequenas e médias com Java 17 ou Java 21, Nginx como proxy reverso, TLS via Let’s Encrypt e deploy por systemd ou Docker. Se a aplicação usa PostgreSQL ou MySQL na mesma máquina, filas, cache, jobs agendados ou tráfego acima de alguns milhares de requisições por dia, 4 vCPUs e 8 GB de RAM passam a ser uma escolha mais segura. Para público brasileiro, datacenter no Brasil pode reduzir latência percebida, mas CPU, memória, I/O, backup e operação continuam pesando tanto quanto a localização.

Resumo rápido

Escolher VPS para Java Spring Boot exige olhar além do número de vCPUs anunciado no plano. A JVM reserva memória, o garbage collector precisa de folga, o sistema operacional consome recursos e o banco de dados pode competir por CPU e disco. Uma API que roda bem no notebook do desenvolvedor pode travar em produção se subir em uma instância de 1 GB de RAM com PostgreSQL, Nginx, Docker e logs persistentes no mesmo servidor.

• Para produção básica, use 2 vCPUs, 4 GB de RAM e 40 GB de SSD como ponto de partida. Em Java, 2 GB de RAM só faz sentido para APIs muito leves e bem controladas.
• Para API com banco no mesmo servidor, prefira 4 vCPUs, 8 GB de RAM e disco de 80 GB ou mais, especialmente com PostgreSQL, Elasticsearch pequeno, RabbitMQ ou Redis.
• Defina limites explícitos de heap, por exemplo -Xms512m -Xmx1536m em VPS de 4 GB, em vez de deixar a JVM crescer sem planejamento.
• Docker facilita padronização do ambiente, mas também consome memória. Se for usar containers, leia o guia de VPS para Docker antes de consolidar aplicação, banco e proxy na mesma máquina.
• Datacenter no Brasil ajuda APIs consumidas por usuários brasileiros, integrações locais e sistemas administrativos com muitas chamadas curtas.
• SSD ou NVMe melhora logs, consultas, filas e builds, mas não compensa uma aplicação sem índices no banco ou com heap mal configurado.
• Backups, snapshots, firewall e monitoramento precisam entrar na decisão antes do primeiro deploy, não depois do primeiro incidente.

O que muda ao hospedar Spring Boot em VPS no Brasil

Spring Boot é confortável para desenvolvimento porque entrega servidor embutido, auto configuração e empacotamento simples em JAR. Em produção, essa praticidade não elimina o trabalho de infraestrutura. A aplicação passa a depender de uma JVM persistente, variáveis de ambiente, gerenciamento de processo, proxy reverso, certificados TLS, logs, métricas, backups e política de atualização do sistema. Em uma VPS, você controla tudo isso. O lado bom é flexibilidade. O lado trabalhoso é que a responsabilidade operacional também fica com você.

VPS tradicional, Cloud Server e cloud instance

VPS tradicional costuma significar uma máquina virtual criada sobre um servidor físico, com recursos alocados de forma relativamente fixa. Cloud Server ou cloud instance normalmente indica provisionamento em uma plataforma cloud, com painel, API, rede virtual, snapshots e upgrades mais ágeis, dependendo do provedor. Na prática editorial, o mais seguro é avaliar recurso real, isolamento, rede, backup e operação, não apenas o nome comercial usado na página do produto. Dois planos chamados VPS podem ter experiências bem diferentes.

Para Spring Boot, essa diferença aparece em momentos simples. Se você precisa aumentar de 2 para 4 vCPUs durante uma campanha, um Cloud Server com resize rápido reduz fricção. Se o projeto é estável, com tráfego previsível e deploy manual mensal, uma VPS tradicional bem configurada pode atender sem drama. O ponto é entender o perfil do sistema antes de escolher.

Quando a localização pesa mais

Hospedar no Brasil tende a reduzir latência para usuários e integrações nacionais. Um painel administrativo acessado em São Paulo, Belo Horizonte ou Recife pode responder melhor quando a API está em datacenter nacional do que em uma região nos Estados Unidos. Isso pesa em aplicações com muitas chamadas pequenas, como autenticação, dashboards, gateways internos e APIs para aplicativos móveis.

Ainda assim, localização não resolve gargalos internos. Uma API Spring Boot com pool de conexão pequeno demais, queries sem índice e heap apertado continuará lenta, mesmo dentro do Brasil. Se você está comparando stacks, o raciocínio é parecido com o de aplicações JavaScript em produção. No guia de VPS para Node.js no Brasil, a latência também aparece como fator relevante, mas não substitui dimensionamento, logs e deploy bem feito.

CPU, RAM, disco e rede: como dimensionar a VPS

O dimensionamento de uma VPS para Spring Boot começa pela RAM. Java usa memória para heap, metaspace, threads, bibliotecas nativas, buffers, sistema operacional e cache de disco. Em uma instância de 2 GB, deixar a JVM com -Xmx1536m pode parecer razoável, mas sobra pouco para Nginx, agente de monitoramento, SSH, journald e banco local. Quando o sistema começa a usar swap, a latência sobe e o comportamento fica irregular. Para produção, 4 GB costuma ser o mínimo mais confortável.

Configuração mínima realista

Uma API REST pequena, com 20 a 50 endpoints, autenticação JWT, banco gerenciado fora da VPS e tráfego moderado pode começar com 2 vCPUs, 4 GB de RAM e 40 GB de SSD. Nesse cenário, uma configuração de JVM como -Xms512m -Xmx1536m deixa margem para o sistema. O Nginx faz TLS e proxy para a porta 8080, a aplicação grava logs rotacionados e o banco externo absorve a maior parte do I/O persistente.

Se o banco estiver na mesma máquina, o ponto de partida muda. PostgreSQL ou MySQL precisam de cache, conexões e escrita em disco. Para uma API com banco local, fila leve e Redis, faz mais sentido pensar em 4 vCPUs, 8 GB de RAM e 80 GB de SSD ou NVMe. O heap pode ficar entre 2 GB e 3 GB, o banco recebe memória própria e o sistema ainda consegue respirar durante backup, deploy e picos de tráfego.

Quando subir para 4 vCPUs ou mais

CPU pesa em serialização JSON, criptografia TLS, compressão, consultas complexas, processamento de arquivos, relatórios e tarefas assíncronas. Spring Boot também cria threads para web server, pool de conexões, schedulers e workers. Em APIs com picos simultâneos, 1 vCPU vira gargalo rápido. Dois núcleos virtuais são aceitáveis para MVP, mas 4 vCPUs reduzem contenção quando há banco local ou jobs em background.

Disco também merece atenção. SSD é suficiente para muita API. NVMe pode ajudar em workloads com logs intensos, banco local, filas persistentes e muitos arquivos pequenos, mas disponibilidade depende de provedor, plano e localidade. Antes de comprar, confira tipo de storage, política de snapshot, limite de IOPS quando informado e banda de rede. Para entender a lógica de escolha entre CPU, RAM e armazenamento, o guia como escolher CPU, RAM e NVMe aprofunda esses trade-offs com exemplos de VPS e Cloud Server.

JVM, sistema operacional e ajustes de runtime

A JVM moderna lida melhor com containers e limites de memória do que versões antigas, mas isso não dispensa configuração. Java 17 e Java 21 são escolhas maduras para Spring Boot atual, com bom suporte de longo prazo em distribuições como Eclipse Temurin, Amazon Corretto, Azul Zulu e OpenJDK empacotado por distribuições Linux. O mais importante é padronizar versão entre desenvolvimento, CI e produção. Trocar de Java 17 para Java 21 sem teste pode mudar consumo de memória, tempo de startup e comportamento de bibliotecas.

Heap, metaspace e limites do systemd

Em produção, defina heap de forma explícita. Para VPS de 4 GB, um exemplo inicial é JAVA_OPTS=-Xms512m -Xmx1536m -XX:+UseG1GC. Em VPS de 8 GB com banco separado, -Xms1g -Xmx3g costuma dar folga para APIs médias. Se o banco roda localmente, reduza o heap da aplicação ou aumente a VPS, porque PostgreSQL e MySQL também dependem de cache. Não existe número mágico. O ideal é medir uso real com métricas de heap, GC, CPU e latência por endpoint.

Com systemd, crie um serviço dedicado para o JAR. Use usuário sem privilégios, diretório de trabalho fixo e restart automático. Um serviço simples pode usar ExecStart=/usr/bin/java $JAVA_OPTS -jar /opt/app/app.jar, Restart=always e RestartSec=10. Também vale definir MemoryMax quando você quer impedir que a aplicação consuma a VPS inteira. Esse limite precisa ser maior que o heap, pois a JVM usa memória fora do heap.

Java 17, Java 21 e imagem do sistema

Ubuntu 22.04 LTS, Ubuntu 24.04 LTS e Debian 12 são escolhas comuns para VPS Java. Elas têm pacotes estáveis, documentação ampla e boa compatibilidade com Nginx, Certbot, Docker e agentes de monitoramento. Rocky Linux e AlmaLinux também fazem sentido em equipes acostumadas ao ecossistema RHEL. O ponto prático é manter uma base previsível, com atualizações de segurança e scripts de provisionamento repetíveis.

Evite instalar muitas versões de Java sem controle. Em servidores pequenos, bagunça operacional causa erro bobo: o deploy roda com Java 21 no terminal, mas o serviço systemd usa Java 17 por causa do PATH. Defina JAVA_HOME, registre a versão no README operacional e valide com java -version dentro do mesmo contexto em que o serviço roda. Parece detalhe, mas esse tipo de inconsistência derruba deploy em sexta-feira.

Deploy em produção: Docker, systemd, proxy e CI/CD

O deploy de Spring Boot em VPS pode ser simples sem ser improvisado. O caminho clássico é gerar um JAR no pipeline, enviar para /opt/app, atualizar variáveis de ambiente, reiniciar o serviço systemd e validar health check. O caminho com Docker empacota a aplicação em imagem, usa Compose ou outro orquestrador leve e facilita rollback por tag. Os dois funcionam. A melhor escolha depende da maturidade da equipe, da quantidade de serviços e da necessidade de reproduzir o ambiente.

Deploy sem Docker

Sem Docker, você reduz camadas e consumo de memória. A VPS precisa de Java, usuário de aplicação, Nginx, Certbot e systemd. Um fluxo prático é compilar com Maven ou Gradle no CI, salvar o artefato como app-1.4.2.jar, copiar via SSH e atualizar um symlink app.jar. Depois, rode systemctl restart app e consulte /actuator/health. Para evitar downtime perceptível, dá para usar duas portas internas, por exemplo 8081 e 8082, e alternar o upstream do Nginx após o health check responder.

Esse modelo combina com dev solo, APIs pequenas e times que querem menos moving parts. O cuidado principal é manter deploy idempotente. Scripts que dependem de estado manual quebram cedo. Registre variáveis em arquivo de ambiente protegido, como /etc/app/app.env, e nunca coloque senha, token ou chave privada dentro do repositório. Logs devem ir para journald ou arquivo rotacionado, com retenção limitada.

Deploy com Docker e Compose

Com Docker, a aplicação roda em container, o banco pode rodar em outro e o Nginx pode ficar no host ou em container separado. Em uma VPS de 4 GB, rode poucos containers e defina limites. Um Compose com app, postgres e redis funciona para MVP, mas exige backups e volumes bem planejados. Em produção mais séria, separar banco em outro Cloud Server ou serviço gerenciado reduz risco.

Docker ajuda quando você tem dependências específicas, precisa replicar ambiente em staging e quer rollback por imagem. Também facilita rodar sidecars, como coletor de logs ou exporter de métricas. Só não trate Docker como substituto de arquitetura. Uma VPS pequena com containers demais vai sofrer do mesmo jeito. Se sua aplicação usa Docker para Spring Boot, banco, fila e observabilidade, o guia de VPS para Docker ajuda a estimar memória, disco e organização de volumes persistentes.

Banco de dados, storage, backup e observabilidade

A decisão de colocar banco de dados na mesma VPS da aplicação deve ser tomada com calma. Para MVP, ambiente interno ou produto em validação, pode ser uma escolha econômica e simples. Para produção com usuários pagantes, dados sensíveis ou alto volume de escrita, separar banco e aplicação reduz risco operacional. Quando tudo mora no mesmo servidor, um pico de CPU da API afeta o banco. Um backup pesado afeta a API. Uma falha de disco atinge tudo ao mesmo tempo.

Quando separar banco e aplicação

Separe o banco quando a aplicação precisa de disponibilidade mais previsível, quando o volume de dados cresce rápido ou quando a equipe não quer administrar tuning, backup e replicação sozinha. Uma configuração comum é VPS de aplicação com 2 a 4 vCPUs e 4 a 8 GB de RAM, banco em serviço gerenciado ou Cloud Server dedicado, Redis separado quando há cache crítico e storage de arquivos em objeto, não no disco local da aplicação. Isso simplifica deploy, rollback e manutenção.

Se o banco ficar local, reserve recursos. Em VPS de 8 GB, você pode usar heap da aplicação em torno de 2 GB, PostgreSQL com parâmetros conservadores e margem para sistema. Evite abrir 200 conexões só porque o pool permite. Em Spring Boot, HikariCP com maximumPoolSize=10 ou 20 já atende muitas APIs pequenas, desde que as queries sejam rápidas. Pool grande demais não cria capacidade, apenas aumenta contenção.

Backups testados e métricas úteis

Backup bom é backup restaurado em teste. Para PostgreSQL, pg_dump diário pode servir para bases pequenas. Para bases maiores, snapshots consistentes, WAL archiving e replicas entram no desenho. Para MySQL, mysqldump resolve cenários simples, mas pode travar dependendo do volume e engine. Armazene backup fora da VPS, com retenção mínima de 7 a 30 dias, criptografia e teste de restauração mensal.

Observabilidade não precisa começar cara. Exponha Spring Boot Actuator com endpoints restritos, monitore CPU, RAM, disco, load average, latência HTTP, taxa de erro, tempo de GC e uso de heap. Prometheus e Grafana são ótimos, mas também consomem recursos. Em VPS pequena, um agente leve externo pode ser suficiente. O ponto é receber alerta antes do disco chegar a 100 por cento ou antes do heap entrar em ciclo constante de garbage collection.

Localização no Brasil, latência e provedores

Para aplicações Java Spring Boot usadas por público brasileiro, a localização do datacenter muda a experiência em operações interativas. Uma API hospedada no Brasil pode responder com menor tempo de ida e volta para usuários nacionais, especialmente em sistemas com múltiplas chamadas por tela. Isso não significa que toda aplicação deve ficar no Brasil. Se o banco, filas, CDN e integrações principais estão fora, hospedar só a API localmente pode criar tráfego cruzado e piorar o desenho. A arquitetura precisa ser vista inteira.

Como avaliar datacenter

Antes de escolher, verifique região disponível, política de banda, tipo de armazenamento, snapshots, backups, IPv4, IPv6, firewall, console de emergência e possibilidade de upgrade. Preço, promoção, localidade e recursos variáveis precisam ser confirmados nas páginas oficiais antes de publicação ou contratação, porque provedores alteram planos. Para este guia, os dados de concorrentes devem ser tratados como referência editorial coletada em 2026-07-10, com revisão humana recomendada antes de qualquer comparação comercial.

LetsCloud pode entrar no radar quando o projeto valoriza presença regional e operação voltada ao mercado brasileiro, mas a disponibilidade de localidades como São Paulo, Fortaleza ou Miami, tipo de storage, snapshots, backup automático, suporte e valores deve ser validada no site oficial por plano. DigitalOcean, Vultr, Linode/Akamai, AWS Lightsail, Google Cloud, Azure e Oracle Cloud também atendem perfis diferentes, com variações de painel, regiões, rede e serviços complementares.

Tabela comparativa editorial

A tabela abaixo não compara preço. Ela resume perfis técnicos comuns para Spring Boot e ajuda a transformar requisitos em configuração inicial. Use como ponto de partida, depois valide consumo real com métricas.

Perfil de aplicação	Configuração inicial sugerida	Banco de dados	Deploy recomendado	Observações técnicas
API pequena, banco externo	2 vCPUs, 4 GB RAM, 40 GB SSD	Gerenciado ou servidor separado	JAR com systemd ou Docker único	Heap entre 1 GB e 1,5 GB, Nginx no host e Actuator protegido
API média com banco local	4 vCPUs, 8 GB RAM, 80 GB SSD ou NVMe	PostgreSQL ou MySQL na mesma VPS	Docker Compose ou systemd com serviços separados	Pool Hikari entre 10 e 20 conexões, backup externo diário e disco monitorado
SaaS em produção com filas	4 a 8 vCPUs, 16 GB RAM, 160 GB SSD ou mais	Banco dedicado ou gerenciado	CI/CD com staging, rollback e métricas	Separar Redis, jobs e banco reduz contenção e facilita manutenção
Integração interna de baixa carga	2 vCPUs, 2 a 4 GB RAM, 30 a 40 GB SSD	Leve ou externo	JAR com systemd	Aceitável quando há poucos usuários e heap bem limitado

Repare que a configuração mínima de 2 GB aparece apenas em cenário de baixa carga e controle rígido. Para APIs públicas, 4 GB evita boa parte dos problemas de swap e reinícios inesperados. Também ajuda a manter margem durante atualização de pacote, renovação de certificado, compressão de logs e deploy simultâneo.

Segurança e operação diária de uma VPS Java

Segurança em VPS para Spring Boot começa antes do deploy. Acesso SSH por chave, usuário sem root para a aplicação, firewall restritivo e atualizações automáticas de segurança reduzem a superfície de ataque. O servidor não deve expor a porta 8080 diretamente para a internet. O padrão mais comum é Nginx ou Caddy escutando 80 e 443, com proxy para a aplicação em localhost. Banco de dados local deve aceitar conexão apenas de localhost ou rede privada confiável.

Hardening inicial

Um checklist simples já evita muitos problemas. Desabilite login SSH por senha, restrinja root remoto, use ufw ou firewall do provedor, libere apenas 22, 80 e 443 quando necessário e configure fail2ban ou mecanismo equivalente para reduzir brute force. Certificados TLS podem ser emitidos com Certbot ou Caddy. Variáveis sensíveis devem ficar em arquivo protegido, secret manager ou painel seguro, nunca dentro do JAR, Dockerfile ou repositório.

No Spring Boot, revise CORS, cabeçalhos HTTP, exposição do Actuator e logs. Endpoints como /actuator/env, /actuator/heapdump e /actuator/logfile não devem ficar públicos. Se Actuator for usado para health check, exponha apenas o necessário, por exemplo /actuator/health, e proteja métricas com autenticação ou rede privada. Logs também merecem cuidado, porque podem conter tokens, e-mails, CPF ou payloads sensíveis se a aplicação estiver mal configurada.

Rotina de manutenção

A operação diária combina atualização, monitoramento e ensaio de recuperação. Programe janelas para atualizar pacotes, reiniciar serviços e testar rollback. Aplique logs rotacionados com logrotate ou política do journald, pois Spring Boot pode gerar muitos logs em erro repetitivo. Configure alerta de disco em 75 ou 80 por cento, CPU sustentada acima de 80 por cento, memória próxima do limite, falha de health check e aumento de erros 5xx.

Também documente o processo de reconstrução. Se a VPS sumir hoje, quanto tempo leva para subir outra? O ideal é ter script de provisionamento, variáveis mapeadas, backup recente e comando de deploy reproduzível. Mesmo em equipe pequena, um arquivo operacional com comandos de restore, portas, serviços, domínios e responsáveis já reduz bastante o tempo de incidente.

Recomendações por perfil

Dev solo e MVP

Para dev solo, produto em validação ou API interna simples, comece com 2 vCPUs, 4 GB de RAM e 40 GB de SSD. Use Java 17 ou 21, JAR com systemd, Nginx no host e banco externo quando possível. Se o orçamento exigir banco local, mantenha PostgreSQL enxuto, limite o pool de conexões e faça backup diário fora da VPS. Esse perfil deve priorizar simplicidade e previsibilidade. Docker é opcional. Se você usa Docker, rode poucos containers e monitore memória desde o primeiro dia. O objetivo é evitar uma arquitetura grande demais antes de validar tráfego real.

Time pequeno com API em produção

Para time pequeno com usuários reais, integrações e deploy frequente, a base mais equilibrada costuma ser 4 vCPUs, 8 GB de RAM e 80 GB de SSD ou NVMe. Use CI/CD, staging, rollback por versão, health checks e monitoramento de heap, GC, latência e erros HTTP. Docker Compose pode funcionar bem, desde que volumes e backups sejam claros. Se o banco cresce ou recebe muitas escritas, separe em outro servidor ou serviço gerenciado. Nesse perfil, a localização no Brasil pode melhorar experiência para clientes nacionais, mas não deve ser escolhida isoladamente. Rede, suporte operacional, snapshots e restauração pesam bastante.

Produção crítica e SaaS

Para SaaS, fintech, healthtech, marketplace ou aplicação com impacto financeiro, evite colocar tudo em uma única VPS sem plano de contingência. Considere 4 a 8 vCPUs, 16 GB de RAM para aplicação, banco dedicado ou gerenciado, Redis separado, backups com teste de restauração e estratégia de observabilidade mais completa. Use deploy automatizado com rollback, logs centralizados, alertas e runbook de incidente. Também avalie alta disponibilidade, ainda que comece simples. Uma segunda instância, balanceador, banco replicado ou plano de recuperação documentado pode ser mais valioso do que apenas comprar uma VPS maior.

Quando escolher provedor nacional ou internacional

Provedor com datacenter no Brasil faz sentido quando a maioria dos usuários está no país, quando integrações locais têm baixa tolerância a latência ou quando a equipe prefere cobrança e atendimento mais alinhados ao mercado brasileiro, sempre com validação dos termos oficiais. Provedor internacional pode ser melhor quando você precisa de muitas regiões, serviços gerenciados, rede global ou integração com ecossistema cloud maior. Em qualquer caso, não escolha só pelo painel bonito. Teste deploy, meça latência, valide backup, confira console de emergência e simule upgrade antes de migrar produção.