O Melhor Hosting para .NET em 2026 — Comparação Completa (Azure, AWS, Railway, Fly.io)

Escolher a plataforma de hospedagem errada para sua aplicação .NET é um erro caro — tanto em dinheiro quanto em tempo de desenvolvimento. Este guia cobre todas as opções sérias em 2026, com preços reais, experiências reais de deploy e uma matriz de recomendações concreta ao final.

Os preços abaixo foram verificados em agosto de 2026 na página oficial de preços de cada provedor (e, no caso do Azure, na API de Retail Prices), para regiões dos EUA salvo indicação em contrário. A aplicação e cada configuração de deploy deste guia são arquivos reais que você pode apontar para um CLI: samples/dotnet-hosting contém uma API mínima em .NET 10 junto com o fly.toml, railway.json, render.yaml, a especificação do DigitalOcean e o Bicep do Azure usados aqui, com um teste de fumaça que garante que a aplicação respeite um PORT injetado em tempo de execução — a parte que a maioria dos Dockerfiles copiados erra (veja a seção do Railway).

Os Concorrentes

Seis plataformas que merecem sua atenção para cargas de trabalho .NET:

• Azure App Service — o PaaS próprio da Microsoft, com a integração mais profunda para .NET
• AWS Elastic Beanstalk — a camada de PaaS gerenciado da Amazon sobre o EC2
• Railway — um PaaS moderno focado no desenvolvedor com configuração mínima
• Fly.io — plataforma centrada em contêineres com deploy na borda global
• Render.com — sucessor do Heroku com preços simples
• DigitalOcean App Platform — PaaS direto de um provedor familiar

Azure App Service

Visão Geral

O Azure App Service é o lar natural para aplicações .NET. A Microsoft o constrói e mantém, o suporte ao runtime é sempre de primeira classe, e a integração com o ecossistema (Azure SQL, Key Vault, Managed Identity, Application Insights) não tem igual.

Deploy

# Criar grupo de recursos e plano do App Service
az group create --name myapp-rg --location eastus
az appservice plan create --name myapp-plan --resource-group myapp-rg --sku B1 --is-linux
 
# Criar a aplicação web apontando para o .NET 10
az webapp create \
  --name myapp-unique-name \
  --resource-group myapp-rg \
  --plan myapp-plan \
  --runtime "DOTNETCORE:10.0"
 
# Fazer deploy a partir de uma pasta local
# Publicar, compactar, fazer deploy — az webapp deploy quer um ARQUIVO zip, não a pasta
# publish; apontar --src-path para um diretório falha com "not a valid local file path"
dotnet publish -c Release -o ./publish
cd ./publish && zip -r ../app.zip . && cd ..   # Windows: tar.exe -a -cf app.zip -C publish *
az webapp deploy \
  --resource-group myapp-rg \
  --name myapp-unique-name \
  --src-path ./app.zip \
  --type zip

No Windows, não monte o zip com o Compress-Archive do PowerShell — ele grava as entradas do zip com separadores de barra invertida, e assim que sua saída de publish tem uma subpasta (wwwroot/, runtimes/), o App Service no Linux falha o deploy com um erro de rsync no Kudu como failed to stat "/home/site/wwwroot/algo\arquivo": Invalid argument (22). Passei exatamente por isso fazendo o deploy do sample deste artigo. O Windows inclui o bsdtar (tar.exe, no System32), que produz zips corretos com barras normais. Use * em vez de . como argumento de arquivos: com ., o bsdtar prefixa cada entrada com ./ — o Kudu aceita esse zip, mas o Windows Explorer o exibe como vazio, o que me custou um minuto de confusão.

Esta é a execução exata do deploy de o sample, não um ensaio:

Camadas de Preço

Planos Linux, East US, agosto de 2026 (API de Azure Retail Prices; o portal costuma mostrar valores arredondados ligeiramente diferentes):

Slots de Deploy

Os slots de deploy permitem executar um ambiente de staging e trocá-lo com a produção sem nenhum tempo de inatividade:

# Criar um slot de staging
az webapp deployment slot create \
  --name myapp-unique-name \
  --resource-group myapp-rg \
  --slot staging
 
