What if one person ran a whole company's infrastructure?

Ask what a technology company needs to operate and you get a familiar list: somewhere to keep the code, something to build it, somewhere to store the built artifacts, a way to manage secrets, storage that survives failures, networking, monitoring, and then — finally — the actual applications.

My homelab has all of it, self-hosted on a six-node Kubernetes cluster that has been running for over a year: my own Git server and its build runners, my own container registry, a secrets vault, replicated storage, monitoring, and around twenty-three applications on top — including this website, the analytics platform that counts its visitors, a multi-agent AI platform, and ten small AI tool servers. The screenshot below is the real fleet, from the evidence page.

One verb: push

The operating model is deliberately boring. Everything the cluster runs is described in Git. A small robot continuously makes reality match the repository — and if reality drifts, the robot puts it back. When I change this website, I push the change; the system builds it, records exactly which version is running, and rolls it out. There is no deploy ceremony to remember, which matters, because a team of one has nobody else to remember it.

That constraint turned out to be the best teacher. With no colleague to catch a forgotten step, every manual step is a future failure — so everything becomes automated, declared, and checkable. This is precisely the discipline large organisations pay consultants to describe. Running it alone, at home, makes the reasons visceral rather than theoretical.

The week it broke

Honesty section. Recently my build system started failing intermittently: the public registry it pulled base images from began rate-limiting my network. The failures looked random — some builds passed, some froze — which is the worst kind of failure to reason about.

The fix was not a retry loop. It was removing the dependency: my builds now pull through my own registry, from an image I build and sign myself. The lesson generalises to every system I have ever operated, AI systems included: the dependencies you did not choose deliberately are the ones that choose your worst day.

Why an employer should care

Because it converts my claims from adjectives into habits. When I recommend GitOps, approval gates, audit trails, or owning your critical path, I am not describing a slide — I am describing my Tuesday. Every pattern on this site's operating-model page runs here first, where mistakes cost me an evening instead of costing a team its credibility.

And when an AI platform decision lands on my desk — what to centralise, what to control, what to measure — the instincts come from operating all of these layers together, not from having read about them separately.

An honest boundary

One operator, no service levels, no on-call rota, personal scale. A real company adds people, compliance, and consequences that a homelab cannot simulate. I claim the shape and the habits — not the scale. The scale is what I would be joining your organisation to serve.

---

The fleet screenshot and the platform's other production views are on the evidence page.