---
title: "Como escolher VPS para API: CPU, RAM e conexões"
description: "Descubra quanta CPU, RAM e conexões simultâneas a sua API precisa, como o runtime muda a conta e quando escalar, com planos Ryzen e Xeon reais."
url: "https://streethosting.com.br/guias/vps/escolher-vps-para-api"
category: "vps"
slug: "escolher-vps-para-api"
datePublished: "2026-09-28"
dateModified: "2026-09-28"
author: "Equipe StreetHosting"
difficulty: "intermediario"
language: "pt-BR"
keywords:
  - "vps para api"
  - "escolher vps api"
  - "vps para api node python"
  - "conexoes simultaneas api vps"
  - "escalar api vps"
---

# VPS para API: dimensionar pelo runtime, pelas conexões e pelo banco

Uma API em Node.js, uma em Python e uma em Java com o mesmo tráfego pedem VPS diferentes. Veja como o runtime, as conexões simultâneas e o banco de dados definem CPU e RAM, como medir antes de contratar e como crescer depois.

> **Resposta rápida**
>
> Para escolher uma **VPS para API**, parta do runtime e do banco, não do tráfego estimado. Some a memória de cada processo ou worker, do banco e do cache; escolha vCPU pelo modelo de concorrência da linguagem; e confirme com um teste de carga. Uma API com banco na mesma máquina começa bem com 2 a 4 vCPU e 4 a 8 GB de RAM, de R$ 64,00 a R$ 114,00 por mês na linha Ryzen 9 9950X.

## Como uma API consome a VPS

Cada requisição tem duas fases. Na primeira, a API trabalha: valida dados, verifica o token, monta a resposta em JSON. Isso é CPU. Na segunda, espera: pelo banco, por outra API, pelo disco. Esperar não gasta CPU, mas mantém a conexão aberta, ocupa memória e segura um worker. Saber em qual fase a sua API passa mais tempo define o que comprar.

- **API limitada por CPU:** renderização no servidor, geração de PDF, redimensionamento de imagem, criptografia. Aqui o clock de cada núcleo manda na latência.
- **API limitada por espera:** o caso mais comum, um CRUD que consulta o banco e devolve JSON. Aqui importam o número de workers, a memória e a latência até o banco.
- **Endpoints traiçoeiros:** login com bcrypt ou argon2 gasta de propósito dezenas a centenas de milissegundos de CPU por tentativa. Um pico de logins, ou um ataque de força bruta, satura a CPU de uma API que no resto do tempo fica ociosa.

A meta que orienta a escolha é a latência no percentil 95, o tempo que 95% das requisições levam no máximo. Média esconde problema: uma API com média de 40 ms pode ter 5% das respostas passando de dois segundos.

## O runtime muda a conta

O mesmo tráfego pede recursos diferentes conforme a linguagem, porque cada runtime usa os núcleos e a memória de um jeito.

| Runtime | Como usa os núcleos | O que pesa na RAM | Tende a preferir |
| --- | --- | --- | --- |
| Node.js | Um núcleo por processo para o JavaScript; mais processos com PM2 em modo cluster | Heap de cada processo | Clock alto, linha Ryzen |
| Python (FastAPI, Django) | Um núcleo por worker por causa do GIL; escala com vários workers | Cada worker duplica a aplicação na memória | vCPU para workers; clock ajuda na latência |
| PHP (Laravel com PHP FPM) | Um processo por requisição em andamento | Memória por processo vezes o total de processos | RAM e vCPU, linha Xeon rende bem |
| Java e Kotlin (Spring Boot) | Vários núcleos em um processo, com threads | Heap da JVM, definida por Xmx | RAM e vários núcleos |
| Go, Rust e .NET | Vários núcleos em um processo, com pouca sobrecarga | Baixo por conexão | Qualquer linha; vCPU extra é bem aproveitado |

