[adamcharnock]

For deployment to a single-server I would certainly reach for Ansible as a starting point. Using that I would probably configure systemd units on Debian.

Speaking off-the-cuff (so don't hold me to this):

If you need multi-node for (fairly good but not amazing) reliability, then the easiest first step would be a cloud instance, rather than bare-metal server. Given live migration, they are effectively multi-node.

If you need multi-node for performance, then get a single dedicated bare-metal server. They can pack a huge punch while being cost effective. And you'll likely get 100% uptime in a good year.

If you need multi-node for reliability & performance, then kubernetes.

[psviderski]

Can you still justify K8s even if you need to jump from one cloud/dedicated instance to say 2-3 for reliability?

[adamcharnock]

I was being a bit terse in my original comment. I do think there are a bunch of other situations which don't fit into what I described above.

If scaling really is on the horizon, then yes, doing k8s immediately will save you some time in the long run. If that is the case though, you could always reach for a managed K8S service first (EKS/GKE), then deploy to dedicated later. Just avoid any entanglements with other proprietary cloud services, because that will be time consuming to untangle later.