Deploy .NET and ASP.NET Core on Nodion

Deploy .NET and ASP.NET Core step by step

1. One project at the root, or DOTNET_PROJECT Nodion publishes the one .csproj or .fsproj in the base directory, framework-dependent. With several projects, or a solution whose projects sit in subfolders, set DOTNET_PROJECT to the web project's path with the Build flag on the Environment tab; the root still needs a .sln or global.json so Nodion detects .NET. Pointing the base directory at the project folder only works if it references no projects outside it, because the build sees nothing above that folder. Build variable

   DOTNET_PROJECT=src/MyApp.Web/MyApp.Web.csproj

2. Leave the address to Nodion Nodion starts the app with ASPNETCORE_URLS=http://0.0.0.0:$PORT. Remove hard-coded URLs such as app.Run("http://localhost:5000") and Kestrel endpoints in appsettings.json, which take precedence over it. An API without a page at / needs a health endpoint; set its path as the health check path in the app settings. Program.cs

   var builder = WebApplication.CreateBuilder(args);
   builder.Services.AddHealthChecks();
   
   var app = builder.Build();
   app.MapHealthChecks("/healthz");
   app.MapGet("/", () => "Hello from Nodion");
   
   app.Run();

3. Keep AllowedHosts open for the health check The health check calls each instance with its internal IP as the host. The template default "AllowedHosts": "*" lets it through. A list of your domains makes ASP.NET Core answer 400, and the release never goes live; keep *, or check hosts in your own middleware that skips the health check path. appsettings.json

   {
     "AllowedHosts": "*"
   }

4. Create the app and attach PostgreSQL Create an application from your repository in the region EU Central, then a PostgreSQL database in the same region. Npgsql uses key-value connection strings, not postgres:// URLs like DATABASE_URL, so when you attach the database on the Environment tab, inject host, port, database, user and password under your own names and build the connection string from them. Program.cs

   var cs = new Npgsql.NpgsqlConnectionStringBuilder
   {
       Host = builder.Configuration["DB_HOST"],
       Port = int.Parse(builder.Configuration["DB_PORT"] ?? "5432"),
       Database = builder.Configuration["DB_NAME"],
       Username = builder.Configuration["DB_USER"],
       Password = builder.Configuration["DB_PASSWORD"],
   }.ConnectionString;
   builder.Services.AddDbContext<AppDbContext>(o => o.UseNpgsql(cs));

5. Apply EF Core migrations Nodion does not run EF Core migrations, and the run image has no SDK, so dotnet ef cannot run as a release step. Apply them when the app starts with Database.Migrate(), which is fine for a single instance, or switch to a Dockerfile that builds an EF Core migration bundle and runs it as the app's release command. Program.cs

   using (var scope = app.Services.CreateScope())
   {
       scope.ServiceProvider.GetRequiredService<AppDbContext>().Database.Migrate();
   }

Good to know

• SDK and runtime versionThe .NET line comes from global.json, else from the TargetFramework of the project in the base directory, else .NET 10, and the run image gets the ASP.NET Core runtime of the same line. A project in a subfolder is not read for this, so a net8.0 or net9.0 app selected with DOTNET_PROJECT needs a global.json with that version. Nodion installs the current SDK of that line, which can be a newer feature band, so set "rollForward": "latestFeature" there.
• Production settingsNodion does not set ASPNETCORE_ENVIRONMENT, so ASP.NET Core runs as Production and reads appsettings.Production.json on top of appsettings.json. Keep secrets in environment variables marked secret; ConnectionStrings__Default maps to ConnectionStrings:Default.

What Nodion runs for you

• Deploys without downtime Push to your branch and Nodion builds a new release. Traffic switches once the new instances answer their health check; a failed release leaves the running one in place. Apps with a local volume restart instead, because the disk belongs to one instance.
• Databases next to the app Managed PostgreSQL, pgvector, MySQL, Valkey and ClickHouse in the same region. Attached databases arrive as DATABASE_URL, REDIS_URL or CLICKHOUSE_URL.
• Previews per pull request Turn on previews and pull requests from your repository get their own app with its own URL and fresh, empty databases, created automatically or by hand. Forks and bot pull requests are skipped.
• Workers, cron jobs and scaling Run workers as extra processes of the same app, schedule jobs on the Cron tab, and scale every process to up to 16 instances.
• Release step With buildpacks, a Procfile release: line runs with every new build. Dockerfile apps, and redeploys or rollbacks to an earlier image, use a release command set on the app itself, which also takes precedence over the Procfile line. On static sites a release step runs in an image that holds only the built files.
• Logs and metrics Build, release and runtime logs plus CPU, memory, disk and network metrics for every instance in the dashboard.
• Domains and HTTPS A default hostname with HTTPS from the first deploy; your own domains get certificates automatically.

Further reading

• Dockerfile vs Buildpacks: Which One Should You Use? Both turn your code into a container image. What differs is who writes the build steps, and that decides control, maintenance and security updates.
• Heroku Alternatives with EU Hosting: 5 Options Compared A German platform and US clouds with EU regions, compared by headquarters, regions and managed databases.

.NET and ASP.NET Core on Nodion: questions and answers