I Built My AI a Brain. It Had One Skull.
How a dead Mac Mini taught me that self-hosted memory needs no host at all: git as WAL, CI as the writer, and cattle replicas.
A while back I wrote about giving my AI cofounder a memory. Everything it learned about my projects, my decisions, and my mistakes went into a database on my own hardware. No third-party vendor holding my thinking. It worked.
It also had a flaw I didn't see. The flaw wasn't in the code. It was in the topology.
Every write went to one Mac Mini on my desk. That machine indexed the memory, held the source of truth, and pushed copies to my other computers. I had built a brain with exactly one skull. I spent months adding replicas that could read it. That felt like resilience, right until the morning it wasn't.
The morning the brain went quiet
At 06:50 on a Saturday in July, the Mac Mini went dark while I was on a business trip in a different country.
The reads survived. That part worked. A routing layer noticed the primary was gone. It sent queries to a replica. My coding sessions kept recalling past decisions as if nothing had happened.
The writes were dead for 34 hours.
That alone is an ordinary hardware failure. But when I investigated, I found something worse. The replicas had been accepting writes the entire time. Each one stored the new memory, returned a success receipt, and then quietly dropped it the moment the primary came back online. The system wasn't just losing data. It was lying to me. Every "saved" notification was a small forgery.
I fixed that the same evening. Replicas now reject writes immediately and fail out loud. A noisy error is always better than silent corruption.
Still, the honest error message surfaced the real question: why did I have a primary machine at all?
Why not just use the cloud?
The obvious question is why I didn't just host a managed database in the cloud and call it a day.
Two reasons. First, latency and locality. When an AI agent runs in a tight coding loop, it queries memory constantly. Local reads take one millisecond on disk. Cloud round-trips add latency to every step, and they break the moment your wifi drops. I wanted a system that worked on a plane.
Second, blast radius. This memory holds my codebase, my architectural notes, and my business decisions. An always-on cloud database is an unnecessary target.
I wanted the security and speed of local files, without the fragile dependency of a single home server.
Deleting the concept, not the machine
When a server dies, the instinct is to make it tougher. Better power supplies. Faster failovers. A hot standby.
That is a treadmill. You spend time buying reliability for a role that shouldn't exist.
The real answer was to stop treating the database as a live server. Treat it as a build artifact.
Three rules define the redesign:
The database is a build artifact. Git is the write-ahead log. The writer is a pipeline.
Here is how it works in practice:
- Writing a memory is a git commit. A markdown file or a JSON line. It works from a laptop, a phone, or a cloud shell. It works offline. Git orders the commits. Split-brain becomes structurally impossible.
- Building the index happens in CI. A GitHub Actions workflow picks up the commits, generates the embeddings, indexes the data, and publishes the database file as a release artifact. No personal machine is required. If the pipeline breaks, the exact same script runs locally on any laptop.
- Serving machines are cattle. Each computer pulls the latest artifact, verifies it, and swaps it in atomically. Losing a machine is a non-event. None of them is the source of truth.
The concept of a "primary" machine disappeared from the architecture.
The security catch: belief breaches
This design introduced a new vulnerability.
When your memory database is just a downloadable file, whoever controls that download controls what your AI believes. An attacker doesn't need to steal data. They can inject false memories. The agent will read them, trust them, and act on them.
A simple SHA-256 checksum does not protect against this. If an attacker compromises a deployment token, they can publish a malicious database alongside a valid checksum.
To prevent this, the build artifact is cryptographically signed using keyless OIDC signing in CI. There is no long-lived private key stored on the server to steal. The signature is bound directly to the specific GitHub Actions workflow and repository.
Each machine verifies this identity before installing the update. If a file is not signed by our exact build pipeline, the agent refuses to load it.
The suitcase receipt
Design documents are easy to write. The real test happened a few weeks later.
The pipeline's first full build (indexing roughly 39,000 chunks across 3,000 files) ran while I was on a flight. The airline wifi blocked my VPN. Every computer in my home was completely unreachable.
The Mac Mini that used to be the single point of failure was powered off in my cabin luggage in the overhead bin.
The memory system rebuilt itself from scratch, signed its own artifact, and distributed it to every active client. I reviewed the pull request from my phone and approved it from 30,000 feet.
If your AI depends on your hardware being online, you don't have resilient architecture. You just have a single point of failure with your name on it.