# Trocar staging com produção
az webapp deployment slot swap \
  --name myapp-unique-name \
  --resource-group myapp-rg \
  --slot staging \
  --target-slot production

CI/CD com GitHub Actions

# .github/workflows/deploy.yml
name: Deploy to Azure App Service
on:
  push:
    branches: [main]
 
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Setup .NET 10
        uses: actions/setup-dotnet@v4
        with:
          dotnet-version: '10.0.x'
      - name: Publish
        run: dotnet publish -c Release -o ./publish
      - name: Deploy to Azure
        uses: azure/webapps-deploy@v3
        with:
          app-name: myapp-unique-name
          publish-profile: ${{ secrets.AZURE_PUBLISH_PROFILE }}
          package: ./publish

Veredicto

Ideal para: Aplicações .NET corporativas, equipes que já estão no Azure, aplicações que precisam de Azure SQL, Key Vault ou Managed Identity.

Fique atento a: Os preços sobem bruscamente entre B1 e S1. Cold starts nas camadas inferiores.

AWS Elastic Beanstalk

Visão Geral

O Elastic Beanstalk é a abstração de PaaS da AWS sobre o EC2. Você tem mais controle do que com o Azure App Service, mas também mais superfície de configuração. O suporte ao .NET é sólido por meio das plataformas Windows Server ou Linux.

Deploy

# Instalar EB CLI
pip install awsebcli
 
# Inicializar e criar ambiente
eb init myapp --platform "dotnet-core-on-al2023" --region us-east-1
eb create myapp-prod --instance-type t3.small
 
# Fazer deploy
dotnet publish -c Release -o ./publish
cd ./publish
zip -r ../deploy.zip .
eb deploy

Preços

O Elastic Beanstalk em si é gratuito — você paga pelas instâncias EC2 subjacentes, pelos load balancers e pelo armazenamento.

Linux sob demanda, us-east-1, agosto de 2026:

Adicione ~$16.50/mês por um Application Load Balancer se necessário (obrigatório para múltiplas instâncias), mais cobranças por uso de LCU.

Observe que a famosa t3.micro gratuita da AWS por 12 meses não existe mais para novas contas: desde julho de 2025 a camada gratuita é baseada em créditos — $100 no cadastro mais até $100 adicionais por completar tarefas de onboarding, que expiram após 6 meses. Contas criadas antes dessa data mantêm o antigo acordo de 12 meses.

Autoscale

// .elasticbeanstalk/env.yaml
option_settings:
  aws:autoscaling:asg:
    MinSize: 1
    MaxSize: 4
  aws:autoscaling:trigger:
    MeasureName: CPUUtilization
    Unit: Percent
    UpperThreshold: 70
    LowerThreshold: 20

Veredicto

Ideal para: Equipes profundamente integradas na AWS, aplicações que precisam de controle granular sobre o EC2, cargas de trabalho com tráfego variável que precisam de otimização de custos via autoscale.

Fique atento a: Curva de aprendizado mais íngreme do que o Azure App Service. Proliferação de configurações em .ebextensions.

Railway

Visão Geral

O Railway é a opção com a melhor experiência de desenvolvimento desta lista. Faça push do código, receba uma URL. Nenhum manifesto YAML é necessário para uso básico. Ele executa contêineres internamente e gerencia roteamento, TLS e escalonamento de forma transparente.

Deploy

# Instalar Railway CLI
npm install -g @railway/cli
 
# Fazer login e inicializar
railway login
railway init
 
# Adicionar um Dockerfile ou deixar o Railway detectar o .NET automaticamente
# Em seguida, fazer deploy
railway up

Um Dockerfile mínimo para .NET 10:

FROM mcr.microsoft.com/dotnet/sdk:10.0 AS build
WORKDIR /src
COPY . .
RUN dotnet publish -c Release -o /app
 
FROM mcr.microsoft.com/dotnet/aspnet:10.0
WORKDIR /app
COPY --from=build /app .
ENTRYPOINT ["dotnet", "MyApp.dll"]

