Como escolher VPS para FastAPI no Brasil

Resposta direta

Para hospedar FastAPI em produção no Brasil, comece com uma VPS ou Cloud Server de pelo menos 2 vCPUs, 2 GB de RAM e 40 GB de SSD para APIs pequenas, usando Uvicorn ou Gunicorn com workers ASGI atrás de Nginx, Caddy ou Traefik. Se a API usa PostgreSQL no mesmo servidor, filas, Redis, uploads ou tarefas assíncronas pesadas, o ponto de partida mais seguro passa para 4 vCPUs, 4 GB a 8 GB de RAM e disco SSD ou NVMe com boa taxa de I/O. A localização do datacenter pesa bastante: para usuários brasileiros, uma instância em São Paulo costuma reduzir latência em relação a regiões nos EUA ou Europa. A decisão final deve considerar tráfego simultâneo, tempo médio de resposta, consultas ao banco, estratégia de backup, observabilidade e facilidade de upgrade.

Resumo rápido

• FastAPI é leve, mas a aplicação inteira não é só o framework: banco, proxy, logs, filas e TLS consomem recursos.
• Para produção básica, use 2 vCPUs, 2 GB de RAM, 40 GB de SSD e swap moderado, sem depender dela para carga real.
• APIs com PostgreSQL local, Redis e workers em background ficam mais confortáveis com 4 vCPUs e 4 GB a 8 GB de RAM.
• Uvicorn funciona bem para ASGI, mas em produção é comum usar Gunicorn gerenciando múltiplos workers Uvicorn.
• Nginx, Caddy ou Traefik devem ficar na frente da aplicação para TLS, compressão, roteamento e headers.
• Datacenter no Brasil ajuda APIs consumidas por usuários, apps móveis e integrações empresariais nacionais.
• Backups testados, firewall, deploy automatizado e monitoramento fazem tanta diferença quanto CPU e RAM.

O que muda ao rodar FastAPI em uma VPS no Brasil

FastAPI ganhou espaço porque entrega boa produtividade em Python, validação forte com Pydantic e suporte nativo a async. Isso não significa que qualquer servidor pequeno aguente produção. Uma API real recebe conexões simultâneas, conversa com banco de dados, grava logs, valida tokens, processa JSON, responde a health checks e pode disparar tarefas assíncronas. O framework em si costuma ser eficiente, mas o conjunto da stack precisa ser dimensionado com cuidado.

Em uma VPS no Brasil, a primeira diferença aparece na latência. Se o consumidor da API está em São Paulo, Belo Horizonte, Rio de Janeiro, Curitiba ou em uma rede corporativa nacional, hospedar em região brasileira tende a encurtar o caminho da requisição. Em integrações B2B, essa diferença pode ser percebida em chamadas repetidas. Um endpoint que responde em 80 ms dentro do país pode passar de 180 ms ou 220 ms quando a aplicação está em uma região distante, mesmo sem gargalo de CPU. Não é uma regra fixa, porque rota de rede e operadora variam, mas é um fator prático.

VPS tradicional, Cloud Server e cloud instance

VPS tradicional normalmente significa uma máquina virtual em um host físico, com recursos definidos por plano. Cloud Server ou cloud instance costuma oferecer criação mais rápida, imagens prontas, rede privada, snapshots e upgrade com menos atrito, dependendo do provedor. Para FastAPI, os dois modelos podem funcionar. A diferença está menos no nome comercial e mais em previsibilidade de CPU, I/O de disco, painel, automação, backup e opções de escala.

Quem já hospeda aplicações Python pode comparar este cenário com um projeto Django. Em Django, o servidor costuma carregar mais lógica de template, admin e ORM síncrono. Em FastAPI, o perfil pode ser mais voltado a JSON, OpenAPI e serviços assíncronos. Mesmo assim, muitos critérios se repetem. O artigo sobre VPS para Python Django no Brasil ajuda a entender como decisões de CPU, RAM e banco mudam entre aplicações Python mais tradicionais e APIs modernas.

Latência e público brasileiro

