I keep a running list of the things I do on every small service I run. None of it is clever. All of it has saved me at least once. I wrote up the full setup in You probably do not need Kubernetes. These are the notes I actually come back to.
Harden the box before anything else
Before the app goes anywhere near a server, the server has to be safe to expose. No root login. Key-only SSH. A firewall open on 80, 443, and SSH, and nothing else. Something like fail2ban to cut down the noise.
The step people skip is disabling password authentication. Do it only after you have confirmed key login works in a second session. I have locked myself out doing it the fast way, and it is a bad hour.
Bind the app to localhost
One line, worth more than most of the architecture decisions I make:
ports:
- "127.0.0.1:3000:3000"
The app port is reachable only from the machine itself, so the reverse proxy is the only door in. If the proxy config breaks, you have a broken site, not an exposed service.
Check the certificate now, not later
certbot renew --dry-run
Five seconds. If it fails, I want to know today rather than the morning a certificate expires and the site goes red.
A deploy you can reverse is a deploy you will actually do
If deploying feels dangerous, you avoid it, and then you ship one scary change. The fix is small and reversible deploys. On a push, run the tests, and if they pass, update the box. Keep secrets in the platform, never in the repo. Keep the previous version one step away.
Minimum observability
A server you cannot see is a server you are guessing about. For a small service that means a health check that reflects real readiness, an external monitor that pages you when it stops answering, and logs you can read. That is enough. Collecting more than that, before there is a question to answer, is procrastination wearing a dashboard.
Reach for Kubernetes late
Kubernetes earns its keep when there are several services that scale independently, or a team that deploys without you, or a scheduler with real work to do. Until then it is a second job you volunteered for. I would rather run one box I understand than a cluster I have to look up.
The part that is not technical
The same shape of work shows up outside infrastructure. Leading the IEEE student branch at university was the same problem: limited time, unclear requirements, people with different goals. The clarity is the job. The tools are secondary.
None of these notes are original. They are just the ones that keep being true. If you run a small service, the boring version you understand will almost always beat the impressive version you do not.
Top comments (0)