If you cannot rebuild it, you do not really run it
Self-hosting stays calm when a machine can be replaced from notes, not from memory.
Running your own services is a good way to find out what "it works" actually depends on. A server, a reverse proxy, a container, a deploy workflow: each piece is simple enough to understand on its own. The difficult part is the gap between the machine you remember setting up and the machine you could set up again on a tired evening.
Memory is a poor runbook.
Assume the current box is temporary
That assumption changes what gets written down. Which packages were installed, how the firewall is shaped, where certificates live, which services should return on their own, which environment variables are required. These are not trivia. They are the difference between an afternoon and a lost weekend.
Containers make an application easier to move. They do not, by themselves, explain why it was configured that way. A Compose file without a note about the proxy, the volumes, and the backup is only half a system. The other half is still production. It is just production that lives in your head.
The standard I keep aiming at is slightly stern. If the disk disappeared, could the service come back from the repository and a short set of notes? While the answer is no, the setup is more fragile than it looks on a quiet day.
Notice the failures that need a person
A quiet system is not an invisible one. Disk filling up, a certificate nearing expiry, a container that has been restarting since midnight: these are the signals that predict a bad morning. A large dashboard is optional. A signal you will actually see is not.
The same taste applies to shipping a change. A manual session full of remembered commands works until the one day it does not, usually while you are trying to fix something else. A small pipeline — build, ship, restart, check — costs more to set up and much less to trust. It also leaves a record of what changed, which is what you will want when the new version misbehaves.
The short list I try not to negotiate with:
- Provisioning notes that can be followed without improvising.
- Backups that have been restored at least once, not only taken.
- TLS and the reverse proxy kept boring on purpose.
- Deploys that record what went out.
- Alerts for the few failures that need a person, and silence for the rest.
Let each extra service earn its place
Every added tool is another thing that can fail, another thing to patch, another login to keep. Self-hosting is still worth it when the lab earns its keep: safer deploys, a clearer view of what is running, an easier way back after a mistake. A service that only adds machinery has a carrying cost, and that cost shows up later, usually during the incident.
The point of a small production server, or a lab beside it, is to understand the machinery well enough that it stops demanding attention.
A system you can rebuild is a system you can change without holding your breath.