A Forma mais Barata de Hospedar uma App .NET em 2026

Hospedar uma app .NET de forma econômica em 2026 é genuinamente possível — mas cada opção de baixo orçamento vem com concessões que você precisa entender antes de fazer um deploy em produção. Este guia cobre o espectro completo, desde completamente gratuito até aproximadamente $13/mês, com números concretos e avaliações honestas de cada plataforma.

Cada preço abaixo foi verificado em agosto de 2026 contra a página oficial de preços do provedor (os números do Azure contra a Retail Prices API). Os arquivos de configuração deste guia são arquivos reais e implantáveis — a unidade systemd, o Caddyfile, o Dockerfile, o fly.toml e o Bicep vivem em samples/dotnet-hosting, apontando para uma única API .NET 10 mínima com um teste de fumaça.

Opções Verdadeiramente Gratuitas

Hospedagem gratuita existe, mas é fortemente limitada ou requer algum esforço de infraestrutura da sua parte.

Oracle Cloud Always Free

O nível Always Free do Oracle Cloud é o cómputo gratuito mais generoso disponível em 2026. Você obtém:

• 2 VMs AMD Compute (VM.Standard.E2.1.Micro): 1 OCPU + 1 GB RAM cada
• 4 VMs Arm Ampere A1 Compute: até 4 OCPUs e 24 GB RAM no total (você pode usar todos os 4 em uma única VM)
• 2 Block Volumes totalizando 200 GB
• 10 GB de Object Storage
• Sem expiração de cartão de crédito no nível gratuito (diferente dos trials de 12 meses da AWS/GCP/Azure)

A opção Ampere A1 é particularmente atrativa — uma única VM com 4 OCPUs e 24 GB RAM executa .NET 10 muito bem. O inconveniente é que é arquitetura Arm64, então você precisa publicar para linux-arm64.

# Publicar um binário self-contained linux-arm64
dotnet publish -c Release -r linux-arm64 --self-contained true \
  -p:PublishSingleFile=true -o ./publish
 
# Ou usar o runtime dependente do framework (menor, requer o runtime .NET instalado)
dotnet publish -c Release -r linux-arm64 --self-contained false -o ./publish

Para executá-lo como um serviço systemd na VM da Oracle:

# /etc/systemd/system/myapp.service
[Unit]
Description=Minha App .NET
After=network.target
 
[Service]
WorkingDirectory=/opt/myapp
ExecStart=/opt/myapp/MyApp
Restart=always
RestartSec=10
# Executar como usuário não-root
User=www-data
Environment=ASPNETCORE_ENVIRONMENT=Production
Environment=ASPNETCORE_URLS=http://+:5000
 
[Install]
WantedBy=multi-user.target

sudo systemctl enable myapp
sudo systemctl start myapp

Você também precisará configurar um proxy reverso (nginx ou Caddy) na frente da app:

# /etc/nginx/sites-available/myapp
server {
    listen 80;
    server_name seudominio.com;
 
    location / {
        proxy_pass         http://localhost:5000;
        proxy_http_version 1.1;
        proxy_set_header   Upgrade $http_upgrade;
        proxy_set_header   Connection keep-alive;
        proxy_set_header   Host $host;
        proxy_cache_bypass $http_upgrade;
        proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header   X-Forwarded-Proto $scheme;
    }
}

O que você abre mão: Você gerencia a VM por conta própria — atualizações do SO, patches de segurança, regras de firewall, backups. Não há auto-scaling e nem experiência PaaS gerenciada. Para um projeto hobby ou ferramenta interna é um excelente negócio; para um produto voltado a clientes você precisa investir tempo em operações.

Azure App Service F1 (Nível Gratuito)

O nível F1 do Azure é gratuito para sempre, mas tem limites rígidos:

O limite de 60 minutos-CPU/dia é o maior problema. Uma app web moderadamente ativa pode atingi-lo antes do meio-dia e sua app retornará erros 403 pelo resto do dia. F1 é adequado apenas para desenvolvimento e testes.

