El Mejor Hosting para .NET en 2026 — Comparación Completa (Azure, AWS, Railway, Fly.io)

Elegir la plataforma de hosting equivocada para tu aplicación .NET es un error costoso — tanto en dinero como en tiempo de desarrollo. Esta guía cubre todas las opciones serias en 2026, con precios reales, experiencias de despliegue reales y una matriz de recomendaciones concreta al final.

Los precios a continuación fueron verificados en agosto de 2026 contra la página oficial de precios de cada proveedor (y, en el caso de Azure, la API de Retail Prices), para regiones de EE. UU. salvo que se indique lo contrario. La aplicación y cada configuración de despliegue de esta guía son archivos reales a los que puedes apuntar un CLI: samples/dotnet-hosting contiene una API mínima de .NET 10 junto con el fly.toml, railway.json, render.yaml, la especificación de DigitalOcean y el Bicep de Azure usados aquí, con una prueba de humo que verifica que la aplicación respete un PORT inyectado en tiempo de ejecución — la parte que la mayoría de los Dockerfiles copiados hace mal (ver la sección de Railway).

Los Contendientes

Seis plataformas que merecen tu atención para cargas de trabajo .NET:

• Azure App Service — el PaaS propio de Microsoft, con la integración más profunda para .NET
• AWS Elastic Beanstalk — la capa de PaaS administrado de Amazon sobre EC2
• Railway — un PaaS moderno orientado al desarrollador con configuración mínima
• Fly.io — plataforma centrada en contenedores con despliegue en el borde global
• Render.com — sucesor de Heroku con precios simples
• DigitalOcean App Platform — PaaS directo de un proveedor conocido

Azure App Service

Descripción General

Azure App Service es el hogar natural para las aplicaciones .NET. Microsoft lo construye y mantiene, el soporte de runtime es siempre de primera clase, y la integración con el ecosistema (Azure SQL, Key Vault, Managed Identity, Application Insights) no tiene comparación.

Despliegue

# Crear grupo de recursos y plan de 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
 
# Crear la aplicación web apuntando a .NET 10
az webapp create \
  --name myapp-unique-name \
  --resource-group myapp-rg \
  --plan myapp-plan \
  --runtime "DOTNETCORE:10.0"
 
# Desplegar desde una carpeta local
# Publicar, comprimir, desplegar — az webapp deploy quiere un ARCHIVO zip, no la carpeta
# publish; apuntar --src-path a un directorio falla con "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

En Windows, no construyas el zip con Compress-Archive de PowerShell — escribe las entradas del zip con separadores de barra invertida, y en cuanto tu salida de publish tiene una subcarpeta (wwwroot/, runtimes/), App Service en Linux falla el despliegue con un error de rsync en Kudu tipo failed to stat "/home/site/wwwroot/algo\archivo": Invalid argument (22). Me pasó exactamente eso desplegando el sample de este artículo. Windows incluye bsdtar (tar.exe, en System32), que produce zips correctos con barras normales. Usa * en lugar de . como argumento de archivos: con ., bsdtar antepone ./ a cada entrada — Kudu acepta ese zip, pero el Explorador de Windows lo muestra como vacío, lo que me costó un minuto de confusión.

Esta es la ejecución exacta del despliegue de el sample, no un ensayo:

Niveles de Precios

Planes Linux, East US, agosto de 2026 (API de Azure Retail Prices; el portal suele mostrar cifras redondeadas ligeramente diferentes):

Slots de Despliegue

Los slots de despliegue te permiten ejecutar un entorno de staging e intercambiarlo a producción con cero tiempo de inactividad:

# Crear un slot de staging
az webapp deployment slot create \
  --name myapp-unique-name \
  --resource-group myapp-rg \
  --slot staging
 
# Intercambiar staging a producción
az webapp deployment slot swap \
  --name myapp-unique-name \
  --resource-group myapp-rg \
  --slot staging \
  --target-slot production

CI/CD con 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: Aplicaciones .NET empresariales, equipos que ya están en Azure, aplicaciones que necesitan Azure SQL, Key Vault o Managed Identity.

Ten cuidado con: Los precios suben bruscamente entre B1 y S1. Arranques en frío en los niveles inferiores.

AWS Elastic Beanstalk

Descripción General

