Bare metal próprio vs cloud terceirizada: a vantagem do hardware próprio

A maioria das PaaS modernas que você conhece — Railway, Render, Heroku, Fly.io, Vercel — não opera o próprio hardware. Eles rodam em cima de AWS, GCP ou Azure. Você paga pra eles, eles pagam pro hyperscaler, e o markup vai parar no seu cartão.

Isso é um detalhe arquitetural que ninguém anuncia em pricing page. Mas ele explica muita coisa: por que a fatura sobe imprevisivelmente, por que a latência tem teto, por que a soberania de dados é frágil quando o ferro físico está sob jurisdição de outro país.

A Upuai escolheu o caminho oposto: bare metal próprio, em datacenter brasileiro, sem subsidiária estrangeira na cadeia. Esse post explica o que essa decisão muda — em custo, em performance, em soberania, e em controle de produto.

A camada que ninguém te conta: onde sua PaaS realmente roda

Quando você sobe um app no Railway ou Render, o fluxo é mais ou menos esse:

Seu código vai pro GitHub.
A PaaS dispara um build na infra dela.
A PaaS coloca o container num cluster Kubernetes.
Esse cluster roda em EC2 (AWS), GCE (GCP) ou Azure VM.
Você paga a PaaS. Ela paga a AWS. Você nunca vê isso.

Esse modelo tem nome no mercado: managed PaaS sobre cloud público. Foi a inovação da Heroku em 2007 — pegar a complexidade do EC2 e esconder atrás de git push heroku main. Funcionou. Virou padrão.

O lado escuro do padrão: você está pagando dois margins. O AWS cobra seu custo + margem; a PaaS cobra o custo da AWS + a margem deles. Em geral, o segundo markup é onde mora a maior parte do “premium PaaS moderna”.

Pra um app de hobby, o markup é invisível e o conforto vale. Pra workloads de produção que crescem, o markup começa a doer — e você começa a pensar em sair pra “AWS pura”. Mas aí perde a UX, e o ciclo recomeça.

A pergunta natural é: dá pra ter UX moderna sem o markup duplo? A resposta é sim — você só precisa de uma PaaS que opere o próprio metal.

A diferença entre revender cloud e operar cloud

No mercado de infraestrutura, há três categorias bem diferentes:

Cloud público (hyperscaler): AWS, GCP, Azure. Operam datacenters próprios em escala global, vendem direto ao consumidor final.
PaaS sobre cloud público: Railway, Render, Vercel, Heroku, Fly. Pegam EC2/GCE e adicionam camada de UX. Conveniência sobre infraestrutura terceira.
PaaS bare-metal-próprio: Hetzner Cloud (com servidores físicos), Latitude.sh, Railway Metal (a iniciativa do Railway de migrar parte da carga pra metal próprio), e Upuai no Brasil.

A diferença entre 2 e 3 é onde mora o segredo de unit economics melhor:

Categoria 2 tem custo marginal alto. Toda nova carga consome EC2 — e EC2 é caro, especialmente em região fora dos EUA. Pra escalar a PaaS, a empresa precisa cobrar markup pra cobrir o custo da AWS + sua margem + provisões pra picos.
Categoria 3 tem custo de entrada alto (datacenter, ferro, network) mas custo marginal baixo. Adicionar mais um cliente é quase de graça enquanto houver capacidade ociosa. A PaaS controla a curva de capacidade e amortiza investimento ao longo do tempo.

Categoria 3 não é melhor em todos os cenários. Pra startup que vai operar globalmente desde o dia 1, categoria 2 (sobre AWS) faz sentido porque você precisa do alcance global e da elasticidade do hyperscaler. Pra startup BR que serve cliente BR, categoria 3 com datacenter BR é estrutural — você não precisa pagar pelo alcance global que não vai usar.

O que muda em custo quando você opera o metal

A economia muda nas três grandes linhas:

Compute

Em AWS, uma instância t3.medium (2 vCPU, 4 GB RAM) custa cerca de US$ 30/mês em sa-east-1 — esse é o custo na nota fiscal da PaaS. Se a PaaS cobra US$ 50/mês equivalente, ela tem 40% de margem. Se a AWS aumenta o preço (ou o câmbio sobe), a margem some.