Domínios personalizados e SSL não estão disponíveis no F1. Você fica limitado a suaapp.azurewebsites.net e apenas HTTP (embora o próprio domínio azurewebsites.net seja servido com HTTPS pelo load balancer do Azure).

// O SKU F1 em Bicep — observe os limites
resource appServicePlan 'Microsoft.Web/serverfarms@2022-03-01' = {
  name: 'myplan-free'
  location: resourceGroup().location
  sku: {
    name: 'F1'  // Gratuito: 60 minutos-cpu/dia, sem domínio personalizado
    tier: 'Free'
  }
}

Render Nível Gratuito

O nível gratuito do Render oferece um serviço web com:

• 0.1 CPU
• 512 MB RAM
• Entra em repouso após 15 minutos de inatividade
• Acorda na primeira requisição (o cold start pode levar de 30 a 60 segundos)
• Domínios personalizados suportados (com TLS gratuito)
• 750 horas de instância gratuitas por mês

O limite mensal de 750 horas significa que uma instância sempre ativa não o excederia (720 horas em um mês de 30 dias, então uma instância é suficiente). O comportamento de repouso é a limitação real — adequado para projetos hobby, não para nada que precise de tempos de resposta consistentes. O Render é direto sobre isso — este banner fica permanentemente no dashboard do serviço gratuito:

# Dockerfile para o nível gratuito do Render
FROM mcr.microsoft.com/dotnet/sdk:10.0-alpine AS build
WORKDIR /src
COPY ["MyApp.csproj", "."]
RUN dotnet restore
COPY . .
RUN dotnet publish -c Release -o /app/publish
 
FROM mcr.microsoft.com/dotnet/aspnet:10.0-alpine AS final
WORKDIR /app
COPY --from=build /app/publish .
EXPOSE 8080
ENTRYPOINT ["dotnet", "MyApp.dll"]

O Render injeta a porta de escuta como uma variável de ambiente PORT em tempo de execução. Não tente capturá-la com ENV ASPNETCORE_URLS=http://+:${PORT:-8080} no Dockerfile — o Docker resolve ${...} em tempo de build, então o valor padrão fica gravado e o valor injetado pelo Render é ignorado (eu mesmo publiquei exatamente esse bug em uma versão anterior deste artigo). Em vez disso, leia a variável no Program.cs:

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

O teste de fumaça do exemplo inicia a app com um PORT injetado e verifica que ela responde ali. E este é o mesmo código ao vivo no nível gratuito do Render — listeningOn reporta a porta 10000, que só o PORT injetado pelo Render poderia ter definido:

# render.yaml — infraestrutura como código para o Render
services:
  - type: web
    name: my-dotnet-app
    runtime: docker
    plan: free
    healthCheckPath: /health
    envVars:
      - key: ASPNETCORE_ENVIRONMENT
        value: Production
      - key: ConnectionStrings__Default
        fromDatabase:
          name: my-postgres-db
          property: connectionString
 
databases:
  - name: my-postgres-db
    plan: free  # 1 GB de armazenamento, sem backups, expira 30 dias após a criação

O Nível de $4–$5/Mês

Aqui as coisas se tornam genuinamente úteis para projetos paralelos e ferramentas internas.

Railway Plano Hobby — $5/Mês em Crédito

O plano Hobby do Railway custa $5/mês e oferece $5 em crédito de uso de recursos. Se sua app for pequena, você pode nem mesmo consumir todo o crédito.

Precificação de recursos no Railway (cobrada por segundo):

• CPU: $0.00000772/vCPU-segundo — cerca de $20 por vCPU-mês
• RAM: $0.00000386/GB-segundo — cerca de $10 por GB-mês

Uma API .NET mínima com uso médio de 0.1 vCPU e 256 MB RAM custa aproximadamente:

CPU:  0.1 vCPU * ~$20/vCPU-mês = ~$2.00/mês
RAM:  0.25 GB  * ~$10/GB-mês   = ~$2.50/mês
Total: ~$4.50/mês  (dentro dos $5 incluídos no plano Hobby)

Railway suporta deploys Docker e tem boa integração com GitHub. Faça push para sua branch principal e o deploy acontece automaticamente.