Elastic Beanstalk es la abstracción de PaaS de AWS sobre EC2. Obtienes más control que con Azure App Service, pero también más superficie de configuración. El soporte para .NET es sólido mediante las plataformas de Windows Server o Linux.

Despliegue

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

Precios

Elastic Beanstalk en sí es gratuito — pagas por las instancias EC2 subyacentes, los balanceadores de carga y el almacenamiento.

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

Añade ~$16.50/mes por un Application Load Balancer si lo necesitas (requerido para instancias múltiples), más cargos por uso de LCU.

Ten en cuenta que la famosa t3.micro gratuita de AWS por 12 meses ya no existe para cuentas nuevas: desde julio de 2025 la capa gratuita se basa en créditos — $100 al registrarte más hasta $100 adicionales por completar tareas de incorporación, que expiran a los 6 meses. Las cuentas creadas antes de esa fecha conservan el acuerdo antiguo de 12 meses.

Autoescalado

// .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: Equipos profundamente integrados en AWS, aplicaciones que necesitan control fino sobre EC2, cargas de trabajo con tráfico variable que necesitan optimización de costos mediante autoescalado.

Ten cuidado con: Curva de aprendizaje más pronunciada que Azure App Service. Expansión de configuración en .ebextensions.

Railway

Descripción General

Railway es la opción con la mejor experiencia de desarrollo de esta lista. Sube el código, obtén una URL. No se requieren manifiestos YAML para el uso básico. Ejecuta contenedores internamente y gestiona el enrutamiento, TLS y el escalado de forma transparente.

Despliegue

# Instalar Railway CLI
npm install -g @railway/cli
 
# Iniciar sesión e inicializar
railway login
railway init
 
# Añadir un Dockerfile o dejar que Railway detecte .NET automáticamente
# Luego desplegar
railway up

Un 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"]

Una trampa: Railway inyecta el puerto de escucha como variable de entorno PORT en tiempo de ejecución, y la línea de Dockerfile tan copiada ENV ASPNETCORE_URLS=http://+:${PORT:-8080} no la recoge — Docker resuelve ${...} en tiempo de build, dejando el 8080 fijo. En su lugar, lee PORT en Program.cs:

// Program.cs — respetar el PORT inyectado por la plataforma (Railway, Render, estilo Heroku)
var port = Environment.GetEnvironmentVariable("PORT");
if (!string.IsNullOrEmpty(port))
{
    builder.WebHost.UseUrls($"http://+:{port}");
}

La prueba de humo del ejemplo verifica exactamente esto: la aplicación se inicia con un PORT inyectado y debe responder en él, tanto localmente como dentro de la imagen del contenedor.

O usa un railway.json para la configuración (no hace falta startCommand — el ENTRYPOINT del Dockerfile lo cubre):

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

Desplegado con exactamente esa configuración, los logs de despliegue de Railway muestran el contrato funcionando de punta a punta — contenedor arriba, escuchando en el puerto inyectado, y la sonda /health respondiendo 200 antes de enrutar tráfico:

Precios

• Plan Hobby: $5/mes, que incluye $5 de crédito de uso mensual
• Plan Pro: $20/mes por workspace, incluye $20 de uso
• Tarifas de uso: ~$20 por vCPU-mes y ~$10 por GB-de-RAM-mes, facturado por segundo ($0.00000772/vCPU-s, $0.00000386/GB-s)
• Una API .NET pequeña típica: cabe dentro de los $5 incluidos del plan Hobby

Variables de Entorno

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

Veredicto

Ideal para: Desarrolladores independientes, startups, proyectos personales, equipos que quieren cero gestión de infraestructura. Excelente para APIs .NET respaldadas por Postgres.

Ten cuidado con: Funcionalidades empresariales menos maduras. Sin SLA para el plan Hobby.

Fly.io

Descripción General

Fly.io ejecuta tus contenedores en hardware en más de 30 regiones de todo el mundo. Es especialmente adecuado para aplicaciones sensibles a la latencia que necesitan ejecutarse cerca de los usuarios a nivel global.

Despliegue

# Instalar flyctl
curl -L https://fly.io/install.sh | sh
 
# Lanzar una nueva aplicación (detecta Dockerfile)
fly launch --name myapp --region iad
 
# Desplegar
fly deploy

La configuración 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

Precios

