Start with introductory physical unix handbooks that cover user permissions, fork(2), and exec(2).

Oddly enough containers only add something like a git-fs-chroot and network-chroot on top. The principles are all still the same.

Like I said, I didn’t like this answer either until I read a few of the books.

For example what does it mean to _secure the server properly_. What's the "threat model"? Are there compliance requirements? Since this looks like a sort of hobby-project (single-server production deployment?), I believe that you should be okay with ssh keys-only config and ports 80 (redirect to SSL) and port 443 with LE certificates.

Managing security updates on a single server will require downtime. If you have active users you can handle that we scheduled downtime 5hours every X weeks (e.g. First Saturday of the month from 01-02 AM the server will be unavailable).

You're going to need a dedicated system to setup observability. The cheapest option is probably node_exporter with prometheus and grafana. Loki for logs with s3 backend (can be pretty cheap if you use backblaze).

For backups use whatever the provider gives you to backup the VM. Most providers have a ready-made solution for that.

Automatic deploys can be configured ofc, but usually the deployment pipeline mirrors the application requirements... Are you going to a DVCS (github actions)? Are you doing to handle deployments using a tool like kamal? In either case would try to use "SO_REUSEADDR" for zero-downtime upgrades in a single-server.

Secrets management and server setup can be managed by ansible + sops.

> anything else that is needed?

A DB? A CDN? An object store? A queue? :-)