On June 18 I shut down two gateways on my server. Not because they were broken. They were healthy. They answered requests. One of them had been my primary inference path not long before. I stopped it anyway, and the part that took the longest wasn’t the shutdown. It was deciding to do it.
Quick gloss, since this stuff has terrible names. A gateway is the piece of software that sits between my AI tools and the companies that actually run the models. Every request passes through it. It holds my API keys — the credentials that cost money when they leak. I ended up running three of them at once, because each one was better at something.
One of them was my fallback plan. When I first set things up, I picked a gateway, then hedged by keeping a second one for the features the first one didn’t have. Then a third, because it was faster at one specific job. Each decision made sense on its own. Stacked together, I had three overlapping things doing one job, and only one of them was the thing my agents actually used.
Every extra gateway is a surface. And I gave one of them a public door. That’s the part I couldn’t stop thinking about. One of the proxies had a management dashboard — the page where you configure providers and edit settings — sitting in the same process as the public endpoint, served on the same port. Same address as the thing the internet can reach. I’d spent months tightening the front door of my server and left a second front door propped open by accident, because a second gateway was a thing I was no longer looking at.
Redundant services fail quietly, and nobody’s watching. Nobody checks the health of the backup. Not me, and not my agents. And the dangerous failure isn’t a crash — it’s drift. A gateway that stopped being used still holds old provider settings, and it still runs its own background syncs on a weekly clock, updating a list nobody reads.
The real cost is attention. Each one runs its own tunnel, its own restart policy, its own copy of my keys. That’s more places a credential can sit, more containers that will try to boot after a reboot whether I remember them or not. Three systems meant three things to check when something felt off — and on a small server, checking is the expensive part.
Here’s the honest reason it took me so long. My first instinct, when I asked whether to shut one down, was to point out how many models it could serve. All true. Also irrelevant — it was 13 active providers of insurance against a failure that hadn’t happened. I’ve now done this twice. In May I decided to consolidate on a gateway and eventually shut the other one down. Two weeks later I reversed course, upgraded it instead, and ran both. That’s how the pile grows: one small sensible exception at a time, until you’re maintaining three of everything and calling it resilience.
The way through was to make the decision reversible. I deleted nothing — containers stopped, services disabled, data intact. If I’m wrong, one command brings any of them back. What I actually got was a server where one process holds the keys, one config file describes what’s reachable from the internet, and a reboot brings up exactly what I think it brings up.
The strongest thing you can run on a small server is less.