Uma armadilha: o Railway injeta a porta de escuta como variável de ambiente PORT em tempo de execução, e a linha de Dockerfile amplamente copiada ENV ASPNETCORE_URLS=http://+:${PORT:-8080} não a captura — o Docker resolve ${...} em tempo de build, fixando o 8080. Em vez disso, leia PORT no Program.cs:

// Program.cs — respeitar o PORT injetado pela plataforma (Railway, Render, estilo Heroku)
var port = Environment.GetEnvironmentVariable("PORT");
if (!string.IsNullOrEmpty(port))
{
    builder.WebHost.UseUrls($"http://+:{port}");
}

O teste de fumaça do exemplo garante exatamente isso: a aplicação é iniciada com um PORT injetado e precisa responder nele, tanto localmente quanto dentro da imagem do contêiner.

Ou use um railway.json para configuração:

{
  "$schema": "https://railway.app/railway.schema.json",
  "build": {
    "builder": "DOCKERFILE",
    "dockerfilePath": "Dockerfile"
  },
  "deploy": {
    "healthcheckPath": "/health",
    "healthcheckTimeout": 300,
    "restartPolicyType": "ON_FAILURE"
  }
}

Implantado com exatamente essa configuração, os logs de deploy do Railway mostram o contrato funcionando de ponta a ponta — contêiner no ar, escutando na porta injetada, e a sonda /health respondendo 200 antes de rotear tráfego:

Preços

• Plano Hobby: $5/mês, que inclui $5 de crédito de uso mensal
• Plano Pro: $20/mês por workspace, inclui $20 de uso
• Taxas de uso: ~$20 por vCPU-mês e ~$10 por GB-de-RAM-mês, cobradas por segundo ($0.00000772/vCPU-s, $0.00000386/GB-s)
• Uma API .NET pequena típica: cabe dentro dos $5 incluídos no plano Hobby

Variáveis de Ambiente

railway variables --set "DATABASE_URL=Server=...;Database=...;..." --set "ASPNETCORE_ENVIRONMENT=Production"

Veredicto

Ideal para: Desenvolvedores independentes, startups, projetos pessoais, equipes que querem zero gerenciamento de infraestrutura. Excelente para APIs .NET com Postgres.

Fique atento a: Funcionalidades corporativas menos maduras. Sem SLA para o plano Hobby.

Fly.io

Visão Geral

O Fly.io executa seus contêineres em hardware em mais de 30 regiões ao redor do mundo. É especialmente adequado para aplicações sensíveis à latência que precisam rodar próximas dos usuários globalmente.

Deploy

# Instalar flyctl
curl -L https://fly.io/install.sh | sh
 
# Lançar uma nova aplicação (detecta Dockerfile)
fly launch --name myapp --region iad
 
# Fazer deploy
fly deploy

A configuração fly.toml:

app = "myapp"
primary_region = "iad"
 
[build]
  dockerfile = "Dockerfile"
 
[env]
  ASPNETCORE_ENVIRONMENT = "Production"
  ASPNETCORE_URLS = "http://+:8080"
 
[http_service]
  internal_port = 8080
  force_https = true
  auto_stop_machines = true
  auto_start_machines = true
  min_machines_running = 0
 
[[vm]]
  memory = "512mb"
  cpu_kind = "shared"
  cpus = 1

Preços

O Fly descontinuou sua cota gratuita em outubro de 2024 — as antigas "3 VMs compartilhadas grátis" só sobrevivem em contas preexistentes. Novas organizações recebem um teste gratuito curto (cerca de $5 / 7 dias) e depois pagam por segundo de tempo de máquina. Os preços variam ligeiramente por região; aproximadamente:

• shared-cpu-1x 256 MB: ~$2/mês rodando 24/7
• shared-cpu-1x 512 MB: ~$3,30/mês
• performance-1x 2 GB: ~$32/mês (a família de CPU dedicada agora são os SKUs performance-*)
• Volumes: $0,15/GB/mês; saída (egress) a partir de ~$0,02/GB (sem cota gratuita de banda para novas organizações)

Multi-Região

# Adicionar regiões
fly regions add lhr syd
 