Se a API atende um aplicativo móvel usado no Brasil, latência vira parte da experiência do usuário. Cada tela pode fazer três ou quatro chamadas, e pequenos atrasos se acumulam. Para uma API interna consumida por servidores em outro país, a localização brasileira talvez não seja prioridade. Já para checkout, autenticação, consulta de saldo, painel SaaS e integração com ERPs nacionais, hospedar perto do público costuma ser uma decisão técnica defensável. O ideal é medir com ping, traceroute e testes reais de endpoint, não apenas assumir que todo datacenter local será melhor em qualquer situação.

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

Dimensionar FastAPI começa por separar três cargas: processamento Python, espera de I/O e serviços auxiliares. Uma API que só recebe JSON, valida dados e consulta um banco remoto pode usar pouca CPU. Já uma API que gera PDFs, processa imagens, calcula relatórios, faz scraping controlado ou executa modelos de machine learning precisa de mais vCPU e, às vezes, isolamento em workers separados. A pergunta correta não é apenas quantas requisições por segundo o FastAPI aguenta. A pergunta é o que cada requisição faz.

Para um MVP com poucos usuários simultâneos, 2 vCPUs e 2 GB de RAM podem ser suficientes, desde que o banco esteja bem configurado e a aplicação não rode tarefas pesadas no mesmo processo. Nesse perfil, reserve algo como 300 MB a 700 MB para sistema operacional, Nginx e agentes, 300 MB a 800 MB para processos Python e o restante para cache do sistema e banco, se houver. Em produção pequena com PostgreSQL local, 2 GB ficam apertados rapidamente. O banco usa memória para shared buffers, conexões, cache e operações de ordenação. Se cada worker Python abrir conexões próprias, o consumo cresce.

Perfis de carga para FastAPI

Uma API de cadastro, login e CRUD com PostgreSQL remoto pode partir de 2 vCPUs, 2 GB de RAM e 40 GB de SSD. Uma API SaaS com autenticação JWT, PostgreSQL local, Redis, filas e 50 a 150 usuários simultâneos combina melhor com 4 vCPUs, 4 GB a 8 GB de RAM e 80 GB de SSD ou NVMe. Uma API de alta escrita, por exemplo eventos de telemetria ou webhooks com picos, exige olhar para IOPS, throughput de rede e estratégia de fila. Nesse caso, jogar mais worker no Gunicorn pode piorar tudo se o banco não acompanhar.

Disco também não deve ser tratado como detalhe. Logs, uploads, arquivos temporários, WAL do PostgreSQL e backups locais podem ocupar espaço sem aviso. Uma regra prática é manter pelo menos 30% do disco livre, configurar rotação de logs e nunca depender apenas de backup armazenado na mesma VPS. NVMe ajuda quando há muitas leituras e escritas pequenas, mas não corrige consulta SQL mal indexada nem ausência de pool de conexões.

Quando separar banco de dados e aplicação

Separar banco e API passa a fazer sentido quando a aplicação precisa de manutenção independente, quando o PostgreSQL consome muita memória ou quando o deploy da API não deve afetar o banco. Em um servidor único, um deploy ruim pode consumir CPU e prejudicar consultas. Em servidores separados, você ganha isolamento, mas também adiciona custo, rede privada, firewall entre instâncias e mais pontos de operação. Para uma equipe pequena, o meio-termo pode ser começar com tudo em uma VPS de 4 vCPUs e 8 GB, monitorar por duas ou quatro semanas e separar o banco quando CPU steal, memória ou I/O indicarem pressão real.

ASGI em produção: Uvicorn, Gunicorn e workers

FastAPI roda sobre ASGI, uma interface pensada para aplicações assíncronas em Python. O servidor mais comum é o Uvicorn, que pode executar a aplicação diretamente. Em produção, muitos times usam Gunicorn como gerenciador de processos e workers Uvicorn para servir a aplicação. Essa combinação permite reiniciar workers, lidar melhor com sinais do sistema, ajustar timeouts e controlar paralelismo por processo. Também facilita integração com systemd, supervisord ou containers.

