The laptop in the closet

The first public version of this system ran on a laptop in a closet.

Not a metaphor, and not a humblebrag. A 17-inch gaming laptop — i7, 64 GB of RAM, an RTX 3080 Ti, four terabytes of storage — sitting on a shelf in a room with the door shut, running Fedora, serving an AI system to a handful of testers through a Cloudflare tunnel. It stayed there until the end of September, when the whole thing moved onto a rented server in a data centre and the laptop went back to being a laptop.

Every architecture post about “local-first AI” stops at the romance of that image. This one is about the part that actually mattered: why the laptop was correct, what it cost, and what changed when it left.

What was running in the closet

The system is a memory: a store of my own documents, chunked and embedded, with a reader that answers questions against what is actually in the store and refuses when it is not there. A small model writes the answer; a bigger future lives on rented hardware.

The laptop ran all of it locally, including the model:

Two details were load-bearing.

The model was local on purpose. Testers typed personal things into a chat box. With the model on the same machine as the memory, nothing a tester typed crossed the network to a provider. The tunnel carried the page and the answer; the thinking happened in the room.

The front door was a tunnel, not an open port. No inbound SSH, no public application port. Cloudflare terminated TLS and forwarded to a socket bound to 127.0.0.1. For a system holding someone’s notes, “the only way in is through a tunnel I control, and the box has no open door” is worth more than any number of security features inside the app.

Why a laptop, honestly

Three reasons, in order of how much they mattered.

1. It was already paid for. The marginal cost of the first version was zero. A rented GPU with 24 GB of VRAM costs real money per hour; the laptop’s 3080 Ti was sitting there. The first thing an idea needs is not capacity, it is permission to exist cheaply enough to be wrong. I could run the whole system for a month on hardware I already owned, and I did.

2. Physical control is a feature. The data stayed in a room in my house. When I wanted to know what was on the disk, I walked over. Backups were a directory on a machine I could unplug. That is not a scalable property; for the first few months it was the most valuable one.

3. Iteration happened in the same room as the work. The machine that trained, embedded, re-ranked and served was also the machine with the code on it. A change was a save and a restart, not a CI pipeline. Every design decision in this system was made cheap by that loop.

What it cost is equally simple: a laptop is not always on. It sleeps, it thermally throttles, it loses power, and nobody is there to press a key. The first version needed the model and the store up whenever a tester opened the page. On a laptop, “whenever” is a promise you cannot keep. The dashboard had a waking state because the system genuinely had to wake.

The gotcha that only exists when two front doors disagree

The move to a real public beta produced one lesson I would put in front of anyone doing this: Cloudflare Access and the tailnet are different identity models, and they do not compose by accident.

The remote-access code was written for the tailnet, where tailscale serve injects a verified Tailscale-User-Login header and strips a client-sent one. Cloudflare does neither: it sends Cf-Access-Authenticated-User-Email, and it does not strip inbound Tailscale-* headers.

Two consequences, both real:

1. every tester arrived identity-less, so a guard that demanded a tailnet identity would have locked all of them out — solved by mapping anonymous-but-Access-vetted traffic to a single remote-anonymous sentinel;
2. worse, a tester could send Tailscale-User-Login: <operator> and the guard would believe it — solved by making that header inert server-side and adding an edge rule that strips it.

The lesson is general: a header is only an identity if the thing in front of you put it there. If two proxies are in the path and only one of them strips it, the header is a suggestion.

What the move changed

At the end of September the system moved off the laptop onto a CPU-only virtual server — about $23 a month, 22 GB of RAM, no GPU. The expensive reading work moved to rented GPU hardware on demand. Testers, threads and memories moved with zero conflicts; every entry was re-embedded and every hash matched before M2 was allowed to go quiet.

What that bought was not sophistication. It was always-on: a box that answers at 3 a.m. because it is a service, not a convenience. What it cost was the property that made the first version easy to reason about — the machine is no longer in my house, so the data is somewhere else.

Which is why the split that emerged is the design, not a stopgap:

Three machines, three jobs, none of them pretending to be the others. The laptop was not a prototype I escaped. It was the cheapest possible way to learn what the other two machines needed to be.

The part I would tell you to copy

If you are starting something like this and you own a computer with a GPU: start there. Do not rent capacity to find out whether the idea is real. Put the first version on the machine you already have, behind a tunnel you control, with the model local, and make the only promise you can keep — that it works while it is awake.

Then, when the promise you need to make becomes “it is awake when someone opens the page,” move the door to a box that never sleeps and rent the GPU only for the minutes you actually need it.

The closet was never the architecture. It was the cheapest correct answer to the question the project was actually asking at the time: what is this, and is it worth spending on?