# Escalar para ter pelo menos 1 máquina por região
fly scale count 2 --region lhr
fly scale count 2 --region syd

Gerenciamento de Segredos

fly secrets set DATABASE_URL="..."
fly secrets set JWT_SECRET="..."

Veredicto

Ideal para: APIs globais, cargas de trabalho sensíveis à latência, equipes experientes com contêineres que querem distribuição global a um custo razoável.

Fique atento a: O auto-stop/start de máquinas adiciona latência de cold start ao escalar para zero. Mais voltado para operações do que o Railway. O Postgres gerenciado começa em $38/mês — para um banco de dados barato, combine a computação do Fly com um Postgres gratuito externo.

Render.com

Visão Geral

O Render é o substituto moderno mais próximo do Heroku. Deploys simples conectados ao Git, Postgres gerenciado e preços diretos.

Deploy

# O Render faz deploy a partir do Git automaticamente
# Basta conectar seu repositório no painel e configurar:
# Build Command: dotnet publish -c Release -o ./publish
# Start Command: dotnet ./publish/MyApp.dll

Ou use um Dockerfile (recomendado para .NET). É assim que o sample é implantado por esse caminho — toda a configuração é um único formulário; o único campo não óbvio em um monorepo é o Root Directory, que aponta o contexto de build do Docker para a pasta certa:

Preços

Veredicto

Ideal para: Projetos pessoais, ambientes de staging, equipes migrando do Heroku.

Fique atento a: O comportamento de suspensão da camada gratuita, menos funcionalidades avançadas do que Railway ou Fly.io.

DigitalOcean App Platform

Visão Geral

O DigitalOcean App Platform oferece deploys simples baseados em contêineres com preços previsíveis — sem surpresas na fatura por cobranças baseadas em uso.

Deploy

# Usando o CLI do doctl
doctl apps create --spec app.yaml

# app.yaml
name: myapp
region: nyc
services:
  - name: api
    dockerfile_path: Dockerfile
    github:
      repo: yourorg/yourrepo
      branch: main
      deploy_on_push: true
    instance_size_slug: basic-xxs
    instance_count: 1
    http_port: 8080
    envs:
      - key: ASPNETCORE_ENVIRONMENT
        value: Production

Preços

O DigitalOcean reestruturou os preços do App Platform; os contêineres agora são cobrados por tamanho de instância (todos com vCPUs compartilhadas na faixa de entrada):

A camada gratuita cobre apenas sites estáticos — não há opção gratuita de contêineres.

Veredicto

Ideal para: Equipes que querem a simplicidade do Heroku com preços previsíveis e um provedor familiar.

Fique atento a: Menos integrações específicas para .NET do que o Azure. Regiões limitadas em comparação com o Fly.io.

Qual Você Deve Escolher? Matriz de Recomendações

Comparação de Desempenho

Tempos de cold start (aproximados, VMs compartilhadas/com burst, API mínima do .NET 10):

Comparação de Autoscale

Resumo das Camadas Gratuitas

Considerações Finais

Para a maioria dos desenvolvedores .NET em 2026, a decisão se resume a três opções:

1. Azure App Service se você está no ecossistema Microsoft ou precisa de funcionalidades corporativas
2. Railway se você quer o caminho mais rápido do código para uma URL em produção
3. Fly.io se você precisa de distribuição global ou contêineres always-on com custo eficiente

Os tempos de "use Azure porque é .NET" acabaram. Railway e Fly.io oferecem uma experiência de desenvolvimento convincente a custos menores para a maioria das cargas de trabalho. Avalie com base na experiência da sua equipe, nos requisitos de escala e nos compromissos existentes com a nuvem.

Cada configuração de deploy deste guia é um arquivo real em samples/dotnet-hosting — uma API mínima que você pode fazer deploy nas seis plataformas sem alterações. Se o orçamento for o fator decisivo, a forma mais barata de hospedar uma app .NET percorre as mesmas plataformas de baixo para cima a partir de $0, e os guias por plataforma vão mais fundo: Azure App Service, Railway, Fly.io e Render.

Leituras adicionais

• Azure App Service pricing (Linux)
• Fly.io pricing
• Render pricing