Operando metal próprio, o custo da mesma capacidade é radicalmente menor. Servidor físico moderno tem 32-64 vCPU e 128-256 GB RAM. Dividido em containers, você roda dezenas de aplicações no mesmo ferro. O custo por container cai pra ordem de US$ 3-5/mês de custo direto — não US$ 30.

Esse delta é o que permite a Upuai vender Pro a R$ 99/mês com recursos equivalentes ao que Railway/Render cobram US$ 30-50.

Storage

Storage em AWS S3 é US$ 0,023/GB/mês — barato isoladamente. Mas o problema é egress: US$ 0,09/GB depois da franquia. Pra um SaaS com 500 GB de bandwidth/mês, isso vira US$ 45 escondidos.

Operando o próprio storage (MinIO ou similar em ferro próprio), o egress não tem custo marginal — é só largura de banda do datacenter. Por isso a Upuai zera egress: não está repassando custo escondido.

Suporte

PaaS sobre cloud público tem outra dependência: quando o cloud público tem outage, a PaaS também tem. Quando você abre ticket de suporte na PaaS, e o problema é AWS, a PaaS precisa abrir ticket na AWS — e te repassar a resposta.

Operando metal próprio, o time da PaaS é também o time de infra. Resposta de suporte de produção é direta. (Discutimos isso em Suporte em português + SLA brasileiro.)

O que muda em performance

Cloud público tem uma palavra técnica que ninguém da AWS/GCP gosta de pronunciar: noisy neighbor. Sua VM divide o hardware físico com outras VMs de outros clientes. Quando o vizinho roda um job de IO pesado, o seu IO sofre. Quando o vizinho consome CPU em burst, seu CPU degrada.

Hyperscalers mitigam isso com QoS, mas não eliminam. É inerente ao modelo de virtualização compartilhada em escala massiva.

Em bare metal próprio, você controla quem mora onde. A Upuai aloca containers em servidores físicos com isolamento de tenant — workloads pesadas são separadas, recursos garantidos por plano, NVMe direct attach pra latência de disco previsível.

Os números reais:

Latência de disco (P99): NVMe direct attach < 1ms; AWS EBS gp3 ~5-10ms; AWS EBS io2 ~3ms.
Latência de rede intra-DC: bare metal próprio ~0,3ms; AWS intra-AZ ~1-2ms.
CPU contention: bare metal alocado ~0% steal time; AWS t3.medium burstable pode ter até 30% steal time em peak hours.

Pra app web típico, essas diferenças são imperceptíveis. Pra workloads com IO intenso (database, cache, queue), a diferença é dramática.

O que muda em soberania

Aqui fica menos óbvio mas mais profundo. Quando sua PaaS roda em cima de AWS, mesmo numa região “Brasil” (sa-east-1, São Paulo):

A propriedade do ferro é da Amazon Web Services Inc., empresa US.
O contrato master é com a Amazon Web Services Brasil Serviços Ltda., subsidiária BR — mas com cláusulas que remetem à lei US.
O control plane (autenticação, billing, audit logs) roda nos EUA, não no Brasil. Mesmo seu workload em São Paulo, parte dos metadados sai do país.
CLOUD Act (US, 2018) obriga a Amazon Web Services Inc. a entregar dados a autoridades americanas mesmo quando esses dados estão fisicamente fora dos EUA. A subsidiária BR não muda isso.

A diferença com bare metal próprio operado por empresa brasileira:

Propriedade do ferro é brasileira, sob jurisdição BR direta.
O contrato é com a empresa BR, sob lei BR.
Control plane fica no Brasil — todos os bits ficam.
ANPD tem jurisdição direta, sem subsidiária estrangeira no meio.

Não é um detalhe ideológico — é gestão de risco contratual. Detalhamos isso em Soberania digital não é ideologia: é gestão de risco contratual.

O caso da Upuai: o ferro em BH/MG

A Upuai opera datacenter próprio em Belo Horizonte/MG. As escolhas estruturais:

Redundância A+B de energia: dois feeds independentes da concessionária + nobreaks + geradores. Continuidade durante quedas de energia.
Refrigeração eficiente: aproveitando o clima ameno de BH (média anual 21°C), reduz custo operacional.
Conectividade dual: dois provedores de trânsito IP independentes, com peering nacional via PTT-BH e conexão internacional via cabos submarinos de Fortaleza.
Storage tiered: NVMe para databases e cache (latência sub-1ms); HDDs em RAID pra object storage (volume + custo baixo).
Network determinística: switches dedicados, não compartilhados com outros clientes.

