Deploy .NET applications

A .NET application runs on Sevalla as an application: Sevalla builds an image from your Git repository with the .NET SDK, then runs the published assemblies as processes. The web process serves HTTP with ASP.NET Core’s Kestrel server, background workers run hosted services or queue consumers, and jobs run Entity Framework Core migrations before each deployment. C#, F# and Visual Basic projects all build the same way.

Framework guides

ASP.NET Core

Deploy a minimal API on .NET 10 with PostgreSQL, an EF Core migrations bundle and a health check.

Blazor

Deploy a Blazor Web App with interactive server rendering and Data Protection keys in PostgreSQL.

How .NET applications run on Sevalla

Part	On Sevalla
Build	Ingot, Sevalla’s builder, by default. It recognizes a .NET application by a project file (`.csproj`, `.fsproj` or `.vbproj`) at the root of the build path, a solution file there that lists one, or projects in `src/<name>/`. With several projects, it builds the one whose assembly the start command runs, otherwise the only web project; test projects don’t count.
Package manager	NuGet. Ingot restores from the project files alone, so the restore layer is reused while only code changes, and adds `--locked-mode` when the project has a `packages.lock.json`. A project with a lock file and Razor components restores from the whole source instead: the SDK adds the package of Blazor’s scripts, which the lock file lists, only when it sees `.razor` files.
.NET version	The `TargetFramework` of the project, such as `net10.0`, or .NET 10, Ingot’s default line, when it can’t read one. See Pin the .NET version.
Publish	`dotnet publish -c Release -p:UseAppHost=false`: portable assemblies that the image runs with `dotnet`. Ingot turns off `PublishAot`, `PublishReadyToRun`, `PublishSingleFile`, `PublishTrimmed` and `SelfContained` and says so in the build log. To publish otherwise, set `build` in `ingot.json` to a command that publishes to `/app/publish`.
Images	The .NET SDK image (`mcr.microsoft.com/dotnet/sdk:10.0-noble`) builds; the ASP.NET Core image (`aspnet:10.0-noble`) runs a web project, and the smaller .NET runtime image (`runtime:10.0-noble`) runs anything else, such as a worker service. Both include ICU and time zone data, so cultures and time zones work.
Start command	`dotnet /app/<AssemblyName>.dll`, shown in the build plan’s Start row. To run something else, add a `web` entry to a `Procfile`, set `start` in `ingot.json`, or set the web process’s Custom start command on the Processes tab. See Set the start command.
Port	Ingot points `ASPNETCORE_HTTP_PORTS` at the `PORT` environment variable when the application starts, so Kestrel listens on all interfaces on the web process’s port, `8080` by default. `urls`, `http_ports`, `https_ports` or `Kestrel:Endpoints` in `appsettings.json` override it, and the build log warns about them.
Proxy headers	Ingot sets `ASPNETCORE_FORWARDEDHEADERS_ENABLED=true`, so ASP.NET Core takes the scheme and the client’s address from the `X-Forwarded-Proto` and `X-Forwarded-For` headers of Sevalla’s proxy: `Request.Scheme` is `https`, and HTTPS redirection and HSTS work.
Environment	`Production`, because `ASPNETCORE_ENVIRONMENT` isn’t set. Every environment variable is also in the application’s configuration; `ConnectionStrings__Default` sets `ConnectionStrings:Default`.
Concurrency	Kestrel serves requests on the .NET thread pool, and .NET sizes its garbage collector and thread pool to the instance’s memory and CPU, so there’s no worker count to set.
Migrations	A job with the start policy Before deployment that runs an EF Core migrations bundle, for example `/app/efbundle`. If it fails, the deployment fails and the previous version keeps running. Ingot never runs migrations itself.
Background work	A background worker process that runs a worker service or a queue consumer from the same image, with its own start command.
Scheduled tasks	A cron job whose start command runs a console entry point of the application.
Databases	PostgreSQL, MySQL, MariaDB, Redis or Valkey on Sevalla, reached over an internal connection that adds the connection details as environment variables. Npgsql and the MySQL providers take connection strings of keys and values, so build them from `DB_HOST`, `DB_PORT`, `DB_DATABASE`, `DB_USERNAME` and `DB_PASSWORD` rather than `DB_URL`.
Files	The filesystem resets on every deployment, and that includes ASP.NET Core’s Data Protection keys: keep them in the database when the application uses antiforgery tokens or cookies. Keep uploads in object storage.
Other build strategies	A Dockerfile, or another build strategy, on the application’s Settings tab

