Server daemons: run a .NET worker as a background daemon (systemd) with DotDeployer
A daemon, on Linux, is any long-running background process managed by the init system —
here, systemd — rather than something a user runs interactively in a terminal. A Windows
service is the same idea on Windows: a process the OS starts, supervises, and restarts, with no
console attached. A .NET Worker Service (Microsoft.NET.Sdk.Worker) is the application-level
piece that makes a .NET app able to run as either one, from the same binary, depending on the
host it’s running on. On a DotDeployer server, “daemon” specifically means a systemd unit
DotDeployer creates and supervises for you.
A daemon is a long-running process DotDeployer keeps alive on a server — a queue consumer, a background worker, anything that’s meant to run continuously rather than finish and exit.
Steps:
- Open the server from Servers, go to its Daemons tab.
- Add the command that starts the process — for example
dotnet MyWorker.dll. - DotDeployer starts it and keeps it running: if it crashes or the server reboots, it’s restarted automatically.
Where it runs: a daemon runs on the server, not tied to a single site’s current symlink the
way a deploy is — point it at the release path you want it to run from.
Daemon vs. scheduled command: a daemon is for something that should always be running; a scheduled command is for something that runs on a timer, finishes, and exits. A queue consumer is a daemon; a nightly cleanup job is a scheduled command.
Logs and restarts: a daemon’s output is available the same way a deploy’s log is, and restarting it — after a config change, for example — is a button on the Daemons tab rather than an SSH session.
Per server: daemons are set per server. If you run the same worker on more than one server, add it to each server’s Daemons tab.