Detalhamos esse datacenter em O datacenter em Belo Horizonte: por que importa onde seus bits dormem.

A consequência prática pra você: latência sub-20ms pra 80% do território nacional, custo previsível em BRL, soberania de dados garantida por contrato e por física.

Quando bare metal não vence

Honestidade obrigatória — bare metal próprio não é resposta pra todo cenário:

Picos extremos de elasticidade (Black Friday 10×): hyperscalers têm capacidade quase infinita. Bare metal precisa de capacidade pré-provisionada. Pra workloads com picos imprevisíveis e extremos, cloud público continua sendo a escolha certa.
Multi-região global ativa-ativa: edge em 30+ países só faz sentido com hyperscaler. Você não vai operar 30 datacenters do zero.
Serviços managed muito específicos: Lambda, Kinesis, SQS, DynamoDB, Bedrock — esses produtos AWS não têm equivalente direto em PaaS bare-metal-próprio. Se seu app depende, fica no AWS.

Pra a maioria dos SaaS BR, bare metal próprio com UX moderna ganha. Pra os casos acima, cloud público continua ganhando.

Comparativo lado a lado

Critério	PaaS sobre AWS/GCP	PaaS bare-metal-próprio (Upuai)
Markup duplo (cloud + PaaS)	Sim — você paga dois	Não — markup único
Noisy neighbor (compartilhamento)	Sim, inerente ao modelo	Controlado via tenancy
Jurisdição do ferro	US (mesmo em região BR)	Brasil — direta
Latência intra-DC	1-2ms	~0,3ms
Egress	Cobrado (US$/GB)	Zero
Elasticidade extrema (10× pico)	Excelente	Limitada à capacidade do DC
Multi-região global	Trivial	Hoje só Brasil
Custo previsível em BRL	Não (USD + IOF + spread)	Sim — preço fixo em Real

Tradeoffs reais. Não existe 'PaaS perfeita' — existe a certa pro seu caso de uso.

Perguntas frequentes

Bare metal próprio é o mesmo que rodar em servidor dedicado? Não. Servidor dedicado (modelo dos anos 2000) é você administrar o servidor — patches, OS, monitoramento. Bare metal próprio operado pela Upuai significa que a Upuai opera o ferro. Pra você, a UX é igual a Railway/Vercel — git push e o app sobe. A diferença é estrutural, não operacional.

E se o datacenter da Upuai cair? Redundância A+B de energia, dois provedores de trânsito IP, blue-green deploy com auto-revert, backups automáticos com PITR pra bancos. Falhas de componente são esperadas e cobertas; falha catastrófica de datacenter é o risco que toda PaaS single-DC tem (incluindo Vercel single-region até 2022). Plano Enterprise inclui SLA contratual; planos menores seguem best-effort de SLA.

Posso confiar em provider brasileiro pra produção? Mesma pergunta que se fazia sobre AWS em 2010 (“provider americano? meus dados no exterior?”). A resposta hoje é a mesma de então: depende do provider. A Upuai opera com práticas de SRE de PaaS moderna — observabilidade contínua, deploys controlados, monitoramento 24/7, backups automáticos, postmortems públicos quando algo dá errado.

Quanto da diferença de custo vem do bare metal vs cloud, e quanto vem do câmbio? Roughly: do delta total entre AWS sa-east-1 e Upuai Pro (~13× num cenário típico), cerca de metade é câmbio + IOF + spread, e a outra metade é a diferença estrutural de operar metal próprio vs revender cloud. Os dois fatores se combinam.

Quando faz sentido eu ir direto pra AWS pura ao invés de PaaS bare-metal? Se você tem time DevOps maduro (3+ pessoas dedicadas), workload global, dependência de serviços managed específicos AWS, ou contrato Enterprise Discount Program já negociado. Pra times pequenos sem DevOps dedicado e workload BR-first, PaaS bare-metal-própria é a escolha melhor.

Pra entender melhor as outras dimensões dessa escolha, leia Latência sub-20ms: o KPI silencioso, O datacenter em Belo Horizonte e Soberania digital não é ideologia.