All our project templates are configured to deploy with Docker Compose using GitHub Actions, which is how we deploy all our Apps.
See this detailed blog post and video that explains how we now recommend doing .NET App deployments:
It’s a better isolated and more flexible deployment model which we can deploy any App with and after the initial setup it’s very easy to deploy new Apps to the same server which only requires setting GitHub Action Secrets to specify the website domain the App should be hosted at.
and as most of our project templates are already configured with the build and release GitHub actions to deploy the published .NET App it requires very little effort as documented in our GitHub Action Docker Compose deployments via SSH docs
We also deploy to Amazon Linux (RHEL based distro) with this approach, otherwise if I couldn’t use Docker I’d deploy with rsync / supervisord which is a reliable way to host Apps which will autorestart on failure.
I’ve no experience running .NET Apps with systemd, but found a couple of articles on Google:
Only when we deploy, whenever I run into issues with remote App deployments I’ll just open a bash shell into the container and inspect it on the remote host.
I only run infrastructure dependencies locally, e.g. RDBMS’s, Redis, TypeSense Server, etc. i.e. not the published .NET App itself.
I managed to use the new Microsoft package for systemd and set up a rhel system without supervisord. It seems to be working fine.
I’ll let you know how it goes once it’s been in production for a while.
Maybe I’ll even find some time to write a procedure for this if you are interested.
It’s nice since you have journalctl integration, and everything is pretty much where a sysadmin not familiar with supervisord would expect things to be.