I spend most of my working life building AI systems for startups. Agents, LLM infrastructure, the plumbing that makes models useful. And for years I ran all of my own stuff the way everyone does: a monthly stack of cloud subscriptions, my data scattered across services I don’t control, and an increasing amount of my work depending on APIs metered by the token.

This year I decided to fix that. Not out of ideology, mostly out of practicality. I already own the hardware. I have fast fiber at my apartment and a pile of capable machines at a second location. I travel a lot between work sites, and the thing I actually want is simple to state: everything I care about should live on infrastructure I own, and it should work identically whether I’m at my desk, at a client site, or parked somewhere with a cellular connection.

This series is the build log. Real configs, real mistakes, and the architecture thinking behind each piece. This first post is the map.

The shape of it

I have two physical sites, and instead of making them mirror each other, the design leans into what each one is good at.

The apartment is the hot edge. It has 5 gigabit symmetric fiber, a 10G network backbone, and a small NVMe flash pool. Anything latency sensitive lives here: the services I hit interactively, fast storage for indexes and working data, and an always-on Mac mini that acts as my agent workbench (more on that in a later post).

The second site has the opposite profile: plenty of CPU and memory, and a 52TB spinning-disk archive, but nothing about it needs to be fast to reach. So it’s the compute and archive site. Batch jobs run there. Raw data lives there. Backups land there. Slow disks are fine when the work is throughput shaped instead of latency shaped.

Then there’s me, bouncing between locations with a laptop, a phone, and a portable 5G router. The roaming layer is a first-class part of the design, not an afterthought.

One network, no public anything

The piece that ties it together is Tailscale. Every machine at both sites, plus my laptop, phone, and the travel router, joins one WireGuard mesh. Each site runs a small gateway container that does two jobs: it advertises the site’s subnets so I can reach devices that don’t run Tailscale themselves, and it acts as an exit node so my traffic can egress through home when I’m on wifi I don’t trust.

This replaces a whole category of problems. There are no port forwards. Nothing has a public IP. There’s no VPN to toggle, no bastion host, no dynamic DNS. Access control is a single ACL policy: which people and which machines can reach which services. When I eventually share pieces of this with family, friends, or clients, that’s an ACL entry, not a new attack surface.

The failure I’m designing against is losing access to a site while I’m hours away. So the gateways get boring treatment: dedicated containers, key expiry disabled, start on boot, and a second gateway at the remote site advertising the same routes so no single host failure locks me out. A KVM on the most critical host covers the cases a VPN never can, like a machine that won’t boot.

Storage has a temperature

The data layer follows the same asymmetry as the sites. The flash pool at the apartment holds hot data: search indexes, recent job artifacts, caches, anything a service needs to read quickly. The big archive holds everything else: source data, full history, backups of the hot pool, logs.

Data flows in one direction by default. Things get created or ingested wherever is convenient, get processed at the compute site, land on fast storage if something needs to serve them, and replicate to the archive on a schedule. Going less cloud reliant doesn’t mean abandoning backup discipline, so one encrypted copy still leaves the premises. The point isn’t purity. The point is that the default location for my data is hardware I own.

The part I actually care about: AI as a service layer

Everything above is table stakes. The reason I’m building this is the layer on top.

I want my AI tooling to be infrastructure, the same way storage and networking are. Concretely, that means a few services with stable names on the tailnet:

A gateway that gives every device and every agent one endpoint for model access, with routing policy and per-project budgets behind it. Which provider handles a request, and how much a project is allowed to spend, becomes configuration instead of habit.

A knowledge service that indexes my project corpora, so any tool I use, anywhere, can query the same knowledge through one interface. My notes, my repos, my business documents, available to every agent I run.

A job system, so “hand this off and let it grind overnight on the big machines” is a normal operation rather than something I babysit.

The head of all this is a persistent workspace I can reach from any device. Sessions run on my servers, not my laptop. I can start a task at the office, drive somewhere, and reattach from my phone to see where it got to. The laptop becomes a thin client. The capability lives in the infrastructure.

Why bother, honestly

A fair question, since the cloud versions of all of this exist and mostly work.

Part of it is cost, but less than you’d think. Part of it is privacy and ownership, which I weight more heavily every year I work in this industry. A lot of it is that I build agentic systems for a living, and there’s no better way to develop opinions about this stuff than running it yourself, on your own hardware, where every failure is yours to debug.

And some of it is just that it’s satisfying. There’s a version of this hobby that’s collecting blinking lights in a rack. I’ve done that. This is the other version: a system with a job, where each piece earns its place.

Next post: the network spine in detail, including the VLAN mistake that cost me an evening and taught me more about my own setup than a month of it working correctly would have.