What runs on each of my machines

With fourteen machines and a handful of tools, there comes a point when you no longer know what's running where. This is the map of my harnesses and my models: which machine each one lives on, why there, how they talk to each other and what risks I accept by having some pieces exposed to the internet.

One Tuesday morning I got an alert that a service was responding slowly. I spent twenty minutes logging into three different servers looking for where it was running, until I remembered I'd moved it to another machine two weeks earlier and hadn't written it down anywhere. Twenty minutes looking for my own things in my own house. Like keys, but with servers.

With eight internal servers, six VPSs and several AI tools spread among them, without a map you end up lost. And the worst part isn't losing time: it's not knowing what has access to what.

In Why I have eight servers at home and six outside I explained the criteria I use to decide whether something goes inside or outside: the data it handles, the cost, the availability it needs and how exposed to the internet it has to be. Here I apply them piece by piece.

Three words that get mixed up a lot.

The model is the brain: it reads what you write and produces the answer. On its own, it only generates text. The harness is the program that surrounds the model and gives it tools, memory and limits: what lets it read a file, run a command or save what it has done. And an agent is, put quickly, model plus harness.

And a fourth that shouldn't be mixed up with the others: the runtime, the program that loads and runs a local model, like Ollama or llama.cpp. It doesn't give the model tools or permissions; it just gets it running and serves requests.

The pieces that will come up, each in its own pile:

• Models: the local ones (Qwen, Gemma, distilled DeepSeek...) and the cloud ones (Claude, DeepSeek, GLM, Kimi, MiniMax).
• Runtimes: Ollama, LM Studio and llama.cpp.
• Agent harnesses: Claude Code, DeepSeek Harness and OpenClaw.
• Fine-tuning tool: Unsloth.
• Automation: a few small services and scheduled tasks I've built myself to connect everything.

Local AI, the kind that runs on my machines without sending anything out, lives entirely on the internal network. That's where the graphics card that works for the other services is, the one in the GPU server. The other one I have is in my work laptop, and there I only test models.

On the GPU server, the one with the 12 GB RTX 4070, running Ubuntu, Ollama and llama.cpp run. Ollama handles the day-to-day requests from the other services; I use llama.cpp when I want to fine-tune how a particular model is loaded or try out new formats.

On my work laptop, running Windows with an 8 GB RTX 5070, is LM Studio. It's my testing bench: when a model I'm interested in comes out, I download it there, try it through its interface and decide whether it deserves to move to the GPU server. The server also hosts Unsloth, which I use to fine-tune small models on my own data, almost always at night because it keeps the graphics card busy for hours.

Why there? For three reasons. The graphics card: local models need one, and VPSs don't have one. The data: what I process with local models is precisely what I don't want leaving the house. And the cost: I don't pay per use, just the electricity and the machine.

How I divide the work among the four programs I explain in more detail in Ollama, LM Studio, llama.cpp and Unsloth, which I use for what.

Of the more than 50 models I've tested, about twelve are still installed: eight on the GPU server and four on the laptop. I deleted the rest as I saw I wasn't using them. Disks aren't infinite, even if they seem that way at first.

Claude Code is the harness I work with most. I have it on my workstation, which is where I do almost everything from, and on two of the internal servers, where it handles maintenance tasks and log reviews. It isn't permanently installed on the VPSs: when I need it to do something on one, it works from inside the network and logs in with a user with limited permissions.

The reason for keeping it mostly on the internal network is simple: that's where I have control, where my files are and where I can calmly see what it has done before accepting it. If something goes wrong, it goes wrong at home, behind the door.

I've been testing DeepSeek Harness for ten days. I've put it on a separate internal server, the test one, with no access to the other machines except a shared folder. Until I know it well, I'd rather it played in its own room. How those days are going I tell in Ten days working with DeepSeek Harness.

As for access, each harness has its own user on each machine it logs into, with just the permissions it needs for what it does. None of them holds the key to everything. I won't go into more detail, for obvious reasons.

