.NET

Nitroship detects .NET from *.csproj files at the deployment root or one directory below it. The managed preset publishes the selected project, runs its assembly on compute, and extracts published wwwroot assets to the CDN.

DeployCopy Anchor Link

curl -fsSL https://nitroship.co/install.sh | bash
ntro login

Choose a compute region; there is no default. Select .NET explicitly in the deployment root:

{
  "build": {"framework": "dotnet"},
  "compute": {"regions": ["kr-icn"]}
}

ntro apps create my-dotnet-app
ntro deploy . --prod

This preset requires the hosted builder. Remove --local from your deploy command. After deploying, open a server route and a wwwroot asset at the URL printed by the CLI.

Project selection and buildCopy Anchor Link

The preset chooses exactly one project using Microsoft.NET.Sdk.Web, even if other library projects are present. If there is no web-SDK project, it accepts exactly one .csproj. Multiple web projects or multiple projects without a unique web project are ambiguous and require a different deployment root or your own Dockerfile. The selected project must actually serve HTTP; publishing a console application does not turn it into a web server.

Commit the project, its referenced projects, and dependency configuration. SDK version selection reads global.json's sdk.version, then the selected project's TargetFramework, then .tool-versions. A literal project TargetFramework overrides one inherited from the nearest Directory.Build.props; commit that file too if you use it. The runtime image follows the target framework. The build chooses pinned supported SDK/runtime base versions nearest those declarations, or stable defaults when none is declared. Multi-targeted or custom/native publishing needs your own Dockerfile.

The generated build publishes a release build. Published files are placed under /app in the runtime image. Startup runs the DLL named by AssemblyName, or the project filename when AssemblyName is not set.

Listening addressCopy Anchor Link

The generated runtime sets ASPNETCORE_URLS=http://0.0.0.0:$PORT, defaulting to 3000. Keep your application compatible with this setting: explicit Kestrel endpoints or a hard-coded URL in code can override it. Do not bind only to localhost.

Static assetsCopy Anchor Link

Published wwwroot files are included at /app/wwwroot and staged under /nitroship/static. The builder automatically extracts public assets to the CDN root before starting the runtime. wwwroot/css/site.css becomes /css/site.css. Server source, secrets, and symlinks must not be included in public CDN output. Razor rendering, APIs, and other server requests still run on compute.

If the publish output has no wwwroot, this preset produces no static CDN files. It does not discover arbitrary application file providers or directories outside the published web root. Use a custom Dockerfile for another extraction layout.

Environment and persistenceCopy Anchor Link

Set production settings and secrets through Environment variables. For ASP.NET Core configuration, use double underscores for nested keys, for example ConnectionStrings__DefaultConnection, when that is the key your app reads. Set ASPNETCORE_ENVIRONMENT=Production for production behavior. DATABASE_URL is only useful if your app reads it; it is not automatically turned into a .NET connection string. Use an external database.

Generated images run as a non-root user. The instance filesystem is ephemeral; use /tmp for temporary writes. Store uploads in S3 or other object storage. Persist ASP.NET Core Data Protection keys outside the instance if you need cookies to remain valid across instance replacement.

Nitroship does not automatically run migrations, queue workers, or schedulers. Run your migration command, such as dotnet ef database update or a migration bundle, in CI or locally against the external database. If the application itself migrates on startup, coordinate that explicitly. Run workers separately and use Cron jobs for scheduled HTTP work rather than an in-process scheduler.

Framework selection and Dockerfile escape hatchCopy Anchor Link

build.framework: "dotnet" explicitly selects .NET and overrides an automatically found Dockerfile. It cannot coexist with build.dockerfile.

Without an explicit framework, Nitroship detects the build as described in How Nitroship chooses a build. For custom project selection, native dependencies, publishing options, or static layouts, remove build.framework and use your own Dockerfile.