Blog

July 2, 2026

A homelab should give time back

Self-hosting is useful when recovery, updates and monitoring are designed in. Otherwise you bought yourself another job.

A person checking a backup drive in a compact home server rack

Homelabs are usually photographed when they are new: clean rack, tidy cables, dashboards glowing in the dark.

The honest picture is six months later, when one container has stopped updating, the backup has never been restored and nobody remembers why port 8123 is open.

I like running my own infrastructure. I do not like babysitting it.

My test is boring

A useful homelab should survive two weeks without an SSH session. During that time it should:

  • keep the important services running
  • tell me when something is actually wrong
  • produce backups that can be restored
  • make configuration changes reproducible
  • fail in a way I can understand later

If it cannot do that, it is still a hobby project. Nothing wrong with that. Just do not call it infrastructure.

Automation is not unattended updates

The tempting move is to let every service update itself and hope monitoring catches the smoke. That removes clicking, not responsibility.

I prefer a duller setup: declarative configuration, staged updates, health checks, versioned changes and a recovery path I have exercised before needing it. The clever part is not automatically restarting a broken container. The clever part is knowing whether a restart hides the problem or restores a known-good state.

Backups have the same trap. A successful backup job proves that bytes were written somewhere. It does not prove that the service can be recovered. Restore tests are the only useful metric.

A real desktop network switch with its power and Ethernet connections in place

Photo: User_Pascal on Unsplash.

Where agents help

My AI stack runs through OpenClaw and Paperclip on machines I control. That makes the homelab a useful operating environment for agents, but not because I want an LLM improvising as root at 03:00.

The useful jobs are narrower:

  • collect the relevant logs
  • compare current state with the declared configuration
  • identify the last known change
  • suggest a bounded recovery step
  • execute only inside an explicit permission boundary
  • leave a report for the morning

An agent can shorten diagnosis and remove repetitive work. It should not turn an unexplained failure into an unexplained repair.

That distinction matters. A system that silently fixes itself is difficult to trust. A system that detects, explains and safely recovers from known failures is infrastructure.

The goal of self-hosting is not to own more machines. It is to own the failure modes without donating every evening to them.

Turn the idea into a decision

If this touches something you're building, let's make it concrete.

A focused 30-minute conversation is usually enough to find the real constraint, the next useful move — or whether I am the wrong person.