the system · 02 · deployment engine

Nexus.

The homelab needed a way to turn code into running services without babysitting, so I built my own deployment platform. Push a repo, get a live, TLS-fronted app on my own machines.

every deploy, same ritual
git push
build
health gate
soak
cutover

A new release builds in the dark next to the old one, has to prove itself healthy through a soak window, and only then takes over the traffic. If it never gets healthy, it never goes live, the old release simply keeps running. That’s the whole trick behind zero-downtime.

machines, one platform
3
apps running on it
29
downtime on deploys
0
surface for me & AI
1

Services wire themselves.

Apps can live on any machine in the mesh. When one service needs another, Nexus hands it the address and credentials automatically on the next deploy, nothing is hard-coded, and a whole group of services can share credentials as one unit.

# injected into the app on deploy
CONTENT_URL=http://content.mesh:*****
CONTENT_TOKEN=••••••••••••
# never hard-code an address again

Built for two operators: me, and AI.

I operate the platform by chat, an AI agent sees the exact same controls I do. It can inspect the fleet, design new services and stage everything… but anything irreversible, a real release, a deletion, needs my explicit approval first. The agent proposes; I decide. Every action is logged.

who may do what
  • look & inspectagent · instantly
  • configure & stageagent · confirms
  • release & deleteonly with my grant
want the deep dive? · paper
Governing the Tools, Not the Agent

The full write-up of Nexus, the capability model, the architecture and the deploy pipeline, with the diagrams.

next · 03
Application Engine
the automation