A tentação inicial é configurar muitos workers. Nem sempre isso ajuda. Em uma VPS com 2 vCPUs, usar 2 workers costuma ser mais razoável do que iniciar 6 ou 8 processos. Cada worker carrega a aplicação, importa dependências e mantém conexões. Se a API usa bibliotecas grandes, Pydantic com modelos extensos ou clientes para serviços externos, cada processo pode consumir dezenas ou centenas de MB. Em 2 GB de RAM, exagerar nos workers leva a swap, e swap em produção é sinal de alerta, não estratégia de escala.

Quantos workers usar

Uma fórmula simples para começar é usar entre 1 e 2 workers por vCPU, depois medir. Para 2 vCPUs, teste 2 workers. Para 4 vCPUs, teste 4 workers. Se os endpoints são muito I/O bound, com espera de banco e chamadas externas, pode haver ganho com mais concorrência async, mas isso depende do uso correto de bibliotecas assíncronas. Se a aplicação usa driver síncrono para PostgreSQL, chamadas HTTP bloqueantes ou operações CPU-bound, o comportamento muda.

Um comando inicial com Gunicorn pode ficar assim:

gunicorn app.main:app \
  -k uvicorn.workers.UvicornWorker \
  --workers 4 \
  --bind 127.0.0.1:8000 \
  --timeout 60 \
  --access-logfile - \
  --error-logfile -

Esse exemplo assume uma aplicação em app/main.py com variável app. O bind em 127.0.0.1 é proposital. O processo ASGI não deve ficar aberto diretamente para a internet. Quem recebe a conexão pública é o proxy reverso, que cuida de TLS, headers, limites e roteamento.

Exemplo de serviço systemd

Um serviço systemd simples ajuda a reiniciar a API em caso de falha e manter logs centralizados no journal. Um exemplo seguro começa com usuário sem privilégios, diretório de trabalho explícito e variáveis de ambiente em arquivo separado. Nunca coloque senhas, tokens ou chaves privadas no unit file versionado em Git.

[Unit]
Description=FastAPI production service
After=network.target

[Service]
User=fastapi
Group=www-data
WorkingDirectory=/opt/minha-api
EnvironmentFile=/etc/minha-api/env
ExecStart=/opt/minha-api/venv/bin/gunicorn app.main:app -k uvicorn.workers.UvicornWorker --workers 4 --bind 127.0.0.1:8000 --timeout 60
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

Depois de criar o arquivo, rode systemctl daemon-reload, systemctl enable minha-api e systemctl start minha-api. Em deploys, prefira reload controlado ou restart em janela curta. Para APIs com tráfego maior, blue-green deploy ou containers com health check reduzem interrupções.

Proxy reverso, TLS e roteamento com Nginx, Caddy ou Traefik

Rodar FastAPI sem proxy reverso em produção é uma economia ruim. O Uvicorn é ótimo no papel de servidor ASGI, mas não substitui uma camada de borda preparada para TLS, compressão, redirecionamento HTTP para HTTPS, limites de upload, cabeçalhos de segurança e roteamento por domínio. Nginx, Caddy e Traefik resolvem esse papel com estilos diferentes. Nginx é maduro e amplamente documentado. Caddy simplifica certificados TLS automáticos. Traefik brilha quando há containers, labels e múltiplos serviços dinâmicos.

Se a sua API faz parte de uma arquitetura maior, com frontend, painel administrativo, webhooks e serviços internos, vale olhar o tema de forma mais ampla. O guia sobre VPS para reverse proxy com Nginx, Caddy e Traefik aprofunda a escolha do proxy e mostra quando cada ferramenta combina melhor com ambientes pequenos, Docker e múltiplos domínios.

Por que não expor o Uvicorn direto