# Dockerfile para Railway — PORT é injetado pelo Railway em tempo de execução,
# e a app o lê no Program.cs (veja a seção do Render acima para entender por que
# uma linha ENV ${PORT:-8080} NÃO funcionaria)
FROM mcr.microsoft.com/dotnet/sdk:10.0 AS build
WORKDIR /src
COPY ["MyApp.csproj", "."]
RUN dotnet restore
COPY . .
RUN dotnet publish -c Release -o /app/publish
 
FROM mcr.microsoft.com/dotnet/aspnet:10.0 AS final
WORKDIR /app
COPY --from=build /app/publish .
EXPOSE 8080
ENTRYPOINT ["dotnet", "MyApp.dll"]

// railway.json — arquivo de configuração opcional na raiz do repositório
{
  "$schema": "https://railway.app/railway.schema.json",
  "build": {
    "builder": "DOCKERFILE",
    "dockerfilePath": "Dockerfile"
  },
  "deploy": {
    "healthcheckPath": "/health",
    "healthcheckTimeout": 300,
    "restartPolicyType": "ON_FAILURE",
    "restartPolicyMaxRetries": 3
  }
}

Exatamente esta configuração — a app de exemplo com esse railway.json — está implantada e respondendo em um domínio do Railway:

Os bancos de dados incrementam o custo: o Postgres do Railway é cobrado como uso comum (RAM a ~$10/GB-mês mais uma pequena cobrança de volume de ~$0.16/GB-mês). Uma instância pequena sempre ativa usando ~1 GB de RAM fica em torno de $10–13/mês — muito além dos $5 incluídos no plano Hobby, então para um stack econômico combine o cómputo do Railway com um Postgres externo gratuito como o Neon.

Fly.io — ~$4/Mês para uma App Pequena

O Fly.io cobra por segundo de tempo de máquina — você paga apenas enquanto sua app está em execução. Para apps .NET (regiões dos EUA/UE; os preços variam um pouco por região):

• shared-cpu-1x (256 MB RAM): ~$2/mês se rodar 24/7
• Armazenamento em volume (para SQLite ou armazenamento de arquivos): $0.15/GB/mês, então um volume de 3 GB custa $0.45/mês
• Largura de banda de saída: ~$0.02/GB na América do Norte e na Europa — não há franquia gratuita de largura de banda para organizações novas

Uma app pequena típica no Fly.io com um volume de 3 GB custa cerca de $2.50/mês. Os bancos de dados são onde o Fly deixou de ser barato: o Managed Postgres começa em $38/mês, então neste orçamento combine o cómputo do Fly com um Postgres externo gratuito como o Neon.

# fly.toml
app = "my-dotnet-app"
primary_region = "iad"  # us-east — escolha a região mais próxima dos seus usuários
 
[build]
  dockerfile = "Dockerfile"
 
[env]
  ASPNETCORE_ENVIRONMENT = "Production"
  ASPNETCORE_URLS = "http://+:8080"
 
[http_service]
  internal_port = 8080
  force_https = true
  auto_stop_machines = true   # parar quando inativo para economizar custo
  auto_start_machines = true  # iniciar na primeira requisição (cold start)
  min_machines_running = 0    # definir como 1 para evitar cold starts (custa mais)
 
[checks]
  [checks.health]
    grace_period = "10s"
    interval = "30s"
    method = "GET"
    path = "/health"
    timeout = "5s"
 
[[mounts]]
  source = "myapp_data"
  destination = "/data"

# Fazer deploy no Fly.io
fly auth login
fly launch --dockerfile Dockerfile --name my-dotnet-app --region iad
fly deploy

O Nível de $7–$10/Mês

Este nível oferece desempenho consistente sem cold starts e geralmente inclui melhor suporte e SLAs.

Render Starter — $7/Mês

O plano Starter do Render elimina os maiores problemas do nível gratuito:

O salto de 0.1 para 0.5 CPU faz uma diferença notável para apps .NET, que tendem a ser mais intensivas em CPU que equivalentes em Node.js durante a inicialização e o processamento de requisições.

DigitalOcean App Platform — $10/Mês

