nnesly
Menu
TRSign in

Deploy ASP.NET / .NET

How nesly detects, builds and serves a ASP.NET / .NET project — and the two commands that put it on a live URL.

Deploy ASP.NET / .NET on nesly

A ASP.NET / .NET project is built into a container and run as a server process.

nesly new dotnet-mssql my-app
cd my-app
nesly addon add mssql
nesly deploy --yes

The first deploy creates the project and prints the live URL; after that,nesly deploy is enough.The dotnet-mssql template is a complete, readable starting point.

How detection sees it

  • A .NET project (a .csproj) runs as a container; the SDK and runtime tags follow <TargetFramework> (net8.0, net9.0, net10.0).
  • Projects under src/… and a root .sln are found; with several .csproj files, the single Microsoft.NET.Sdk.Web project is published; more than one web project needs a Dockerfile.
  • With the mssql addon, ConnectionStrings__Default is injected — Configuration.GetConnectionString("Default") reads it with no configuration code.
  • A Migrations folder is bundled into /app/efbundle at build time; release = "dotnet ef database update" runs that binary in the runtime image.

When detection is not what you want, say it yourself: build and start commands, root directory and output directory live in nesly.tomlcommitted next to the code — see builds.

Worth knowing

  • The platform sets ASPNETCORE_URLS (and PORT) on the container — you do not need UseUrls for the listen address.
  • If the build fails with NETSDK1045, raise the SDK that can build your TargetFramework (or pin one in global.json for local builds).
  • release = "dotnet ef database update" needs a Migrations folder (and EF Design package); without it the build refuses with a sentence.
  • Attach a managed database withnesly addon add postgres (ormssql) — connection env vars are injected on the next deploy.
  • When a deploy fails, nesly diagnosereads the logs for you and names the fix.

Full walkthrough: get started. Custom domains, backups, GitHub deploys and the rest of the reference: nesly CLI.