Expor Uvicorn na porta pública aumenta a superfície de ataque e transfere responsabilidades para uma camada que não foi desenhada para ser a borda principal. Com Nginx na frente, você consegue limitar client_max_body_size, aplicar timeouts, registrar access logs padronizados, bloquear métodos indesejados e adicionar headers como X-Forwarded-For e X-Forwarded-Proto. Isso também facilita servir /health, /metrics ou arquivos estáticos por rotas específicas, caso a arquitetura precise.

Um exemplo básico de Nginx para FastAPI seria:

server {
    listen 80;
    server_name api.exemplo.com;

    location / {
        proxy_pass http://127.0.0.1:8000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_read_timeout 60s;
    }
}

Na prática, esse bloco precisa ser acompanhado de TLS, redirecionamento para HTTPS e renovação automática de certificado. Com Certbot, a configuração é conhecida e bem documentada. Com Caddy, o arquivo pode ser menor, algo como api.exemplo.com { reverse_proxy 127.0.0.1:8000 }, desde que DNS e portas estejam corretos.

Cuidados com timeouts e uploads

APIs que recebem arquivos, webhooks lentos ou consultas demoradas precisam de timeouts coerentes. Se o Nginx corta em 60 segundos, mas a aplicação tenta processar relatório por 180 segundos, o usuário verá erro mesmo que o worker continue ocupado. O melhor desenho é retornar rápido, enviar a tarefa para fila e expor um endpoint de status. Isso reduz pressão no worker ASGI e melhora previsibilidade.

Banco de dados, filas e cache: onde a VPS costuma sofrer

Muitos problemas atribuídos à VPS são, na verdade, problemas de banco e concorrência. FastAPI pode responder rápido, mas uma consulta sem índice, uma transação longa ou um pool mal configurado derruba o tempo de resposta. PostgreSQL é uma escolha comum para APIs Python, mas precisa de memória, disco confiável e parâmetros ajustados ao tamanho da instância. Em uma VPS de 2 GB, não faz sentido configurar buffers como se houvesse 16 GB disponíveis. O sistema operacional também precisa de cache e a aplicação Python precisa respirar.

Se o banco fica na mesma VPS, limite o número de conexões abertas pelos workers. Quatro workers com pool de 10 conexões podem abrir 40 conexões rapidamente, sem contar tarefas em background. Para uma API pequena, pools de 5 por worker já podem ser suficientes. Em SQLAlchemy, asyncpg ou psycopg, revise o comportamento do pool e monitore conexões ativas. Conexão ociosa também consome recurso.

PostgreSQL local ou gerenciado

PostgreSQL local simplifica a arquitetura e reduz latência entre aplicação e banco, mas exige backup, atualização, tuning e restauração testada. Banco gerenciado reduz trabalho operacional, mas adiciona custo e depende da região disponível. Em ambiente brasileiro, confirme se o serviço gerenciado está no Brasil ou se ficará em outra região. Uma API hospedada em São Paulo falando com banco nos EUA pode perder parte do ganho de latência.

Para produção inicial, um desenho honesto é rodar FastAPI, Nginx, PostgreSQL e Redis em uma VPS de 4 vCPUs e 8 GB, com backup externo diário e snapshot antes de deploys grandes. Após crescimento, se o banco passar de 60% a 70% de uso de memória com frequência, se o I/O ficar alto ou se backups começarem a afetar a API, separar o banco vira prioridade.

Redis e tarefas em background

Redis é útil para cache, rate limiting, locks distribuídos e filas, mas não deve virar depósito permanente de dados críticos sem política clara de persistência. Para tarefas, Celery, RQ, Dramatiq ou Arq podem processar envio de e-mail, geração de relatórios e webhooks sem prender a requisição HTTP. Em uma VPS pequena, separar workers de background ajuda a evitar que uma tarefa pesada consuma CPU do processo web.

Um exemplo prático: uma API de notas fiscais recebe webhooks, valida assinatura e grava eventos. O endpoint deve responder em menos de 500 ms, colocar o processamento detalhado na fila e deixar um worker cuidar da integração externa. Se cada webhook fizer tudo dentro da requisição, picos de 200 eventos em poucos minutos podem saturar workers ASGI e banco ao mesmo tempo.

Deploy seguro e operação contínua

