La Forma más Barata de Alojar una App .NET en 2026

Alojar una app .NET de forma económica en 2026 es genuinamente posible — pero cada opción de bajo presupuesto viene con concesiones que debes entender antes de hacer un despliegue en producción. Esta guía cubre el espectro completo, desde completamente gratuito hasta aproximadamente $13/mes, con cifras concretas y evaluaciones honestas de cada plataforma.

Cada precio a continuación fue verificado en agosto de 2026 contra la página oficial de precios del proveedor (las cifras de Azure contra la Retail Prices API). Los archivos de configuración de esta guía son archivos reales y desplegables — la unidad systemd, el Caddyfile, el Dockerfile, el fly.toml y el Bicep viven en samples/dotnet-hosting, apuntando a una única API .NET 10 mínima con una prueba de humo.

Opciones Verdaderamente Gratuitas

El hosting gratuito existe, pero está muy limitado o requiere cierto esfuerzo de infraestructura de tu parte.

Oracle Cloud Always Free

El nivel Always Free de Oracle Cloud es el cómputo gratuito más generoso disponible en 2026. Obtienes:

• 2 VMs AMD Compute (VM.Standard.E2.1.Micro): 1 OCPU + 1 GB RAM cada una
• 4 VMs Arm Ampere A1 Compute: hasta 4 OCPUs y 24 GB RAM en total (puedes usar los 4 en una sola VM)
• 2 Block Volumes con un total de 200 GB
• 10 GB de Object Storage
• Sin vencimiento de tarjeta de crédito en el nivel gratuito (a diferencia de los trials de 12 meses de AWS/GCP/Azure)

La opción Ampere A1 es particularmente atractiva — una sola VM con 4 OCPUs y 24 GB RAM ejecuta .NET 10 muy bien. El inconveniente es que es arquitectura Arm64, por lo que necesitas publicar para linux-arm64.

# Publicar un binario self-contained linux-arm64
dotnet publish -c Release -r linux-arm64 --self-contained true \
  -p:PublishSingleFile=true -o ./publish
 
# O apuntar al runtime dependiente del framework (más pequeño, requiere .NET runtime instalado)
dotnet publish -c Release -r linux-arm64 --self-contained false -o ./publish

Para ejecutarlo como un servicio systemd en la VM de Oracle:

# /etc/systemd/system/myapp.service
[Unit]
Description=Mi App .NET
After=network.target
 
[Service]
WorkingDirectory=/opt/myapp
ExecStart=/opt/myapp/MyApp
Restart=always
RestartSec=10
# Ejecutar como usuario no-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

También necesitarás configurar un proxy inverso (nginx o Caddy) delante de la app:

# /etc/nginx/sites-available/myapp
server {
    listen 80;
    server_name tudominio.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;
    }
}

Lo que sacrificas: Administras la VM tú mismo — actualizaciones del SO, parches de seguridad, reglas de firewall, copias de seguridad. No hay escalado automático ni experiencia PaaS gestionada. Para un proyecto hobby o herramienta interna es un excelente trato; para un producto orientado a clientes necesitas invertir tiempo en operaciones.

Azure App Service F1 (Nivel Gratuito)

El nivel F1 de Azure es gratuito para siempre pero tiene límites estrictos:

El límite de 60 minutos-CPU/día es el mayor problema. Una app web moderadamente activa puede alcanzarlo antes del mediodía y tu app devolverá errores 403 el resto del día. F1 es adecuado únicamente para desarrollo y pruebas.

Los dominios personalizados y SSL no están disponibles en F1. Estás limitado a tuapp.azurewebsites.net y solo HTTP (aunque el propio dominio azurewebsites.net se sirve con HTTPS por el balanceador de carga de Azure).

// El SKU F1 en Bicep — observa los límites
resource appServicePlan 'Microsoft.Web/serverfarms@2022-03-01' = {
  name: 'myplan-free'
  location: resourceGroup().location
  sku: {
    name: 'F1'  // Gratuito: 60 minutos-cpu/día, sin dominio personalizado
    tier: 'Free'
  }
}

Render Nivel Gratuito

El nivel gratuito de Render te ofrece un servicio web con:

• 0.1 CPU
• 512 MB RAM
• Entra en reposo tras 15 minutos de inactividad
• Despertar en la primera solicitud (el cold start puede tardar entre 30 y 60 segundos)
• Dominios personalizados compatibles (con TLS gratuito)
• 750 horas de instancia gratuitas por mes

