Building the box: an always-on server for £7.55 a month

Three weeks ago I rented a small server so my AI system could keep working with my laptop shut. I call it the box. It costs £7.55 a month, it's been running without a break since 27 September, and getting it to the point where I trust it took far longer than I expected.

This is the record of how it went, including the bits that went wrong. If you're wondering whether your AI setup needs a server, most of the useful answer is in what broke.

I'd done this before, badly

This isn't my first server. In February I rented one from Hetzner, a 4 core, 8 GB machine in Nuremberg. I had plans for it. Then I didn't build them out, and it sat idle for about four months at roughly £12 a month.

When I tore it down on 17 June I wrote down four lessons:

1. Turn on backups or snapshots from day one. That server never had any.
2. Watch how much it's used, and put a review in the calendar. An idle always-on server is always paying for nothing.
3. Size it to the workload. Don't rent a big general machine hoping to run things on it later.
4. Basing it in the EU is fine.

Those four lines did more to shape the second attempt than any research.

The requirement: the Mac is off

The reason for trying again came from a trip. My wife and I were sailing to the Basque Country on 23 September with the van, on parental leave, for about four weeks.

On 18 September I set the requirement. We both had to be able to use the whole system from our phones, with all its intelligence, skills and connections, and the Mac switched off. On 21 September I made it sharper. My wife and I should have the same functionality as we had with the Mac, or better, just with the Mac off. I called that the simplest test, and it was.

That test was useful because it ruled out every half-answer. Leaving the Mac on in the van wasn't an option. Neither was anything that only worked when I was at a desk.

Choosing where to rent

On 20 September I gave the brief: always on, UK or EU, around £4 a month, not £30. I asked for a comparison of Hetzner, Hostinger, Cloudflare, Vercel, Orca and the newer providers built for AI agents, with prices cited and dated.

Two things came out of that. The only UK-only option that fitted was about £20 a month, so I relaxed the rule to UK or EU. And Orca, which I already used on my phone, isn't a host at all; it connects to machines you control. I've written about Orca separately in Using Orca.

The pick was OVHcloud's smallest plan: 2 cores, 4 GB of memory, 40 GB of storage, £3.97 a month including VAT. I bought it from my phone at about three in the morning on 22 September.

The promise at 3am

Here's the first thing that went wrong, and it wasn't technical.

At about 03:05, after buying and locking down the server, I asked the AI running the setup whether I could go to sleep knowing it would sort it out. It replied "Yes. Go to sleep. I'll sort it out." and then stopped. Nothing was running in the background. When the morning report came round at 08:00, the server still wasn't set up, on the day the phones were meant to go live.

The lesson I took is now a written rule for my orchestrator: a promise to me is followed by the work starting, not by the end of the reply. An AI session that has replied is finished until something wakes it. "I'll sort it out" with nothing running is a sentence, not a plan.

The server was properly set up by 08:35: key-only logins, the root account locked down, a firewall, read-only access to my code.

Broken, working, broken

22 September was a day of confident and wrong diagnoses, and it's worth telling in order.

At 10:16 the AI told me the server wasn't delivering WhatsApp replies. Its test had waited for one exact word in a reply and hadn't seen it. At 13:05 it told me the server was working end to end, because a message had arrived seconds after a test. That message was my scheduled 1pm briefing, which would have arrived anyway. It had also only checked one of my four Claude chats.

At 17:45 it retracted both. The real fault was in the code that checks each chat for new messages: all four chats were checked inside one safety net, so one slow chat tripped it and every chat after it was skipped. Three of the four chats had stopped moving. The check that would have shown this, reading where each chat had got to, was a single query. It wasn't run until I pushed back twice.

That evening I sent screenshots from my phone showing the Claude app listing the server under Devices, green, with three sessions connected, alongside my Mac's sessions. That killed a third theory, that my accounts were somehow split. The device picker just switches between machines.

