Image retained from the original article.
Originally published 21 June 2023; rewritten and reviewed on 15 October 2026.
An application runs successfully with dotnet run in a terminal. The next question is what happens after the terminal closes or the machine restarts. A production deployment needs a process owner, working directory and recovery behaviour as well as a compiled application.
Publish for the deployment model
Use a supported SDK for the project and choose framework-dependent or self-contained deployment deliberately. For a framework-dependent example:
dotnet restore
dotnet publish -c Release -o ./publish
# On the target host with the compatible runtime installed:
dotnet ./publish/ExampleApp.dll
Replace the assembly name with the published application. A self-contained deployment has different runtime and platform considerations. Verify the target architecture and required native dependencies.
Run under the intended service account
Choose a supervisor appropriate to the host, such as a reviewed systemd service. Set the user, working directory, environment and restart behaviour explicitly. Keep deployment secrets outside the published source and grant only the filesystem access the application needs.
For a web application, configure its listener and any reverse proxy deliberately. Do not expose a development configuration simply because the sample started successfully.
Test the operational lifecycle
Start, stop and restart the service through its supervisor. Confirm that logs are available, failures are observable and the application returns after a host reboot. Verify access to databases, files and external services under the actual service identity.
The original console demonstration is still a useful checkpoint. It becomes a deployment only when the process can be started, diagnosed and recovered without depending on the person who left the terminal open.