El límite mensual de 750 horas significa que una instancia siempre activa no lo superaría (720 horas en un mes de 30 días, así que una instancia es suficiente). El comportamiento de reposo es la limitación real — apropiado para proyectos hobby, no para nada que requiera tiempos de respuesta consistentes. Render lo dice de frente — este banner vive permanentemente en el dashboard del servicio gratuito:

# Dockerfile para el nivel gratuito de 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"]

Render inyecta el puerto de escucha como una variable de entorno PORT en tiempo de ejecución. No intentes capturarlo con ENV ASPNETCORE_URLS=http://+:${PORT:-8080} en el Dockerfile — Docker resuelve ${...} en tiempo de build, así que el valor por defecto queda fijado y el valor inyectado por Render se ignora (yo mismo publiqué ese error exacto en una versión anterior de este artículo). Léelo en Program.cs en su lugar:

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

La prueba de humo del ejemplo inicia la app con un PORT inyectado y verifica que responda ahí. Y este es el mismo código en vivo en el nivel gratuito de Render — listeningOn reporta el puerto 10000, que solo el PORT inyectado por Render pudo haber establecido:

# render.yaml — infraestructura como código para 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 almacenamiento, sin copias de seguridad, expira 30 días después de su creación

El Nivel de $4–$5/Mes

Aquí es donde las cosas se vuelven genuinamente útiles para proyectos paralelos y herramientas internas.

Railway Plan Hobby — $5/Mes en Crédito

El plan Hobby de Railway cuesta $5/mes y te da $5 en crédito de uso de recursos. Si tu app es pequeña, puede que ni siquiera consumas todo el crédito.

Precios de recursos en Railway (facturados por segundo):

• CPU: $0.00000772/vCPU-segundo — aproximadamente $20 por vCPU-mes
• RAM: $0.00000386/GB-segundo — aproximadamente $10 por GB-mes

Una API .NET mínima con un uso promedio de 0.1 vCPU y 256 MB RAM cuesta aproximadamente:

CPU:  0.1 vCPU * ~$20/vCPU-mes = ~$2.00/mes
RAM:  0.25 GB  * ~$10/GB-mes   = ~$2.50/mes
Total: ~$4.50/mes  (dentro de los $5 incluidos en el plan Hobby)

Railway soporta despliegues Docker y tiene sólida integración con GitHub. Haz push a tu rama principal y se despliega automáticamente.

# Dockerfile para Railway — PORT es inyectado por Railway en tiempo de ejecución,
# y la app lo lee en Program.cs (mira la sección de Render arriba para saber por qué
# una línea ENV ${PORT:-8080} NO funcionaría)
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 — archivo de configuración opcional en la raíz del repositorio
{
  "$schema": "https://railway.app/railway.schema.json",
  "build": {
    "builder": "DOCKERFILE",
    "dockerfilePath": "Dockerfile"
  },
  "deploy": {
    "healthcheckPath": "/health",
    "healthcheckTimeout": 300,
    "restartPolicyType": "ON_FAILURE",
    "restartPolicyMaxRetries": 3
  }
}

Exactamente esta configuración — la app de ejemplo con ese railway.json — está desplegada y respondiendo en un dominio de Railway:

Las bases de datos incrementan el costo: Railway Postgres se factura como uso ordinario (RAM a ~$10/GB-mes más un pequeño cargo de volumen de ~$0.16/GB-mes). Una instancia pequeña siempre activa que usa ~1 GB RAM queda alrededor de $10–13/mes — mucho más allá de los $5 incluidos en el plan Hobby, así que para un stack económico combina el cómputo de Railway con un Postgres externo gratuito como Neon.

Fly.io — ~$4/Mes para una App Pequeña

Fly.io cobra por segundo de tiempo de máquina — pagas solo mientras tu app está en ejecución. Para apps .NET (regiones de EE. UU./UE; los precios varían ligeramente según la región):

• shared-cpu-1x (256 MB RAM): ~$2/mes si corre 24/7
• Almacenamiento en volumen (para SQLite o almacenamiento de archivos): $0.15/GB/mes, así que un volumen de 3 GB cuesta $0.45/mes
• Ancho de banda de salida: ~$0.02/GB en Norteamérica y Europa — no hay asignación gratuita de ancho de banda para organizaciones nuevas

Una app pequeña típica en Fly.io con un volumen de 3 GB corre alrededor de $2.50/mes. Las bases de datos son donde Fly dejó de ser barato: Managed Postgres empieza en $38/mes, así que con este presupuesto combina el cómputo de Fly con un Postgres externo gratuito como Neon.

