Why#
There is a version of self-hosting that looks like building things. New services, migrations, architecture decisions. That version has a narrative arc and a clear sense of progress.
Then there is the other version. The one that looks like reading a daily digest and finding something that needs attention. A security advisory for a component that routes all DNS traffic. A mail header that does not match the envelope sender. A breaking change in the next version of the identity provider. A power cut that takes the whole stack down and requires physical intervention to recover.
This version does not have a narrative arc. It has a maintenance schedule.
The weeks documented here are that version. They are what ownership actually costs.
Family#
On a Tuesday morning in May the power went out. Everything in the house came back when the power did — except the home server, which crashed during the outage and locked itself in a kernel error loop that prevented the network from coming up.
The consequence was immediate and unexpected. The server is also the DNS resolver for the home network. Without it, no device in the house could look up any address. The wifi showed connected. The router was working. But nothing could reach the internet, because the system that translates names to addresses was not responding.
The server required a physical restart — unplugging it and plugging it back in. No remote access was possible. This is the kind of thing that sounds like a minor inconvenience until it happens at a moment when someone needs to use the internet and the person who knows what to do is not home.
The to-do list now includes an uninterruptible power supply and a DNS fallback configuration. Neither was considered necessary before this happened.
Tech#
Four separate maintenance actions happened in the space of a week, each of which illustrates a different aspect of what ongoing operation requires.
The DNS service received two security updates in three days. The first addressed a vulnerability in how it forwarded queries under certain encryption configurations — a class of issue that enables cache poisoning, which can redirect traffic without the user noticing. The second was a hotfix for a caching bug. Both required finding the correct version tag, updating a configuration file, pulling the new image, and restarting the container. Neither was complex. Both were necessary.
The identity provider that handles authentication for all services had a new release with a breaking change: the default network address it listens on changed in a way that would have made it unreachable on an IPv4-only network after the upgrade. The fix required adding four explicit configuration lines before running the upgrade. Missing that detail in the release notes would have locked every authenticated service — password manager, photo library, file storage, wiki — until the error was diagnosed and corrected. The release notes were read carefully. The fix was applied. The upgrade completed without incident.
The same release introduced per-provider control over which authentication flows each application is permitted to use. Eight providers were updated to allow only the flows they actually need. One application received an exception because it uses a flow that no browser-based service would ever need — a device code flow for command-line registration. The others were restricted to the standard web authentication flow and its renewal mechanism, with everything else disabled.
The mail routing problem was the smallest item and the most instructive. System notifications — backup confirmations, scheduled task results, security alerts — travel through a mail relay that has been working correctly for weeks. A configuration line that was never needed before became necessary when the mail server started rejecting messages because the visible sender in the message body did not match the sender declared in the transmission envelope. One line in the configuration file corrected it. The fix took ten minutes. Finding that the problem existed required noticing, in a daily digest, that a scheduled task had stopped producing confirmation messages.
Project#
The maintenance log for this period contains no new services, no architectural changes, no migrations. It contains eight version updates, one incident response, one near-miss on a breaking change, and several small configuration corrections.
This is the normal state of a running system. The building phase ends. The operating phase does not.
The cost of ownership is not the hardware or the hosting fees, though those are real. It is the sustained attention required to notice when something has quietly changed. The DNS vulnerability was announced on a Tuesday. The AdGuard Home hotfix shipped on a Thursday. The Authentik release notes described the breaking change in a paragraph that is easy to skim past. The mail header mismatch had been silently failing for days before it surfaced in a log review.
None of these required deep expertise to resolve. All of them required reading carefully and acting promptly. That discipline — maintaining it week after week, for a system that mostly works and rarely demands attention — is what running infrastructure actually involves.
The power cut was a reminder that the infrastructure exists in a physical world where things go wrong without warning. The response revealed two gaps in the resilience design. Both are now on the list.