Scheduled commands
Scheduled commands are DotDeployer’s version of cron: a command that runs on a schedule against a site’s current release, without you having to edit crontab by hand over SSH.
Steps:
- Open the site from Sites, go to its Scheduled commands tab.
- Add a command — for example
dotnet MyApp.dll --job cleanup— and a schedule for how often it runs. - DotDeployer runs it on that schedule against the site’s current release, on the server the site lives on.
Where it runs: the command runs in the same working directory and with the same environment variables as the site itself, so it can reuse the site’s configuration and connection strings without any extra setup.
When a deploy happens: scheduled commands keep running against whatever release is current —
after a deploy switches the current symlink, the next scheduled run uses the new release
automatically.
Choosing scheduled commands vs. a daemon: a scheduled command is for something that runs, finishes, and exits — a cleanup job, a report, a sync. For something that needs to stay running continuously, see Daemons instead.
Whose resources it uses: a scheduled command runs as cron on your own server — it uses your server’s CPU and whatever quota your command itself needs. DotDeployer does not run the command anywhere else; it only records the result (every run’s output is in the site’s log/history view). This is different from DotDeployer’s own health checks, which run from outside your server every few minutes and cost you nothing beyond the one HTTP or SSH request each check makes.
Notifications: a successful run never sends a notification — only a failure does, and only once, when a command’s outcome flips from ok to failing or back. Every run, successful or not, still shows up in the site’s log/history view.