# fly.toml
app = "my-dotnet-app"
primary_region = "iad"  # us-east — elige la región más cercana a tus usuarios
 
[build]
  dockerfile = "Dockerfile"
 
[env]
  ASPNETCORE_ENVIRONMENT = "Production"
  ASPNETCORE_URLS = "http://+:8080"
 
[http_service]
  internal_port = 8080
  force_https = true
  auto_stop_machines = true   # detener cuando esté inactivo para ahorrar costo
  auto_start_machines = true  # iniciar en la primera solicitud (cold start)
  min_machines_running = 0    # poner en 1 para evitar cold starts (cuesta más)
 
[checks]
  [checks.health]
    grace_period = "10s"
    interval = "30s"
    method = "GET"
    path = "/health"
    timeout = "5s"
 
[[mounts]]
  source = "myapp_data"
  destination = "/data"

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

El Nivel de $7–$10/Mes

Este nivel te ofrece rendimiento consistente sin cold starts y generalmente incluye mejor soporte y SLAs.

Render Starter — $7/Mes

El plan Starter de Render elimina los mayores problemas del nivel gratuito:

El salto de 0.1 a 0.5 CPU marca una diferencia notable para apps .NET, que tienden a ser más intensivas en CPU que sus equivalentes en Node.js durante el arranque y el procesamiento de solicitudes.

DigitalOcean App Platform — $10/Mes

El contenedor de $10 del App Platform de DigitalOcean te da 1 GiB de RAM en un vCPU compartido con 100 GiB de transferencia, siempre activo, con precios planos predecibles — sin medidor de uso que vigilar. (El nivel de $5 reduce la RAM a la mitad, a 512 MiB, lo cual es viable para una minimal API ligera pero queda justo una vez que EF Core y algunos servicios en segundo plano están cargados.)

Si en cambio encuentras throttling de CPU en el nivel compartido de Fly, más RAM en shared-cpu-1x cuesta alrededor de $5/GB/mes antes de saltar a la familia performance-*, que empieza alrededor de $32/mes — en ese punto las plataformas anteriores suelen ser la mejor opción.

Azure App Service — La Opción Real más Económica

Si quieres una experiencia PaaS gestionada adecuada en Azure con SLA, la opción más económica es el plan B1 Basic.

Plan App Service B1 Basic

B1 soporta dominios personalizados, SSL y la función "Always On" que previene los cold starts. Es el nivel mínimo para cualquier cosa orientada a producción en Azure.

// Plantilla Bicep para App Service B1
resource appServicePlan 'Microsoft.Web/serverfarms@2022-03-01' = {
  name: 'myplan-basic'
  location: resourceGroup().location
  sku: {
    name: 'B1'   // Nivel Basic — plan más barato con Always On + dominio personalizado
    tier: 'Basic'
  }
  kind: 'linux'
  properties: {
    reserved: true  // requerido 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   // previene cold starts — no disponible en F1
      http20Enabled: true
      minTlsVersion: '1.2'
    }
    httpsOnly: true
  }
}

Para despliegues .NET en Azure App Service desde GitHub Actions:

# .github/workflows/deploy.yml
name: Desplegar en 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: Desplegar en 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 — A Veces Más Barato que B1

Azure Container Apps tiene un modelo de precios basado en consumo que puede superar a B1 para apps de bajo tráfico:

• Gratuito: 180,000 vCPU-segundos, 360,000 GiB-segundos y 2 millones de solicitudes por mes por suscripción
• Después del límite gratuito: $0.000024/vCPU-segundo activo, $0.000003/GiB-segundo, $0.40 por millón de solicitudes

Para una app que maneja 1,000 solicitudes/día con 100ms de tiempo de respuesta promedio, puede que ni siquiera salgas del nivel gratuito. Para una app que corre continuamente (24/7), Container Apps costará más que 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       # asignación mínima
          memory: "0.5Gi"
        env:
          - name: ASPNETCORE_ENVIRONMENT
            value: Production
          - name: ConnectionStrings__Default
            secretRef: db-connection
    scale:
      minReplicas: 0    # escalar a cero cuando está inactivo (ahorra costo, agrega cold start)
      maxReplicas: 3

Costos Adicionales de Base de Datos

El costo de hosting es solo parte de la ecuación. La mayoría de las apps necesitan una base de datos, y eso cambia los números significativamente.

