The Always-On Server.
The Always-On Server.
An old laptop, plugged in and left on — the private machine everything else now runs from.
It started as a disk problem. My Mac kept running out of room — every code build, every cache, every regenerable heavy thing piling up on the one machine I actually work on. So I took an old laptop, plugged it in, and turned it into a server that never sleeps. Servers are always-on by definition; this one earns the name.
The regenerable weight lives there now, and on a drive beside it — build artifacts, caches, the things you can always rebuild — off the Mac, which stays lean and fast. That was the whole point, and then it became the substrate for everything else.
It hosts my private records myself, so nothing that is only mine sits on rented infrastructure. A key on the box means I can query my own data and run the Hexis coach on demand — from wherever I am, whenever I want.
It is wired to years of journals through a bridge, but a careful one. The systems are connected; the data is not cross-read. Nothing crosses the boundary it should not, even though the whole thing is my own build on my own hardware. Privacy-conscious by construction, not by trust — the same hard, one-way discipline the rest of the private work holds to.
The real work was never the box. It was reading and reconciling the state across three machines — laptop, phone, server — and routing cleanly between them so they behave as one thing. Once that held, the payoff arrived: I can develop from anywhere. Claude Code from my phone, the Mac from a table somewhere else, every project landing on the machine that’s always on. Reachable from anywhere over a private mesh; exposed to no one.
It stopped being a spare laptop and became the substrate. Twenty-five years of photographs and video live on it now — every camera roll, every phone, every shoebox of files, on my own disks, indexed and searchable and answerable to nobody. That archive has its own file: The Archive.
It serves the public demos. Each one gets its own named subdomain through a tunnel, so a pilot user receives a single stable link and never a machine. The land-intelligence pilot runs there, live at land-intel.parambahia.com. The rule is fixed: a public demo never carries a live model key.
It runs the pipelines — the flat-listing ingest that feeds FlatSignal, the role-matching run beside it — on schedules that hold whether or not I am at a desk. It carries a nightly offsite replica of the big client system’s data, because one copy on rented infrastructure is not a backup.
And it is watched. Watchtower’s monitors check it every twenty minutes and its nightly verifier reads the logs and reports what it found. The box that watches everything else is not exempt.
Running a machine is easy. Knowing it is still doing its job is the hard part, and that is what Watchtower is for. It runs in three tiers. Dumb monitors every twenty minutes assert that the data is fresh and the services answer — no model, no cost, and the only thing fast enough to catch a dead box. A nightly verifier reads the logs, hits the APIs and writes a briefing, because plenty of failures look healthy to a script. And a weekly audit does the slower repository work — dependencies, security, drift. Every tier reports to the same place on my phone, and alerts fire on the change of state, never on every failing run. Alert fatigue is how monitoring dies.
Two machines watch each other, so neither can fail quietly. The server checks the cloud box is answering; the cloud box checks the server is still publishing a heartbeat. Whichever survives does the telling.
Underneath that runs the ordinary work on a clock. The flat-listing pipeline goes out twice an hour through the waking day. The body record refreshes before dawn. The role-matching run sits commented-out while it is parked — deliberate silence, which the monitors are taught to read as parked rather than broken. The nightly verifiers fire in the small hours, one per machine; the weekly audits on a Monday. A link I share from my phone comes back a couple of minutes later as a verdict on whether it is worth adopting.
The tooling underneath keeps moving too — language servers for navigating code, live documentation for libraries I am not certain of, a local security scanner, a cross-model reviewer from a different model family on anything large — each one added when a mistake showed it was missing.
Watchtower grew a second mouth on 23 September. The first watches my systems. The second watches for me. Everyone knows the moment: you are scrolling, something goes past — a repository, a technique, a piece of design, a way of cutting a video — and you think, that would be useful, and then it is gone and you never look at it again. Now it is not gone. I send it to a channel from my phone and the server holds it. No model reads it on the way in; it is a shelf, not an assistant.
When I sit back down at the coding harness I say read the shelf. It goes through what I kept, works out what each thing is and how it could be used — against the projects, the skills, this site — and hands back a verdict for each: adopt, adapt, skip, already covered. Dozens of things have come through it since: tooling, design references, marketing patterns, video method, media. The design questions now on this site’s backlog came through it, and so did the decomposition frames on the Hexis file. Most of what it could do I have not asked it to do yet.
04 / 20 · The Always-On Server — Reachable from anywhere, exposed to no one
Laptop, phone and server reconcile into one thing over a private mesh, so I can develop from anywhere and the box answers to no one else.
My records, the photo archive and the Hexis backend live on hardware I own, so nothing that is only mine sits on rented infrastructure.
Builds, caches and every regenerable heavy thing live on the box and the drive beside it, so the Mac stays lean.
It keeps a nightly copy of the big client system’s data, because one copy on rented infrastructure is not a backup.
Each public demo gets its own named subdomain through a tunnel, and a public demo never carries a live model key.
The listing ingest, the body refresh and the role matching run on schedules that hold whether or not I am at a desk.
Dumb monitors, a nightly verifier that reads the logs, and a weekly audit of the repositories all report to one place on my phone.
They assert that the data is fresh rather than that a job ran, alert on a change of state, and two machines watch each other so neither fails quietly.
Anything I catch while scrolling goes to a channel from my phone and the box holds it, and no model reads it on the way in.
When I sit back down I say read the shelf, and each item comes back as adopt, adapt, skip or already covered.