Deploy de FastAPI em VPS pode ser simples sem ser improvisado. O fluxo mínimo deve incluir usuário sem root para a aplicação, repositório Git ou artefato versionado, ambiente virtual isolado, variáveis fora do código, migrations controladas e restart do serviço com verificação de saúde. O objetivo é conseguir atualizar a API sem abrir brecha de segurança e sem depender de comandos manuais esquecidos em uma madrugada.

Um fluxo prático para projeto pequeno começa assim: criar usuário fastapi, clonar o repositório em /opt/minha-api, criar venv, instalar dependências com versões travadas, copiar variáveis para /etc/minha-api/env, rodar migrations e reiniciar o serviço systemd. Em CI, GitHub Actions ou GitLab CI podem acessar a VPS por SSH com chave restrita e executar um script de deploy. A chave privada nunca deve aparecer em código, logs ou exemplos publicados.

Fluxo de deploy simples

Um script de deploy enxuto pode executar git pull, instalar dependências e reiniciar a aplicação. Para reduzir risco, rode testes antes de enviar, use arquivo .env fora do repositório e tenha comando de rollback documentado. Exemplo de sequência local no servidor:

cd /opt/minha-api
git fetch origin
git checkout main
git pull --ff-only
./venv/bin/pip install -r requirements.txt
./venv/bin/alembic upgrade head
sudo systemctl restart minha-api
curl -f http://127.0.0.1:8000/health

Esse modelo atende MVPs e APIs internas. Para times maiores, containers ajudam a empacotar dependências, padronizar ambiente e facilitar rollback por imagem. Mesmo com Docker, a VPS continua exigindo firewall, logs, backup, atualização do host e limites de recursos. O conteúdo sobre VPS para APIs e microsserviços no Brasil complementa essa visão quando a FastAPI deixa de ser um serviço único e passa a fazer parte de um conjunto de APIs.

Monitoramento e rollback

Sem monitoramento, dimensionamento vira palpite permanente. Acompanhe CPU, memória, disco, I/O, conexões do banco, latência p95 e taxa de erro. Ferramentas como Prometheus, Grafana, Netdata, Uptime Kuma, Sentry e logs centralizados ajudam a detectar degradação antes do cliente reclamar. Para uma VPS pequena, até journalctl, htop, iotop, df -h e métricas do painel do provedor já mostram muita coisa.

Backup precisa ser testado. Snapshot é útil antes de mudanças, mas não substitui dump consistente do banco enviado para armazenamento externo. Uma rotina comum é fazer dump diário do PostgreSQL, criptografar, enviar para bucket compatível com S3 e manter retenção de 7, 14 ou 30 dias. Restauração deve ser ensaiada em outro servidor. Backup que nunca foi restaurado é apenas esperança compactada.

Tabela comparativa de perfis para FastAPI

A tabela abaixo não é uma comparação de preços entre provedores. Ela resume perfis técnicos de dimensionamento para orientar a escolha de VPS ou Cloud Server. Recursos variam por provedor, região, virtualização e política de uso justo de CPU. Antes de contratar, confirme tipo de disco, tráfego incluído, disponibilidade de datacenter no Brasil, snapshots, backup, rede privada e forma de upgrade no site oficial do fornecedor.