O container de $10 do App Platform da DigitalOcean oferece 1 GiB de RAM em um vCPU compartilhado com 100 GiB de transferência, sempre ativo, com preço fixo previsível — sem medidor de uso para vigiar. (O nível de $5 reduz a RAM pela metade, para 512 MiB, o que é viável para uma minimal API enxuta, mas fica apertado quando o EF Core e alguns serviços em background estão carregados.)

Se, em vez disso, você encontrar throttling de CPU no nível compartilhado do Fly, mais RAM no shared-cpu-1x custa cerca de $5/GB/mês antes de pular para a família performance-*, que começa em torno de $32/mês — nesse ponto, as plataformas acima costumam ser o melhor negócio.

Azure App Service — A Opção Real mais Econômica

Se você quiser uma experiência PaaS gerenciada adequada no Azure com SLA, a opção mais econômica é o plano B1 Basic.

Plano App Service B1 Basic

B1 suporta domínios personalizados, SSL e o recurso "Always On" que previne cold starts. É o nível mínimo para qualquer coisa voltada a produção no Azure.

// Template Bicep para App Service B1
resource appServicePlan 'Microsoft.Web/serverfarms@2022-03-01' = {
  name: 'myplan-basic'
  location: resourceGroup().location
  sku: {
    name: 'B1'   // Nível Basic — plano mais barato com Always On + domínio personalizado
    tier: 'Basic'
  }
  kind: 'linux'
  properties: {
    reserved: true  // obrigatório para Linux
  }
}
 
resource appService 'Microsoft.Web/sites@2022-03-01' = {
  name: 'my-dotnet-app'
  location: resourceGroup().location
  properties: {
    serverFarmId: appServicePlan.id
    siteConfig: {
      linuxFxVersion: 'DOTNETCORE|10.0'
      alwaysOn: true   // previne cold starts — não disponível no F1
      http20Enabled: true
      minTlsVersion: '1.2'
    }
    httpsOnly: true
  }
}

Para deploys .NET no Azure App Service a partir do GitHub Actions:

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

Azure Container Apps — Às Vezes Mais Barato que o B1

O Azure Container Apps tem um modelo de precificação baseado em consumo que pode superar o B1 para apps de baixo tráfego:

• Gratuito: 180.000 vCPU-segundos, 360.000 GiB-segundos e 2 milhões de requisições por mês por assinatura
• Após a franquia gratuita: $0.000024/vCPU-segundo ativo, $0.000003/GiB-segundo, $0.40 por milhão de requisições

Para uma app que processa 1.000 requisições/dia com 100ms de tempo médio de resposta, você pode nem sair do nível gratuito. Para uma app rodando continuamente (24/7), Container Apps custará mais que o B1.

# Azure Container Apps — containerapp.yaml
properties:
  managedEnvironmentId: /subscriptions/.../managedEnvironments/my-env
  configuration:
    ingress:
      external: true
      targetPort: 8080
    secrets:
      - name: db-connection
        value: "Server=...;Database=...;..."
  template:
    containers:
      - name: my-dotnet-app
        image: myregistry.azurecr.io/my-dotnet-app:latest
        resources:
          cpu: 0.25       # alocação mínima
          memory: "0.5Gi"
        env:
          - name: ASPNETCORE_ENVIRONMENT
            value: Production
          - name: ConnectionStrings__Default
            secretRef: db-connection
    scale:
      minReplicas: 0    # escalar para zero quando inativo (economiza custo, adiciona cold start)
      maxReplicas: 3

Custos Adicionais de Banco de Dados

O custo de hospedagem é apenas parte da equação. A maioria das apps precisa de um banco de dados, e isso muda os números significativamente.

Para a maioria dos projetos paralelos .NET, o Neon é a melhor opção gratuita de Postgres — sem expiração, escala para zero e tem uma string de conexão amigável para .NET que funciona com EF Core sem configuração adicional. Duas surpresas de 2026 que valem a pena conhecer: a oferta gratuita do Azure SQL agora é permanente (antes era um trial de 12 meses), e o PlanetScale — por muito tempo a opção de "sem nível gratuito, mínimo de $39" — agora começa em $5.

