Theo's Corner
dev / irl / thoughts
← Back
tech

How I manage multiple servers without losing my mind

Theo|Jun 2026|~4 min read

Between my server host's infrastructure, my home VPS, my NAS, and various other machines, I'm managing quite a few servers at any given time. Here's how I keep it from becoming chaos.

SSH config is non-negotiable

The first thing I do with any new server is add it to my SSH config. Every machine gets a short alias — ssh myserver, ssh nas, ssh vps — so I'm never typing IP addresses or remembering which user belongs to which machine. It sounds small but it makes a huge difference when you're jumping between machines constantly.

Docker Compose for everything

Every service on every server runs in Docker with a Compose file. This means the entire configuration for a server's services is in a single readable file that I can version control, back up, and reproduce exactly on a new machine if I need to. If a server dies, I'm not rebuilding from memory — I'm just pulling the Compose file and running it.

Treating your server configuration as code — something versioned and reproducible — is the single biggest thing that separates manageable infrastructure from a mess you're afraid to touch.

nginx as the front door

Everything goes through nginx. Every domain, every subdomain, every service — there's an nginx server block for it that handles SSL and proxies to the right container. It means there's one place to look when something with routing is wrong, and one place to add a new service.

Cloudflare on top

All my domains are managed through Cloudflare. DNS changes propagate fast, I get DDoS protection for free, and the proxying means my actual server IPs aren't publicly exposed for most services. It's become the default layer between the internet and everything I run.

Knowing when things break

The annoying thing about servers is that they break when you're not watching. I use simple uptime monitoring to get notified when something goes down, and I check logs regularly. docker compose logs -f is something I run constantly. Most problems announce themselves in the logs before they become actual outages if you're paying attention.

The goal is to make everything reproducible and observable. If you can rebuild it from scratch and you can see what it's doing, you can manage it without losing your mind.