Self-Hosting Maintenance

Self-hosting gets reliable when the boring care is repeatable.

This page is for the part after the first successful launch: updates, backups, storage, certificates, exposed services, logs, access, and the small notes that make recovery possible later.

The goal is not to turn your home lab into corporate change control. The goal is to know what you run, what can break, and how to recover without guessing under pressure.

The short version

Patch what is exposed. Anything public-facing or reachable through a tunnel gets priority.
Check backups. Confirm jobs completed, storage is healthy, and one small restore actually works.
Watch disk space. Full disks break services in plain, frustrating ways.
Review remote access. VPNs, tunnels, reverse proxies, firewall rules, and DNS records drift over time.
Update the notes. Recovery notes should match the system you actually run.

The maintenance rule

If you cannot explain how to update a service, back it up, restore it, and tell whether it is healthy, the service is not fully under your control yet. It may be working, but you are still depending on luck and memory.

Maintenance is what keeps self-hosting useful instead of fragile. It does not need to be elaborate. It needs to be repeatable enough that future-you can follow it when the service is down and patience is low.

A monthly rhythm

Pick a regular day. Keep the checklist small enough that you will actually do it. A simple habit beats a beautiful process that never happens.

Updates: check the host OS, containers, plugins, dependencies, and anything reachable from outside your network.
Backups: confirm backup jobs completed and that the destination still has space. “Configured once” is not a backup status.
Storage: check disk usage, media growth, logs, databases, snapshots, and SMART/drive health signals where available.
Certificates and domains: look for expiration problems before they become urgent.
Remote access: review VPNs, tunnels, reverse proxies, firewall rules, and public DNS records. Exposure should be intentional.
Users, tokens, and API keys: remove stale access and make sure important credentials are documented in the right place.
Logs and alerts: fix noisy alerts, missing alerts, and logs that grow forever.
Documentation: update the notes you would need on a bad day, not the notes you wish you had written on a good one.

If you only do three things

Start here. These three checks catch many common self-hosting failures before they turn into a larger cleanup job.

Patch what is exposed. Anything public-facing or reachable through a tunnel gets priority.
Check backups and restore one small thing. A backup that has never been restored is still mostly a theory.
Check disk space. Full disks can break databases, logs, uploads, containers, updates, and backups.

Quarterly checks

Restore one service somewhere safe. Prove one backup works before you need it.
Review remote access. Tailscale, VPNs, Cloudflare tunnels, reverse proxies, and firewall rules drift over time.
Prune unused services. If nobody uses it and nobody can explain it, remove it or document why it stays.
Check dependency risk. What breaks if the host, NAS, domain, DNS provider, identity service, or reverse proxy disappears?
Refresh runbooks. Recovery notes should match reality, not the version of the setup that existed months ago.

The small restore test

Do not start with a full outage simulation. Pick one service and test enough to prove the backup path is real.

Find the backup without relying on memory.
Restore it somewhere safe, not over the live service.
Confirm the service starts.
Confirm the data looks right.
Write down what was missing, confusing, or slow.
Fix the recovery notes while the details are fresh.

If you want a quick sanity check before you trust your setup, try the Backup Reality Check. It will not make the backups good for you, but it will make the missing pieces easier to see.

What to document

This does not need to become a corporate incident handbook. A clear Markdown note is enough if it tells you what to do when the service is down.

Where the service runs.
Where the data lives.
Where configs and secrets live.
How to update it.
How to restart it.
How to restore it.
What depends on it.
What external accounts, DNS records, certificates, or tokens matter.
Who else notices if it breaks.

When something breaks

Do the calm version first: check power, disk, network, DNS, certificates, service status, logs, recent updates, and whether a dependency is down. Most outages are not grand mysteries. They are usually small assumptions stacked badly.

Once the service is back, write down what actually fixed it. The best time to improve the runbook is right after the problem is understood.