I run a Hostinger VPS out of a data center in Mumbai, which hosts my personal site, my blog, a couple of client projects, and a small zoo of Docker containers that I am, in theory, responsible for maintaining. In practice, "maintaining" a VPS as a solo operator means knowing linux, a ton of server related technicalities, SSL certificates expiring at inconvenient hours, backups you forget to check, and a nagging sense that one bad docker-compose up is standing between you and a very quiet Tuesday becoming a crisis.

So on July 6th this year, I did something that sounds unwise the moment you say it out loud: I gave an AI agent the keys to my production server.

Not a chatbot that tells you which command to run while you copy-paste it in nervously (this used to be me, for the record). An agent that actually SSHes in, executes the change, checks that it worked, and tells you the outcome. I named it ITGuy. It runs on an open-source framework called Hermes Agent, and by the end of that first night, working through phases well past midnight IST the way these builds tend to go, it had visibility scripts, deployment scripts, a Telegram interface, an audit trail, and a policy document defining exactly what it was and was not allowed to touch.

How I set it up: Hermes Agent, OpenRouter, and a long chat

The actual setup, if you're wondering, was less "engineering project" and more "conversation." Hermes Agent came pre-installed on the VPS via Hostinger's one-click Docker deployment (remember, this was the easy part), and it runs on OpenRouter underneath, which meant I wasn't locked into one model; the same agent has since run on GLM-5.2, DeepSeek, Qwen, and a couple of others, model-agnostic by design, because the infrastructure knowledge lives in files, not in whatever weights happen to be fashionable that week. I didn't write a spec document. I opened a chat window and just told it what it was looking at: "Provider Hostinger, OS Ubuntu, reverse proxy Traefik, containers are Nextcloud, Ghost, WordPress, ntfy, OpenClaw, and here's the one rule that matters, always ask for approval before changing anything." From there it was back-and-forth, me describing what I wanted (visibility first, then the ability to act, then guardrails around the acting), and the agent proposing scripts, which I reviewed before they went anywhere near root. The whole SOUL.md identity document, the one defining it as conservative and security-first and calm under failure, got built the same way: not handed down from on high, but argued into existence over a long chat that ran, true to form, well past midnight.

Three weeks later, it has deployed a personal profile website, my blog on Ghost, a WordPress site, a Next.js net-worth tracker, and a client's portfolio site, all without me touching a terminal. It monitors SSL expiry, security patches, and container health every Friday morning and reports back over Telegram like a slightly obsessive but very polite sysadmin-cum-diary-keeper.

Here is the part most people skip past: the reason this hasn't blown up my server is not that the AI is smart. It's that it's deliberately, almost bureaucratically, powerless.

The AI agent security model: why a leash matters more than intelligence

The itguy user on my VPS is not in the docker group. It is not in sudo. It cannot run docker ps directly, cannot see the API tokens for DNS or backups, and cannot modify a single one of the thirty scripts that constitute its entire vocabulary of action. What it can do is invoke pre-approved, root-owned scripts, and only after I've typed an exact phrase like YES DEPLOY GHOST show.ayebee.xyz (not "ok," not "sure, go for it," the literal phrase, because fuzzy matching is how confident agents delete the wrong container).

Every action follows the same seven-step ritual: understand the request, inspect the actual server state (never assume), write a plan, stop and wait for approval, execute one step at a time, verify independently that it worked, and write an audit entry to a git-tracked log. It announces its own operating mode in every message, "Mode: OBSERVE, no changes made," which is either reassuring or vaguely dystopian depending on how your week is going.

The honest insight here, and this is the bit most "AI agent" writing gets backwards, is that the interesting engineering problem was never getting the model to be capable. Frontier models have been capable of running a VPS for a while now. The problem was building a cage precise enough that capability stops mattering, because the agent physically cannot do the catastrophic thing even if it hallucinates wanting to.

Three infrastructure bugs an AI agent caught that I wouldn't have

The SSL watch that lied for weeks. A cron job ran every Friday, reported success, and had been silently checking zero domains, because a config file called domains.txt simply didn't exist. The script exited cleanly with "no domains provided," and cron, being cron, took that as a job well done. ITGuy found this by accident while deploying an unrelated app. Which is the quietly terrifying thing about monitoring: it can fail successfully for a very long time.

The logo nobody could see. My site's white logo was, on inspection, a PNG with alpha values ranging from 6 to 248 out of 255, technically white text, invisibly faint against a dark background. Nobody had noticed because nobody was looking at the alpha channel; they were looking at a logo that seemed fine on a bright monitor. ITGuy opened it in Pillow, found the problem in about four lines of Python, and fixed it in one.

The reverse proxy bug that came and went. A container with perfectly correct routing labels returned a flat 404, no errors, nothing in the logs. Traefik, it turned out, has an intermittent bug in its Docker provider that ITGuy diagnosed, worked around with a file-based fallback, and documented so thoroughly that when the exact same bug showed up (or didn't) six days later, the fix was already sitting in a skills file waiting to be reused.

None of these are dramatic stories. That's rather the point. Infrastructure doesn't usually fail with a bang; it fails quietly, in the gap between "looks fine" and "is fine," and that gap is exactly where a tireless, unglamorous agent earns its keep.

What I actually think about AI agents running production infrastructure

Everyone currently building "AI agents" is obsessing over how much a model can reason about. I think the more useful question, at least for anything touching production, is how little it needs to be trusted with. The agents worth building aren't the ones with the most autonomy; they're the ones where autonomy and blast radius have been deliberately, almost stubbornly, decoupled.

ITGuy hasn't made me a better sysadmin. It's made the gap between competent and negligent a lot smaller, which for a one-person operation running real websites is, frankly, most of what I need.

I still don't fully trust it. I just no longer need to.

FAQ

What is ITGuy?
ITGuy is an autonomous AI infrastructure agent that manages a production VPS (server provisioning, deployments, DNS, SSL renewal, and backups), built on the Hermes Agent framework and controlled through a Telegram chat rather than a dashboard or CLI.

What is Hermes Agent?
Hermes Agent is an open-source AI agent framework by Nous Research that supports tool use, persistent memory, scheduled cron jobs, and messaging gateways like Telegram, Discord, and WhatsApp. It's the framework ITGuy runs on.

What does OpenRouter have to do with it?
OpenRouter is the model-routing layer underneath Hermes Agent, which is why ITGuy is model-agnostic: the same agent identity and skill set has run on GLM-5.2, DeepSeek, Claude, Chatgpt, Qwen, Nemotron, Hy3 and other models without losing capability, because the infrastructure knowledge lives in files and scripts, not in any one model's weights. It unlocks the use of over 100 closed and open source models in a single dashboard.

Is it safe to let an AI agent manage a production server?
Only if capability and blast radius are deliberately decoupled. ITGuy's user account has no Docker or sudo access; it can only invoke a fixed set of root-owned, pre-approved scripts, and only after an exact human approval phrase. The safety comes from the permission model, not from trusting the model's judgment.

Can an AI agent replace a sysadmin or DevOps engineer?
Not in this setup, and that's by design. ITGuy narrows the gap between "competent" and "negligent" for a one-person operation; it doesn't remove the human from the approval loop for anything that changes state.