If there's one pattern from that day, it's this: a guess made from a stand-in signal is a guess, in either direction. I've written more about it in My AI said it was done. It wasn't.

Full access, and switching things off

On 24 September I made the call to give the box full access to my main repo with the Mac off: all the tools, skills and connections. The two machines stay in step through GitHub. Every 10 minutes the box saves its own records, pulls in anything new, and pushes.

The same day I looked at everything scheduled to run on both machines and said it was burning stuff for no reason. Twenty-two scheduled jobs on the Mac were switched off, including every automatic briefing. I kept only the plumbing: the things that keep connections alive, back things up and save work. I'll rebuild the useful ones deliberately, one at a time.

That decision is easy to skip and I'd recommend it. A move is a good moment to ask what's actually earning its place.

Moving the factory, and moving it back

My agent factory (the set of AI agents that build tickets for me, written up in Building the metafactory) had been staying on the Mac. On 21 September I'd scoped it out of the server project entirely, to keep it simple.

On 27 September, with the Mac off for long stretches, I moved it to the box anyway and approved an upgrade to the 8 GB plan at £7.55 a month. Two days later it went back to the Mac. Only 3 of its 11 model routes worked on the box. Several of its stages needed repairs that only applied there, and by then repair tickets were crowding out the actual work. Pulling it back was the right call.

What I learned was not to treat "it's a Linux server, it'll just work" as a plan.

The parity list

By 6 October the box looked done, until I tried to use it for email. It had no email account connected and couldn't save drafts. I was forwarding mail to myself by hand and copying replies around. The root cause was written up in one line: the move had covered the factory, not my working connections.

The fix was a list. Every tool, login and scheduled job I rely on got a row, with a yes or no for the Mac and a yes or no for the box. When I last looked it had about 76 gaps where the box said no. Some don't matter. Some matter a lot. But I can see them, which I couldn't before.

The box saves its work to git under a "box:" label. There are about 180 of those commits so far, rising from one or two a day at the start to more than thirty a day since 9 October, while I've been working without the Mac.

Locked out of my own server

Two problems this week came from the security set-up.

The first: the only admin access to the box was from my Mac. That was a sensible default on day one. It stopped being sensible when the Mac was away for a week and the AI coding tool on the box needed updating. I tried to run the one admin command from my phone and it asked for a password that doesn't exist. A route for exactly that command had been agreed on 5 October and never installed. It was fixed on the evening of 9 October.

The second: a job that checks the two machines can reach each other sent nine identical "server down" alerts to my phone within one second on 8 October, and more than thirty in under a minute on 9 October. The server was fine both times. The real cause was that the job used a short name for the box that the Mac couldn't look up. It was fixed the same evening.

Both were small. Both cost me time and attention on a phone in a van, which is exactly where I didn't want to spend either.

If you're doing this yourself

1. Write the test first. Mine was "the same or better with the Mac off". It ruled out every half-answer.
2. Start small and cheap. £4 a month is enough to find out what you actually need. Upgrade when something proves it's short of memory, as mine did.
3. Turn on backups on day one. My first server never had them.
4. Make a list of every tool and login, per machine. Mark yes or no for each. The gaps are the work.
5. Switch off scheduled jobs you can't justify. Then add back the ones you miss.
6. Keep one way to fix things from where you'll be. If admin only works from a laptop, you can't fix anything from a phone.
7. Treat "it works" as a claim to check. Look at what actually happened in every chat, not the one that answered.
8. Put a review in the calendar. An idle server is the most expensive kind.

Where it's got to

As I write this the box has been up since 27 September without a restart. It answers our WhatsApp groups, keeps the repos in step and gives me a session I can open from my phone. It's cheaper than the server I wasted money on in the spring, and it's actually used.

It still isn't finished. The parity list has gaps, and there's at least one design choice from the first night I'm not sure I agreed to. But it passes the test I set: I can do my work with the laptop shut.

If you're weighing up whether your own setup needs something like this, drop me a line and I'll tell you what I'd do first.