Para la mayoría de los proyectos paralelos .NET, Neon es la mejor opción gratuita de Postgres — sin expiración, escala a cero y tiene una cadena de conexión amigable para .NET que funciona con EF Core sin configuración adicional. Dos sorpresas de 2026 que vale la pena conocer: la oferta gratuita de Azure SQL ahora es permanente (antes era un trial de 12 meses), y PlanetScale — durante mucho tiempo la opción de "sin nivel gratuito, mínimo de $39" — ahora empieza en $5.

// Formato de cadena de conexión en appsettings.json para Neon
// Usa ?sslmode=require para Neon (y la mayoría de Postgres gestionados)
{
  "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 con Npgsql + Neon
builder.Services.AddDbContext<AppDbContext>(options =>
    options.UseNpgsql(
        builder.Configuration.GetConnectionString("Default"),
        npgsqlOptions =>
        {
            // Neon serverless puede tener breves interrupciones de conexión
            // EnableRetryOnFailure gestiona fallos transitorios automáticamente
            npgsqlOptions.EnableRetryOnFailure(
                maxRetryCount: 3,
                maxRetryDelay: TimeSpan.FromSeconds(5),
                errorCodesToAdd: null);
        }));

Cold Starts: Lo que Realmente Significan para .NET

Los cold starts en .NET son peores que en Node.js o Go porque la inicialización del CLR, la compilación JIT y la configuración del contenedor de inyección de dependencias ocurren en el arranque.

Tiempos típicos de cold start para una app ASP.NET Core mínima en .NET 10:

Para minimizar el impacto de cold start en .NET:

// Program.cs — minimizar tiempo de arranque para entornos de contenedores
// Usar AddDbContextPool en lugar de AddDbContext para reutilizar conexiones
builder.Services.AddDbContextPool<AppDbContext>(options =>
    options.UseNpgsql(connectionString));
 
// Evitar trabajo pesado en el constructor — diferir al primer uso
// Usar IHostedService para inicialización en segundo plano si es necesario
builder.Services.AddHostedService<DatabaseMigrator>();
 
// Habilitar compilación ReadyToRun en .csproj para reducir tiempo JIT
// <PublishReadyToRun>true</PublishReadyToRun>

<!-- .csproj — optimizar para cold start -->
<PropertyGroup>
  <!-- Pre-compila a código nativo al publicar, reduciendo JIT al arrancar -->
  <PublishReadyToRun>true</PublishReadyToRun>
  <!-- Recortar assemblies no utilizados — reduce tamaño de imagen, arranque de contenedor más rápido -->
  <PublishTrimmed>true</PublishTrimmed>
  <!-- Para que el recorte funcione de forma fiable, usar publicación self-contained -->
  <SelfContained>true</SelfContained>
</PropertyGroup>

Tabla Completa de Comparación de Costos

Matriz de Recomendaciones

Elige según tu caso de uso:

Recomendación Concreta

Para la mayoría de los desarrolladores que construyen un proyecto paralelo .NET en 2026, la combinación Fly.io + Neon es el punto óptimo:

• Fly.io shared-cpu-1x con min_machines_running = 1: ~$2/mes
• Plan gratuito de Neon Postgres (0.5 GB, sin expiración): $0
• Total: ~$2–4/mes, sin cold starts, dominio personalizado, HTTPS

Cuando superes el nivel gratuito de Neon o necesites más cómputo, actualiza de forma incremental: el plan Launch de Neon es pago por uso sin mínimo mensual, y más RAM en Fly cuesta alrededor de $5/GB/mes.

Si ya estás en el ecosistema Azure, salta el App Service B1 Basic y considera primero Azure Container Apps con mínimo de réplicas = 0. Para apps de muy bajo tráfico (unos pocos cientos de solicitudes/día), puede que permanezcas dentro de la asignación mensual gratuita indefinidamente.

Evita Azure App Service F1 para cualquier cosa que no sean despliegues temporales de dev/test. El límite diario de 60 minutos de CPU te afectará antes de lo que esperas.

Resumen

Cada archivo de configuración de arriba — la unidad systemd, el Caddyfile, el Dockerfile, el fly.toml, el railway.json, el render.yaml y el Bicep — es un archivo real en samples/dotnet-hosting, todos apuntando a una única API .NET 10 desplegable. Para la comparación de características plataforma por plataforma en presupuestos más altos, consulta El Mejor Hosting para .NET.

Lecturas adicionales

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