OpenClaw is different from the others because you operate it through messaging apps. You write to it from your phone and it does things. That means it has to be reachable from outside, and that's where the problems start.

I have it on one of the VPSs, dedicated to it alone, and not on the internal network. If someone manages to get into a machine where a harness runs, they get in with the agent's hands: anything the agent can do, the intruder can do. That's why I don't want that machine to have a clear path into my home.

The measures I apply, without going into sensitive details: it only responds to my messaging account, the VPS has the bare minimum installed, the harness runs as an unprivileged user, it has no access to the internal network except to request answers from one specific model, and I check its logs every few days. Exposure isn't eliminated; it's made small. And I assume that if something fails one day, the damage will stay on that machine. That's why it stores nothing it can't afford to lose and holds no keys that open other doors.

I haven't had it long, and I write about it in I've started playing with OpenClaw.

The six VPSs act as the public face and as organisers. Two serve websites, one hosts OpenClaw, two run the services that handle clients and share out work among models, and the last one acts as the gateway into the internal network.

None of them has big models. They have no graphics card, and renting one outside the house doesn't pay off for what I do. So the VPS organises: it receives the request, decides who to pass it to and returns the answer. And it passes it either to a cloud model (Claude, OpenAI, DeepSeek, GLM, Kimi or MiniMax) or to one on the internal network.

The client services use Claude for whatever needs higher quality and DeepSeek or GLM for simple, repetitive tasks, for cost reasons. When the data is sensitive, the request goes to a local model on the internal network.

The key question: how does a request from outside reach a model inside without leaving the internal network open?

With an encrypted tunnel that goes out from home to the VPS that acts as the gateway. The connection is opened by the internal network, not the other way round, so there are no inbound ports open on the home router. The VPS can only request specific things through that tunnel, not wander around the network. Think of it as a doorman who goes out to the street to collect the parcels instead of leaving the building's door open.

That said, not opening ports at home reduces the attack surface, but it doesn't remove the risk. If someone takes over the gateway VPS, they hold the other end of the tunnel. That's why, without going into detail, both ends identify themselves with their own keys, the tunnel only lets traffic through to the few addresses and services that need it, the home machines can't reach the internet through it, every connection is logged, I get an alert if the tunnel drops or unexpected traffic appears, and I have a ready plan to revoke the keys and generate new ones if I suspect anything.

And when something goes down? In July the power went out at home for about three hours. The VPSs kept running, but everything that depended on local models got no answer. The services that had a cloud fallback used it; the ones that didn't returned errors until the power came back.

The weak spot I know I have: there's only one gateway VPS. If it goes down, the internal network is cut off from the outside. It's on my list to fix and I still haven't done it.

The diagram, in one sentence: eight machines at home, with the models on the GPU server; six VPSs outside, with OpenClaw isolated on its own; and a single encrypted tunnel going out from home to the gateway VPS.

The same thing, as a list:

• Home, GPU server (RTX 4070, 12 GB): Ollama, llama.cpp and Unsloth; the everyday models.
• Work laptop (RTX 5070, 8 GB): LM Studio, for testing models.
• Home, workstation: Claude Code.
• Home, test server: DeepSeek Harness, isolated.
• Home, the rest: backups, always-on services, agents, the tunnel client and a server for a client.
• Outside, six VPSs: two websites, OpenClaw isolated, two for client services and the gateway VPS.
• Between them: a single encrypted tunnel going out from home to the gateway VPS.

Since that Tuesday, the map isn't just where each thing runs. For each service I note what data it touches (public, mine or clients'), who it belongs to, where its backup is and when I last tested it, when I last changed its keys and when I updated it. I change keys at least once a year, and straight away if someone no longer needs them or I suspect something.

If I were setting it all up today, I'd change a couple of things. I'd have two gateway VPSs instead of one, so as not to depend on a single machine. I'd record from day one what runs where, in a document that updates itself. And I'd have separated the test machine from the rest sooner, since for months it lived alongside services that really mattered.

What remains to be answered is the underlying question, and I answer it in Is it worth having your own servers?.