Einen Coding-Agent rund um die Uhr auf dem Heimserver betreiben
Ein KI-Agent, der nur läuft solange der Desktop an ist, ist ein halbes Werkzeug. Wie ich meinen in einen Container auf dem Heimserver umgezogen habe und von überall erreichbar gemacht habe.
Running a Coding Agent 24/7 on My Home Server
The thing that bothered me about AI coding agents was not the model. It
was that the agent lived in a terminal on my desktop. Close the window,
lose the thread. Walk away from the machine, lose access. Start something
long-running and you are now committed to leaving a gaming PC powered on
all night.
I already run a home server. It is on anyway. Moving the agent there
fixed all three problems at once, and it took an evening.
The shape of the solution
Three pieces, none of them clever:
1. A container with the agent CLI and a toolchain inside it
2. A persistent terminal session so the process survives disconnects
3. A private network path so I can reach it from a laptop or a phone
The interesting decisions are all about what the container is allowed
to do, which I will get to.
The container
A minimal image. Node for the CLI, git, and whatever runtimes the
projects need.
The container does nothing on start. That is deliberate — I attach to it
and start sessions by hand, rather than having it wake up and do things
unsupervised.
Compose, with the parts that matter:
Four things in there are load-bearing:
The config volume. Without it you re-authenticate every time the
container restarts, which you will not tolerate for long.
The work volume is the whole world. The agent can only write inside
it. Nothing else on the server is mounted. If I want it to touch a
project, I clone that project into work/. This is the single most
useful guardrail in the setup.
Read-only SSH keys. It can pull and push with the keys I gave it. It
cannot modify or exfiltrate them through a normal write.
Resource limits. An agent that decides to run a full test suite
should not be able to starve everything else on the box.
Timezone. Sounds trivial. It is not, the moment anything scheduled or
log-related is involved.
Making sessions survive
Docker keeps the container alive. It does not keep your session alive —
close the SSH connection and the foreground process dies with it. That is
what tmux is for.
-A means attach if it exists, create if it does not. One command,
whether it is the first connection of the day or the fifth. Detach with
Ctrl-b d and the session keeps running.
This is the piece that actually delivers the promise. Start a long
refactor from the desk, close the laptop, reattach from the sofa an hour
later, read what happened.
Reaching it from outside
Do not port-forward SSH to the internet. You do not need to.
A mesh VPN — Tailscale, Netbird, WireGuard directly if you enjoy that
sort of thing — puts the server on a private network that follows you
around. The server is reachable from my laptop and my phone, and from
nowhere else. No open ports, no fail2ban, no 3am log full of Chinese
bots trying root/admin.
From a phone this is genuinely usable with any decent SSH client. It is
not comfortable for writing code. It is completely fine for reading what
the agent did and typing "yes, continue" or "stop".
What I got wrong the first time
I mounted too much. The first version had my whole projects directory
in there because it was convenient. It was convenient right up until I
thought about what "convenient" meant, and then I cut it down to a single
work folder. No incident, just a bad idea that I noticed in time.
I gave it a token with more reach than it needed. Same class of
mistake. Scope credentials to what the container actually has to do.
I expected it to be autonomous. It is not, and I stopped wanting it
to be. What I wanted was persistence — the thread outliving my
attention span. That it does perfectly. The fantasy of coming back to
finished work while you slept is a different product, and one I would
trust a lot less.
Was it worth it
The setup is about an evening, most of it spent deciding on mounts rather
than writing anything. What it buys is that the agent stopped being tied
to one desk.
The honest caveat: this moves where the agent runs, not what it costs.
Usage limits are attached to your account, not your hardware. If you are
hitting them on a desktop you will hit them on a server. That is a
separate problem, and a separate post.