About

I have been working in IT infrastructure for about 20 years. That covers a lot of ground: helpdesk to architecture, small business to enterprise, individual contributor to managing teams and processes. I have held the title of Systems Engineer, Infrastructure Architect, and ITSM Manager, though the work has always felt more continuous than the titles suggest.

Most of that career has been spent inside production environments where decisions have consequences. Server rebuilds that could not fail. DR failovers that had to actually work. Infrastructure migrations with no rollback window. The kind of work that teaches you to slow down before you type.

During the day I work in IT service management, building the processes and frameworks that keep infrastructure teams organized and accountable. At night I run a homelab that would probably concern my network administrator past self. Proxmox, Rocky Linux, 30-something Docker containers, OPNsense at the edge, Traefik in the middle, and a growing collection of self-hosted apps, including a couple I built myself when nothing off the shelf quite fit.

That gap between enterprise thinking and homelab reality is what Painfully Useful is about.

Why this blog exists

I got tired of guides that skipped the reasoning.

Most technical content tells you what to run. Very few explain why that decision was made, what the tradeoffs were, or what would have to change for a different answer to be right. Those are the parts that actually matter when you are sitting in front of a production problem or designing something new.

Painfully Useful is where I document the thinking behind the decisions. Not tutorials. Not opinion pieces. Documented reasoning from someone who has made these calls in real environments and is still making them at home.

What you will find here

The content lives across a few themes that I keep coming back to:

Real infrastructure problems and how they got resolved. Not always cleanly. Not always on the first attempt.

Architecture and design decisions, including why something that looked right on paper needed to change when it met the actual environment.

Homelab builds approached with the same rigor I apply at work, because treating personal infrastructure casually is how you end up learning the hard way.

ITSM and operational thinking, because the human and process side of infrastructure is where most of the actual problems live.

A few things worth knowing

I am not neutral on self-hosting. I run my own everything where it makes sense, and I have strong opinions about why that is worth doing even when the managed alternative is easier.

I use AI tooling and think about it carefully. Claude, Claude Code, n8n, and automation pipelines are part of how I work now. I am still figuring out how deep that goes, and I document that alongside everything else.

Nothing here is presented as the permanent answer. What worked in my environment, under these constraints, at this point in time. Technology shifts and context changes, so take it accordingly.

If any of that sounds useful, you are in the right place.

Ryan McKernan is an IT Service Management professional and infrastructure practitioner.