Perfil de uso	Configuração inicial sugerida	Stack típica	Sinais de que precisa subir o plano	Observações técnicas
MVP ou API interna pequena	2 vCPUs, 2 GB RAM, 40 GB SSD	FastAPI, Uvicorn, Nginx, SQLite apenas para testes ou PostgreSQL remoto	Swap frequente, CPU acima de 80% em picos, deploy derrubando serviço	Bom para validação, webhooks leves e integrações internas com baixo tráfego
SaaS pequeno em produção	4 vCPUs, 4 GB a 8 GB RAM, 80 GB SSD ou NVMe	FastAPI, Gunicorn, Nginx ou Caddy, PostgreSQL, Redis, filas	Latência p95 subindo, I/O alto, conexões do banco no limite	Ponto de partida equilibrado para clientes reais e rotina de backup externa
API com picos e webhooks	4 a 8 vCPUs, 8 GB a 16 GB RAM, NVMe conforme disponibilidade	FastAPI, workers ASGI, fila, Redis, PostgreSQL separado ou gerenciado	Fila acumulando, erros 502, timeouts no proxy, banco saturado	Priorize filas, rate limiting, observabilidade e testes de carga antes de escalar às cegas
Produção crítica ou B2B	8 vCPUs ou mais, 16 GB RAM ou mais, banco separado	Múltiplas instâncias, load balancer, deploy blue-green, monitoramento	Janela de manutenção inviável, necessidade de alta disponibilidade, SLA contratual	Pode exigir arquitetura com mais de uma VPS, não apenas um plano maior

Para provedores, a análise deve ser factual. DigitalOcean, Vultr, Linode/Akamai, AWS Lightsail, Google Cloud, Azure, Oracle Cloud, Hostinger, HostGator, Locaweb, Contabo, Hetzner e LetsCloud têm públicos, regiões e modelos diferentes. No contexto brasileiro, confirme datacenter local, cobrança, suporte, bandwidth e storage antes de publicar qualquer afirmação específica. LetsCloud pode fazer sentido quando a prioridade é infraestrutura com presença voltada ao Brasil, mas disponibilidade de NVMe, snapshots, backups e localidades deve ser verificada por plano e data de contratação.

Um teste de carga simples ajuda a transformar a tabela em decisão. Rode wrk, hey ou k6 contra endpoints representativos, não apenas /health. Teste login, listagem com paginação, criação de registro e uma consulta pesada. Meça p50, p95, p99, erros, CPU e conexões do banco. Se o endpoint /health responde 5.000 requisições por segundo, isso diz pouco sobre a rota que faz join, valida permissão e grava auditoria.

Recomendações por perfil

Dev solo ou MVP

Para dev solo, startup em validação ou API interna de baixo tráfego, comece simples: 2 vCPUs, 2 GB de RAM e 40 GB de SSD, com Ubuntu LTS, Nginx, Gunicorn com 2 workers Uvicorn e banco remoto ou PostgreSQL local muito enxuto. Esse perfil combina com APIs de autenticação, protótipos, webhooks leves e painéis internos usados por poucas pessoas. Configure firewall liberando apenas 22, 80 e 443, use SSH por chave e desative login por senha. O maior risco aqui é economizar demais e rodar tudo sem backup. Mesmo em MVP, tenha dump diário do banco fora da VPS e um checklist de restauração.

Time pequeno com API em crescimento

Para um time pequeno atendendo clientes reais, o ponto de partida mais confortável é 4 vCPUs, 4 GB a 8 GB de RAM e 80 GB de SSD ou NVMe, conforme disponibilidade do provedor. Use Gunicorn com 4 workers, Nginx ou Caddy, PostgreSQL com parâmetros modestos, Redis para cache ou fila e monitoramento básico. Esse perfil atende SaaS inicial, integrações B2B, aplicativos móveis e backends com dezenas de usuários simultâneos. O time deve acompanhar latência p95, taxa de erro, uso de memória, conexões do banco e tamanho dos logs. Se deploys começam a causar indisponibilidade, introduza containers, health checks e rollback por versão.

Produção crítica com clientes no Brasil

Para produção crítica, especialmente APIs que afetam pagamento, logística, saúde, educação, financeiro ou operação B2B, pense além de uma VPS maior. Use instâncias separadas para aplicação e banco, backup externo testado, monitoramento com alerta, deploy blue-green ou rolling, TLS bem configurado e plano de resposta a incidentes. Uma configuração inicial pode usar 2 instâncias de aplicação com 4 vCPUs e 8 GB de RAM cada, balanceador na frente e PostgreSQL separado, gerenciado ou autoadministrado com rotina clara de réplica e backup. Se os clientes estão no Brasil, teste latência a partir de redes nacionais e confirme região do banco. Produção crítica pede evidência, não suposição.