Duas consequências práticas. Em Node.js, uma VPS de 4 vCPU com um único processo usa só um núcleo para o código da aplicação: sem o modo cluster do [PM2](https://streethosting.com.br/guias/vps/configurar-pm2-startup-systemd-vps) ou vários processos atrás do Nginx, os outros três ficam ociosos. Em Python com Gunicorn, a documentação sugere começar com duas vezes o número de núcleos mais um como número de workers síncronos; com workers assíncronos do Uvicorn, um por núcleo costuma bastar. Cada worker carrega uma cópia da aplicação, então a RAM cresce junto. O guia de [API Node.js na VPS](https://streethosting.com.br/guias/vps/hospedar-api-nodejs-vps-brasil) mostra o lado Node.js dessa configuração na prática.

Em PHP e Java a conta de memória é mais direta. No PHP FPM, o número máximo de processos, o `pm.max_children`, sai da divisão da RAM reservada para o PHP pela memória média de um processo, que você vê no `htop` com a aplicação em uso: 2 GB para processos de 60 MB dão cerca de 33. Passar disso faz a VPS usar swap no pico. Na JVM, a memória total é maior que o heap, porque threads, metaspace e buffers ficam fora dele, então deixe folga entre o `-Xmx` e a RAM livre da VPS.

## Conexões simultâneas e limites

Requisições por segundo e conexões simultâneas são coisas diferentes, e a ligação entre elas é simples: requisições em andamento são iguais à vazão multiplicada pelo tempo de resposta. Uma API com 200 requisições por segundo e 50 ms de resposta tem, em média, só 10 requisições em andamento. Se o banco ficar lento e a resposta subir para 500 ms, são 100 ao mesmo tempo, com o mesmo tráfego. É por isso que um banco lento derruba a API inteira: os workers acabam.

WebSocket e Server Sent Events mudam a conta, porque cada usuário conectado segura uma conexão por minutos ou horas. Aí o que conta é memória por conexão e os limites do sistema, que vêm baixos por padrão:

- **Arquivos abertos do processo:** cada conexão é um descritor de arquivo, e o limite padrão de um serviço costuma ser 1024. Aumente na unidade do systemd com `LimitNOFILE=65535`, como no exemplo logo abaixo da lista.
- **Nginx:** o Ubuntu vem com `worker_connections 768`, e cada conexão repassada à API conta duas vezes, uma com o cliente e outra com a aplicação.
- **Proteção:** limite a taxa de requisições por IP no Nginx com `limit_req`, principalmente em login e cadastro. Isso protege a CPU de rajadas e de robôs.

Para aumentar o limite de arquivos abertos sem editar a unidade original, crie um override com `sudo systemctl edit minha-api`, acrescente as linhas abaixo e reinicie o serviço. Confira o valor aplicado em `/proc/PID/limits`.

```
[Service]
LimitNOFILE=65535
```

## O banco de dados na conta

Na maioria das APIs, o banco é o gargalo antes da CPU da aplicação. Três pontos definem se ele cabe na mesma VPS e quanto ele pesa:

- **Pool de conexões:** o total de conexões ao banco é o tamanho do pool vezes o número de processos da API. Quatro processos com pool de 25 abrem 100 conexões, exatamente o limite padrão do PostgreSQL.
- **Consultas por requisição:** o padrão N+1, em que uma listagem dispara uma consulta por item, multiplica a latência. Um endpoint com 50 consultas sente cada milissegundo de distância até o banco.
- **Cache:** resultados que mudam pouco podem ficar no [Redis](https://streethosting.com.br/guias/vps/configurar-redis-vps-ubuntu), que também guarda sessões e filas de tarefas em segundo plano.

Com banco e API na mesma VPS, some a RAM que o banco precisa, que costuma ser a maior fatia. Como calcular essa parte está em [como escolher uma VPS para banco de dados](https://streethosting.com.br/guias/vps/escolher-vps-banco-de-dados).

## Medir antes de escolher

Nenhuma tabela substitui um teste de carga com a sua API. O k6 é uma ferramenta gratuita que simula usuários virtuais a partir de um script curto:

```
// teste.js
import http from "k6/http";
import { sleep } from "k6";

export default function () {
  http.get("https://api.seu-dominio.com.br/produtos");
  sleep(1);
}

// no terminal, de outra máquina
k6 run --vus 50 --duration 2m teste.js
```

Rode o teste a partir de outra máquina, nunca da própria VPS, senão o gerador de carga disputa CPU com a API. Aponte para um ambiente de teste ou para endpoints de leitura, aumente os usuários virtuais aos poucos e, enquanto isso, acompanhe a VPS com `htop` e `vmstat 1`.

- [ ] Latência p95 dentro da meta no pico esperado
- [ ] CPU abaixo de 70% no pico, deixando margem para rajadas
- [ ] Nenhum uso contínuo de swap
- [ ] Pool do banco sem requisições esperando conexão
- [ ] Taxa de erro zero durante o teste

Se o teste satura a CPU com poucos usuários, procure o endpoint mais caro antes de pensar em plano maior. Em produção, acompanhe esses números de forma contínua, com uma ferramenta como o Netdata.

## Tabela de dimensionamento

Os cenários abaixo consideram API, banco e cache na mesma VPS, que é como a maioria dos projetos começa. Use como ponto de partida e confirme com o teste de carga.

| Cenário | VPS Ryzen 9 9950X | VPS Xeon E5-2680 v4 |
| --- | --- | --- |
| Webhook, bot, MVP ou API interna | 1 vCPU, 2 GB: R$ 39,00 | 2 vCPU, 2 GB: R$ 23,00 |
| API de app com banco na mesma VPS | 2 vCPU, 4 GB: R$ 64,00 | 3 vCPU, 4 GB: R$ 40,00 |
| API em produção com Redis e fila | 4 vCPU, 8 GB: R$ 114,00 | 6 vCPU, 8 GB: R$ 74,00 |
| WebSocket com muitos usuários conectados | 6 vCPU, 16 GB: R$ 214,00 | 9 vCPU, 16 GB: R$ 142,00 |
| Vários serviços em Docker, SSR e workers | 8 vCPU, 24 GB: R$ 314,00 | 12 vCPU, 24 GB: R$ 210,00 |
| Alto volume com banco próprio pesado | 10 vCPU, 32 GB: R$ 414,00 | 15 vCPU, 32 GB: R$ 278,00 |

Repare que a linha Xeon dá mais vCPU e o mesmo tanto de RAM por um preço menor, enquanto a Ryzen entrega núcleos bem mais rápidos. A escolha entre elas depende do perfil da API, como mostra a última seção. A linha Budget com Ryzen 9 5900XT, listada na mesma página, está sem estoque no momento.

## Como escalar depois

O primeiro passo quase sempre é vertical: um plano maior. Na StreetHosting, o upgrade é feito pelo painel, cobra só a diferença proporcional do ciclo e aumenta memória, vCPU e disco, com um reinício da VM. Planeje o reinício para um horário de pouco movimento. Antes de subir, porém, confira o que costuma render mais:

- **Índices e consultas:** um índice que falta pode custar mais que dobrar a CPU.
- **Cache de respostas:** endpoints de leitura que mudam pouco saem do banco e vão para o Redis.
- **Trabalho fora da requisição:** email, notificação e processamento de arquivo vão para uma fila com worker separado.

Quando o vertical acaba ou você precisa de alta disponibilidade, o caminho é horizontal: várias instâncias da API atrás de um balanceador de carga. Isso exige uma API sem estado local: sessões no Redis, arquivos enviados em um armazenamento de objetos, como no guia de [armazenamento compatível com S3](https://streethosting.com.br/guias/vps/instalar-minio-vps), e banco em servidor próprio. Com mais de um servidor, o deploy manual vira problema, e vale automatizar com GitHub Actions.

## Ryzen ou Xeon para a sua API

A [VPS Ryzen 9 9950X](https://streethosting.com.br/vps/ryzen) é a escolha quando a latência de cada requisição depende da CPU: APIs em Node.js, renderização no servidor, serialização pesada, hashing de senha e processamento de imagem. Ela usa DDR5, chega a 5,7 GHz e vai de R$ 39,00 (1 vCPU, 2 GB, 20 GB NVMe) a R$ 814,00 (14 vCPU, 64 GB, 640 GB NVMe).

A [VPS Xeon](https://streethosting.com.br/vps/xeon) rende mais quando a API passa o tempo esperando: muitos workers de Python ou PHP, Java com muitas threads e APIs que são basicamente uma camada fina sobre o banco. Ela dá mais vCPU por real, de R$ 23,00 (2 vCPU, 2 GB) a R$ 550,00 (24 vCPU, 64 GB, 640 GB). O comparativo completo está em [VPS Ryzen ou Xeon](https://streethosting.com.br/guias/vps/vps-ryzen-vs-vps-xeon).

> **Dica**
>
> As duas linhas ficam em São Paulo, o que reduz a latência para usuários e integrações brasileiras, têm AntiDDoS incluso, que importa para qualquer API pública, e ativam em até 60 segundos. Se estiver em dúvida, comece pela menor opção que passa no seu teste de carga e suba pelo painel quando os números pedirem.

## Perguntas frequentes

### Quantos vCPU uma API precisa?

Uma API pequena, com banco na mesma VPS, roda bem com 2 vCPU. A conta real depende do runtime: Node.js usa um núcleo por processo, Python e PHP escalam com número de workers e Java e Go usam vários núcleos em um único processo. Meça com teste de carga antes de subir.

### Quanta RAM uma VPS para API precisa?

Some a memória de cada processo ou worker, a do banco de dados se ele estiver na mesma VPS, a do Redis e uns 500 MB para o sistema. APIs simples cabem em 2 a 4 GB; com banco, cache e fila juntos, 8 GB é um ponto de partida confortável.

### Ryzen ou Xeon para hospedar uma API?

Ryzen 9 9950X, com clock mais alto, reduz a latência de cada requisição e favorece Node.js, renderização no servidor e endpoints que processam muito. Xeon entrega mais vCPU por real e rende bem com muitos workers em Python, PHP ou Java e com APIs que passam o tempo esperando o banco.

### Quantas conexões simultâneas uma VPS aguenta?

O limite raramente é a VPS em si, e sim a configuração: limite de arquivos abertos do processo, worker_connections do Nginx, pool do banco e memória por conexão. Com esses ajustes, uma VPS pequena sustenta milhares de conexões ociosas, como em WebSocket.

### Quando escalar a API para mais de um servidor?

Quando o maior plano viável já não segura o pico, quando você precisa de alta disponibilidade ou quando o banco e a aplicação disputam recursos. Antes, otimize consultas e adicione cache, que costumam render mais que uma VPS maior.

## Guias relacionados

- [Como hospedar aplicação Node.js em VPS no Brasil](https://streethosting.com.br/guias/vps/hospedar-api-nodejs-vps-brasil.md)
- [Como hospedar API FastAPI na VPS com Gunicorn e Nginx](https://streethosting.com.br/guias/vps/hospedar-api-fastapi-vps.md)
- [Como escolher VPS para banco de dados: RAM, CPU e NVMe](https://streethosting.com.br/guias/vps/escolher-vps-banco-de-dados.md)
- [O que é balanceamento de carga e quando seu projeto precisa](https://streethosting.com.br/guias/infraestrutura/o-que-e-balanceamento-de-carga.md)
- [VPS Ryzen vs VPS Xeon: qual CPU escolher para o servidor](https://streethosting.com.br/guias/vps/vps-ryzen-vs-vps-xeon.md)

## Produtos citados

- https://streethosting.com.br/vps/ryzen
- https://streethosting.com.br/vps/xeon
- https://streethosting.com.br/vps

## Dados estruturados

```json
[
  {
    "@context": "https://schema.org",
    "@type": [
      "Article",
      "TechArticle"
    ],
    "headline": "VPS para API: dimensionar pelo runtime, pelas conexões e pelo banco",
    "name": "Como escolher VPS para API: CPU, RAM e conexões",
    "abstract": "Uma API em Node.js, uma em Python e uma em Java com o mesmo tráfego pedem VPS diferentes. Veja como o runtime, as conexões simultâneas e o banco de dados definem CPU e RAM, como medir antes de contratar e como crescer depois.",
    "description": "Descubra quanta CPU, RAM e conexões simultâneas a sua API precisa, como o runtime muda a conta e quando escalar, com planos Ryzen e Xeon reais.",
    "datePublished": "2026-09-28",
    "dateModified": "2026-09-28",
    "author": {
      "@type": "Organization",
      "name": "Equipe StreetHosting"
    },
    "publisher": {
      "@type": "Organization",
      "name": "StreetHosting",
      "url": "https://streethosting.com.br"
    },
    "inLanguage": "pt-BR",
    "mainEntityOfPage": {
      "@type": "WebPage",
      "@id": "https://streethosting.com.br/guias/vps/escolher-vps-para-api"
    }
  },
  {
    "@context": "https://schema.org",
    "@type": "FAQPage",
    "mainEntity": [
      {
        "@type": "Question",
        "name": "Quantos vCPU uma API precisa?",
        "acceptedAnswer": {
          "@type": "Answer",
          "text": "Uma API pequena, com banco na mesma VPS, roda bem com 2 vCPU. A conta real depende do runtime: Node.js usa um núcleo por processo, Python e PHP escalam com número de workers e Java e Go usam vários núcleos em um único processo. Meça com teste de carga antes de subir."
        }
      },
      {
        "@type": "Question",
        "name": "Quanta RAM uma VPS para API precisa?",
        "acceptedAnswer": {
          "@type": "Answer",
          "text": "Some a memória de cada processo ou worker, a do banco de dados se ele estiver na mesma VPS, a do Redis e uns 500 MB para o sistema. APIs simples cabem em 2 a 4 GB; com banco, cache e fila juntos, 8 GB é um ponto de partida confortável."
        }
      },
      {
        "@type": "Question",
        "name": "Ryzen ou Xeon para hospedar uma API?",
        "acceptedAnswer": {
          "@type": "Answer",
          "text": "Ryzen 9 9950X, com clock mais alto, reduz a latência de cada requisição e favorece Node.js, renderização no servidor e endpoints que processam muito. Xeon entrega mais vCPU por real e rende bem com muitos workers em Python, PHP ou Java e com APIs que passam o tempo esperando o banco."
        }
      },
      {
        "@type": "Question",
        "name": "Quantas conexões simultâneas uma VPS aguenta?",
        "acceptedAnswer": {
          "@type": "Answer",
          "text": "O limite raramente é a VPS em si, e sim a configuração: limite de arquivos abertos do processo, worker_connections do Nginx, pool do banco e memória por conexão. Com esses ajustes, uma VPS pequena sustenta milhares de conexões ociosas, como em WebSocket."
        }
      },
      {
        "@type": "Question",
        "name": "Quando escalar a API para mais de um servidor?",
        "acceptedAnswer": {
          "@type": "Answer",
          "text": "Quando o maior plano viável já não segura o pico, quando você precisa de alta disponibilidade ou quando o banco e a aplicação disputam recursos. Antes, otimize consultas e adicione cache, que costumam render mais que uma VPS maior."
        }
      }
    ]
  }
]
```