// Formato de string de conexão em appsettings.json para o Neon
// Use ?sslmode=require para o Neon (e a maioria dos Postgres gerenciados)
{
  "ConnectionStrings": {
    "Default": "Host=ep-xyz.us-east-2.aws.neon.tech;Database=mydb;Username=user;Password=pass;SSL Mode=Require;Trust Server Certificate=true"
  }
}

// Program.cs — EF Core com Npgsql + Neon
builder.Services.AddDbContext<AppDbContext>(options =>
    options.UseNpgsql(
        builder.Configuration.GetConnectionString("Default"),
        npgsqlOptions =>
        {
            // O Neon serverless pode ter breves interrupções de conexão
            // EnableRetryOnFailure gerencia falhas transitórias automaticamente
            npgsqlOptions.EnableRetryOnFailure(
                maxRetryCount: 3,
                maxRetryDelay: TimeSpan.FromSeconds(5),
                errorCodesToAdd: null);
        }));

Cold Starts: O que Realmente Significam para .NET

Os cold starts em .NET são piores do que em Node.js ou Go porque a inicialização do CLR, a compilação JIT e a configuração do container de injeção de dependências ocorrem no startup.

Tempos típicos de cold start para uma app ASP.NET Core mínima no .NET 10:

Para minimizar o impacto de cold start em .NET:

// Program.cs — minimizar tempo de startup para ambientes de container
// Usar AddDbContextPool em vez de AddDbContext para reutilizar conexões
builder.Services.AddDbContextPool<AppDbContext>(options =>
    options.UseNpgsql(connectionString));
 
// Evitar trabalho pesado no construtor — adiar para o primeiro uso
// Usar IHostedService para inicialização em background se necessário
builder.Services.AddHostedService<DatabaseMigrator>();
 
// Habilitar compilação ReadyToRun no .csproj para reduzir tempo JIT
// <PublishReadyToRun>true</PublishReadyToRun>

<!-- .csproj — otimizar para cold start -->
<PropertyGroup>
  <!-- Pré-compila para código nativo no momento da publicação, reduzindo JIT no startup -->
  <PublishReadyToRun>true</PublishReadyToRun>
  <!-- Remover assemblies não utilizados — reduz tamanho da imagem, startup do container mais rápido -->
  <PublishTrimmed>true</PublishTrimmed>
  <!-- Para o trimming funcionar de forma confiável, usar publicação self-contained -->
  <SelfContained>true</SelfContained>
</PropertyGroup>

Tabela Completa de Comparação de Custos

Matriz de Recomendações

Escolha com base no seu caso de uso:

Recomendação Concreta

Para a maioria dos desenvolvedores construindo um projeto paralelo .NET em 2026, a combinação Fly.io + Neon é o ponto ideal:

• Fly.io shared-cpu-1x com min_machines_running = 1: ~$2/mês
• Plano gratuito do Neon Postgres (0.5 GB, sem expiração): $0
• Total: ~$2–4/mês, sem cold starts, domínio personalizado, HTTPS

Quando você superar o nível gratuito do Neon ou precisar de mais cómputo, faça upgrades incrementais: o plano Launch do Neon é pagamento por uso sem mínimo mensal, e mais RAM no Fly custa cerca de $5/GB/mês.

Se você já está no ecossistema Azure, pule o App Service B1 Basic e considere primeiro o Azure Container Apps com mínimo de réplicas = 0. Para apps de tráfego realmente baixo (algumas centenas de requisições/dia), você pode permanecer dentro da franquia mensal gratuita indefinidamente.

Evite o Azure App Service F1 para qualquer coisa além de deploys temporários de dev/test. O limite diário de 60 minutos de CPU vai te surpreender mais cedo do que você espera.

Resumo

Cada arquivo de configuração acima — a unidade systemd, o Caddyfile, o Dockerfile, o fly.toml, o railway.json, o render.yaml e o Bicep — é um arquivo real em samples/dotnet-hosting, todos apontando para uma única API .NET 10 implantável. Para a comparação de recursos plataforma por plataforma em orçamentos maiores, veja O Melhor Hosting para .NET.

Leituras adicionais

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