Fly descontinuó su asignación gratuita en octubre de 2024 — las antiguas "3 VMs compartidas gratis" solo sobreviven en cuentas preexistentes. Las organizaciones nuevas reciben una prueba gratuita corta (alrededor de $5 / 7 días) y luego pagan por segundo de tiempo de máquina. Los precios varían ligeramente según la región; aproximadamente:

• shared-cpu-1x 256 MB: ~$2/mes funcionando 24/7
• shared-cpu-1x 512 MB: ~$3.30/mes
• performance-1x 2 GB: ~$32/mes (la familia de CPU dedicada ahora son los SKUs performance-*)
• Volúmenes: $0.15/GB/mes; salida (egress) desde ~$0.02/GB (sin asignación gratuita de ancho de banda para organizaciones nuevas)

Multi-Región

# Añadir regiones
fly regions add lhr syd
 
# Escalar para tener al menos 1 máquina por región
fly scale count 2 --region lhr
fly scale count 2 --region syd

Gestión de Secretos

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

Veredicto

Ideal para: APIs globales, cargas de trabajo sensibles a la latencia, equipos con experiencia en contenedores que quieren distribución global a un costo razonable.

Ten cuidado con: El arranque/parada automático de máquinas añade latencia de arranque en frío cuando se escala a cero. Más orientado a operaciones que Railway. El Postgres administrado comienza en $38/mes — para una base de datos económica, combina el cómputo de Fly con un Postgres gratuito externo.

Render.com

Descripción General

Render es el reemplazo moderno más cercano a Heroku. Despliegues simples conectados a Git, Postgres administrado y precios sencillos.

Despliegue

# Render despliega desde Git automáticamente
# Solo conecta tu repositorio en el panel de control y configura:
# Build Command: dotnet publish -c Release -o ./publish
# Start Command: dotnet ./publish/MyApp.dll

O usa un Dockerfile (recomendado para .NET). Así se despliega el sample por esa vía — toda la configuración es un solo formulario; el único campo no obvio en un monorepo es Root Directory, que apunta el contexto de build de Docker a la carpeta correcta:

Precios

Veredicto

Ideal para: Proyectos personales, entornos de staging, equipos migrando desde Heroku.

Ten cuidado con: El comportamiento de suspensión de la capa gratuita, menos funcionalidades avanzadas que Railway o Fly.io.

DigitalOcean App Platform

Descripción General

DigitalOcean App Platform ofrece despliegues simples basados en contenedores con precios predecibles — sin facturas sorpresa por cobros basados en uso.

Despliegue

# Usando el CLI de 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

Precios

DigitalOcean reestructuró los precios de App Platform; los contenedores ahora se cobran por tamaño de instancia (todos con vCPUs compartidas en el rango bajo):

La capa gratuita cubre solo sitios estáticos — no hay opción gratuita de contenedores.

Veredicto

Ideal para: Equipos que quieren la simplicidad de Heroku con precios predecibles y un proveedor conocido.

Ten cuidado con: Menos integraciones específicas para .NET que Azure. Regiones limitadas en comparación con Fly.io.

¿Cuál Deberías Elegir? Matriz de Recomendaciones

Comparación de Rendimiento

Tiempos de arranque en frío (aproximados, VMs compartidas/en ráfaga, API mínima de .NET 10):

Comparación de Autoescalado

Resumen de Capas Gratuitas

Reflexiones Finales

Para la mayoría de los desarrolladores .NET en 2026, la decisión se reduce a tres opciones:

1. Azure App Service si estás en el ecosistema de Microsoft o necesitas funcionalidades empresariales
2. Railway si quieres el camino más rápido desde el código hasta una URL en producción
3. Fly.io si necesitas distribución global o contenedores siempre activos a un costo eficiente

Los tiempos de "usa Azure porque es .NET" han terminado. Railway y Fly.io ofrecen una experiencia de desarrollo convincente a menores costos para la mayoría de las cargas de trabajo. Evalúa en función de la experiencia de tu equipo, los requisitos de escala y los compromisos existentes con la nube.

Cada configuración de despliegue de esta guía es un archivo real en samples/dotnet-hosting — una API mínima que puedes desplegar en las seis plataformas sin cambios. Si el presupuesto es el factor decisivo, la forma más barata de hospedar una app .NET recorre las mismas plataformas de abajo hacia arriba desde $0, y las guías por plataforma profundizan más: Azure App Service, Railway, Fly.io y Render.

Lecturas adicionales

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