.NET · 10.0.402
Hosting .NET 24/7
Sube una minimal API, un servicio ASP.NET Core o un worker en C# y déjalo corriendo. La plataforma reconoce el proyecto por el .csproj o el .sln, ejecuta dotnet publish al construir la imagen y levanta el resultado en un contenedor aislado.
Quién diseñó .NET
Microsoft presentó .NET en 2000, y C# nació con él, bajo la arquitectura de Anders Hejlsberg, el mismo de Turbo Pascal y Delphi. Durante más de una década corrió solo en Windows; .NET Core 1.0, de 2016, abrió el código y trajo Linux y macOS, y en 2020 .NET 5 unificó las líneas en una sola.
Anders Hejlsberg
DBegley · CC BY 2.0
Lenguaje tipado, runtime gestionado
C# se compila a un lenguaje intermedio y se ejecuta con recolección de basura y compilación JIT. El compilador atrapa los errores de tipo antes de que el servicio arranque.
Multiplataforma y abierto
Desde .NET Core, el mismo código corre en Linux, macOS y Windows, con el desarrollo en GitHub. El contenedor Linux dejó de ser la excepción.
La web viene incluida
ASP.NET Core trae el servidor Kestrel, el enrutamiento, la inyección de dependencias y las minimal APIs. Una API completa cabe en pocas líneas de Program.cs.
Qué hace la plataforma por un proyecto .NET
El build y el contenedor corren por cuenta de la plataforma; tu código solo tiene que escuchar en el puerto correcto.
Detección por .csproj y .sln
Con un .csproj o un .sln en el zip o en el repositorio, la plataforma entiende que es .NET y elige el runtime sola. No escribes Dockerfile ni eliges imagen base.
dotnet publish en el build
La restauración de paquetes NuGet y la compilación ocurren mientras se construye la imagen, no en cada arranque. Un error de compilación aparece en el log del build en lugar de convertirse en un crash en producción.
Tope de RAM en el archivo de config
MEMORY define cuánta memoria puede ocupar el contenedor, y el panel muestra el uso real junto al tope. Si el proceso excede el límite, se cierra por OOM y el evento queda registrado en el log.
Auto-reinicio con freno
Una excepción sin tratar no deja el servicio caído: el proceso se reinicia solo, en cualquier plan. Si se rompe 5 veces en 10 minutos, la plataforma marca crash loop y apaga el auto-reinicio durante 24 horas. Salir con exit code 0 no dispara reinicio.
Qué ejecuta la gente en .NET aquí
Desde un servicio HTTP ligero hasta un proceso en segundo plano sin puerto alguno.
Minimal APIs y ASP.NET Core
Publica la aplicación para recibir un subdominio en vertraweb.app con TLS. ASP.NET Core ya escucha en el puerto de la plataforma, sin configuración: no hace falta definir ASPNETCORE_URLS ni UseUrls.
Workers con BackgroundService
Consumidor de cola, rutina periódica, integración con un servicio externo: un Worker Service corre como proceso sin puerto HTTP, con el MEMORY visible en el panel.
Bots de Discord y Telegram en C#
Discord.Net y Telegram.Bot corren como procesos de larga duración. El token va en las variables de entorno del panel, nunca en un appsettings.json dentro del zip.
Conector nativo con base gestionada
Un PostgreSQL 17 o un MySQL 8.0 creado en el mismo panel habla con Npgsql o Entity Framework Core por el host interno. TLS es obligatorio, y el certificado de cliente y la contraseña salen del panel directo a la connection string.
Versiones de .NET disponibles
La 10.0.402 es la recomendada y también la más reciente. Sin VERSION en el vertracloud.config, la aplicación arranca en la recomendada.
| Versión | vertracloud.config | Estado |
|---|---|---|
| 10.0.402 | VERSION=10.0 | RecomendadaMás reciente |
La configuración completa
El vertracloud.config es un archivo INI opcional en la raíz del proyecto. MAIN apunta al proyecto a publicar; VERSION elige la línea de .NET; MEMORY define el tope de RAM del contenedor.
NAME=minha-api
MAIN=MinhaApi.csproj
VERSION=10.0
MEMORY=512Un plan para cada etapa del proyecto
La memoria y el almacenamiento cambian según el plan; el lenguaje, no. Compara lo que abre cada plan y elige el que le sirve al proyecto hoy.
Comparar planesTambién corre aquí
Misma plataforma, mismo deploy, otro stack.
Preguntas frecuentes sobre hosting .NET
Versión, puerto y build: las dudas más frecuentes de quien sube .NET.
¿Qué versión de .NET puedo usar?
Hoy, la 10.0.402, que es la recomendada y la más reciente. Puedes declarar la línea con la clave VERSION en el vertracloud.config; sin ella, la aplicación arranca en la recomendada.
¿Tengo que compilar antes de enviar el zip?
No. Envía el código fuente con el .csproj o el .sln y deja que dotnet publish corra en el build de la plataforma, para Linux. Deja fuera las carpetas bin y obj del paquete: se rehacen y solo agrandan el zip, que tiene un límite de 100 MB.
La API arranca, pero el subdominio no responde.
ASP.NET Core escucha en el puerto de la plataforma sin configuración. Comprueba que la aplicación esté publicada en la web, lo que exige 512 MB de RAM y está disponible a partir del plan Pro, y que el código no fije otro puerto con UseUrls o ASPNETCORE_URLS.
Tengo una solución con varios proyectos. ¿Cuál se publica?
Apunta el MAIN al .csproj del proyecto ejecutable, el que tiene el Program.cs, o al .sln. Los demás proyectos de la solución entran como referencia y se compilan junto.
¿Cómo paso la connection string y otros secretos?
Por la pestaña de variables de entorno del panel: se inyectan en el contenedor al arrancar y quedan cifradas en reposo. ASP.NET Core lee las variables de entorno por su configuración estándar; un appsettings.json dentro del zip no es lugar para un secreto.
Sube tu servicio .NET hoy
Crea la cuenta, sube el código con el .csproj o el .sln, o conecta el repositorio de GitHub, y sigue el dotnet publish en la terminal del panel.
Crear cuenta