Right now, as I write this, there's an AI agent running inside a Kubernetes pod on a Mac mini sitting on a shelf in my house. It's not a cloud instance I'm paying by the hour. It's the same Mac mini that used to just sit there, mostly idle, between the rare moments I asked it to do something. Now it hosts a chat agent, runs CI builds, and syncs git repos with my other machines over a p2p daemon I wrote myself, called mesh. None of that needed a credit card on file with a hosting provider.
I didn't build mesh because GitHub Actions or a hosted git remote don't work. They work fine. I built it because I wanted to actually understand how this stuff works underneath, instead of trusting someone else's YAML to do it for me — and because I kept looking at the machines already scattered around me, this Mac mini, my phone charging on the nightstand, a laptop that spends most of its day just waiting for me to open the lid, and thinking: that's compute. That's storage. It's already on, already paid for, and it's idle almost all day. I'm not going to pretend I've run the numbers on cloud CI minutes versus my electric bill — I haven't, and that's not really the point. The point is I already owned more than enough machine to do this, and renting a fresh one felt like the wrong instinct before I'd even used what I had.
Git was designed as a decentralized source control system from the start. It ships with git-daemon, built specifically to push and pull between peers, and it's supported doing that same thing over plain HTTP for years. The pieces for peer-to-peer sync have been sitting inside git the whole time. And yet the workflow almost everyone actually uses is: push to a single hosted remote on GitHub or GitLab, and wait.
That waiting is a real, familiar pain. Every devops engineer knows the loop — edit the pipeline YAML, commit, push, wait for the runner to pick it up, watch it fail on something trivial, fix it, push again. It's slow specifically because everything gets funneled through one central, hosted choke point that git itself was never designed to require. Mesh doesn't invent decentralized git. It just actually uses the parts git already gives you for that — peers pushing and pulling directly, no single remote anyone has to wait behind — and puts CI/CD on top that runs the same way, picked up by whichever peer is available, instead of queued behind one vendor's runners.
There's a security shape here too, and I like it, mostly by accident. This chat agent has tool-calling access to a shell, but it doesn't hold GitHub credentials and can't push anywhere outside this pod. When it works on a repo, it clones from https://localhost:7979/<repo>.git — a bare repo mesh serves on the same machine — and every commit it makes gets pushed right back to that same local, bare repo over localhost. Nothing about that push ever leaves the pod. It's mesh's daemon, watching that bare repo, that then replicates the new commits out to other peers over its own signed peer protocol and kicks off CI. The agent never touches that hop at all. If the agent ever did something it shouldn't — a bad command, a bad instruction slipped in from something it read — the blast radius stops at a bare repo on localhost, not a GitHub org with real write access. I didn't set out to design that as a security model. It's just what you get when the thing that talks to the wider network is the sync layer, not the agent itself.
Mesh replicates full-mesh: every peer mirrors every repo the moment it's introduced with a git push. There's no primary server that everything depends on, because there doesn't have to be one. The pod on the Mac mini, my other machines, whatever node joins next — they're all just peers, and reliability comes from redundancy across hardware I already own, not from one box that has to stay up.
That's the same shape of idea I wrote about in When Two Systems Are Both Right: no single source of truth, just enough peers agreeing with each other over time. I didn't set out to repeat that pattern in my own infrastructure. I noticed afterward that I'd already believed it before I had a name for it.
I've said before that the integration is the product, and the software underneath is just plumbing. That's true of client work. It's also true of the pod this agent is running in right now. I just decided I wanted to lay this pipe myself, on hardware I already had sitting around not doing much, partly to learn how it actually works, and partly because it turns out ambient compute was never actually short supply. I was just renting around it out of habit.
Field Mappings