Every process (web, worker, cron job and job) runs from the same image, each with its own start command. See Processes.

Pin the .NET version

The project’s TargetFramework is the version pin: a project that targets net10.0 builds with the .NET 10 SDK and runs on the .NET 10 runtime, because .NET runs an application only on the major version it targets. Ingot reads the version from the first of these that’s set:

The INGOT_DOTNET_VERSION environment variable, or versions.dotnet in ingot.json.
sdk.version in global.json, with its rollForward policy.
The newest TargetFramework (or TargetFrameworks) among the project and the projects it references.
.NET 10, Ingot’s default line, when nothing is set.

Ingot builds .NET 10, 9 and 8. A framework it has no image for fails the build, for example Storefront.csproj targets net11.0, which this Ingot release has no image for. The SDK can be newer than the framework a project targets, never older, and the application always runs on the runtime of its TargetFramework. A line such as 10 builds on Microsoft’s 10.0 images, which move to each patch release, so every new build picks up security fixes. The build plan’s .NET row shows the version and where it came from. You don’t need a global.json. If you have one, Ingot applies it as the dotnet command does. Microsoft’s SDK images carry the newest feature band of each line, such as the .NET 10 SDK 10.0.403. When the rollForward policy of global.json doesn’t allow that SDK, Ingot downloads the newest SDK Microsoft still services that the policy allows, checks its SHA-512 checksum, and builds with it. With the default policy, this global.json allows the 10.0.1xx SDKs:

global.json

{
  "sdk": {
    "version": "10.0.100"
  }
}

The build plan shows the SDK in its own row:

Build log

╭─ ■ ASP.NET Core · .NET 10 ────────────────────────────────────╮
│ .NET       10                          global.json "10.0.100" │
│ SDK        10.0.114                    global.json "10.0.100" │
│ Project    Storefront.csproj           the only project       │
│ Framework  ASP.NET Core                Storefront.csproj      │
│ Start      dotnet /app/Storefront.dll  Storefront.csproj      │
├─ Image ───────────────────────────────────────────────────────┤
│ Build      mcr.microsoft.com/dotnet/sdk:10.0-noble            │
│ Runtime    mcr.microsoft.com/dotnet/aspnet:10.0-noble         │
│ User       1000:1000                                          │
│ Init       tini                                               │
│ Port       $PORT, default 8080                                │
╰──────────────────────────────────────────────── Ingot v0.4.1 ─╯

When no SDK that Microsoft services matches, the build fails, for example with

global.json asks for SDK 10.0.200, and its rollForward policy doesn't allow 10.0.403 or 10.0.114, the .NET 10 SDKs Microsoft services

. Set rollForward to latestFeature, or sdk.version to one of the SDKs the message lists. If global.json sets sdk.paths, include "$host$", so the SDK in the image can be used. See Set the language version.

Build with a Dockerfile

A Dockerfile for a .NET application on Sevalla builds in two stages: it restores and publishes with Microsoft’s SDK image, then copies only the published output into the ASP.NET Core runtime image of the same 10.0 line, which has the /bin/sh that start commands and the web terminal need. It runs as the image’s numeric app user (USER 1654), sets ASPNETCORE_FORWARDEDHEADERS_ENABLED=true, and points ASPNETCORE_HTTP_PORTS at the PORT variable in its command before it hands process 1 to dotnet, which handles SIGTERM itself. The guides show it whole: ASP.NET Core and Blazor.

Get started

Migrate

AI

JavaScript

Python

PHP

Ruby

Go

Rust

Java and Kotlin

.NET

Elixir

Static site generators

Deploy .NET applications

Framework guides

ASP.NET Core

Blazor

How .NET applications run on Sevalla

Pin the .NET version

Build with a Dockerfile

​Framework guides

ASP.NET Core

Blazor

​How .NET applications run on Sevalla

​Pin the .NET version

​Build with a Dockerfile

Framework guides

How .NET applications run on Sevalla

Pin the .NET version

Build with a Dockerfile