Back to list

How Claude Became My System Administrator

devopsaisecurityclaude
How Claude Became My System Administrator

I don't have a system administrator on staff. I build my own apps, but my server administration skills are — let's be honest — mediocre at best. On the cheapest (and not exactly rock-solid) hosting I could find, I run several projects on a single VPS: this website and blog, Poetory, a time tracker, and a language flashcard app (still in internal testing). All on Dokku, all in Docker containers. It worked — so I didn't worry about it.

Then everything broke.

A Crypto Miner in Production

One day I noticed the server was barely responsive. Sites took half a minute to load before timing out, deployments hung indefinitely. First thought: "hosting provider issue" — it happens with them from time to time. A reboot didn't help much.

I work with Claude Code — a command-line version of Claude that can execute commands, read files, and generally interact with your system. And if there's anything a CLI tool should handle well, it's a remote terminal. I described the problem and gave it access to my server via SSH key.

Claude figured it out pretty quickly. Checked the load with htop, saw the CPU pinned at 100%. Started investigating where the load was coming from — found a suspicious process inside one of the Docker containers. Analyzed it and delivered the verdict: XMRig cryptocurrency miner was running inside the container.

How did it get there? In December 2025, a critical vulnerability CVE-2025-55182 was discovered in React Server Components, dubbed React2Shell. Maximum severity — CVSS 10.0. The vulnerability allowed any unauthenticated user to execute arbitrary code on the server via a specially crafted HTTP request.

The RondoDox botnet was massively exploiting this vulnerability, deploying crypto miners on vulnerable servers. By the end of December 2025, over 90,000 servers worldwide had been compromised.

When the vulnerability was disclosed, I updated all my applications. All except one — I simply forgot about it. That's exactly the one the miner got into.

Claude quickly removed the infected container, helped update the vulnerable application, and checked the remaining containers for compromise. The server could breathe again.

Memory Shortage and Virtualization Issues

Some time later, the server started lagging again. I assumed I'd caught something again and turned to Claude once more. It checked — this time there was no malware. The problem was simpler: not enough RAM. Several projects, each with its own Docker containers running Node.js and Django, plus databases — it was all consuming more than the VPS had available. Swap couldn't keep up, which meant it was time for an upgrade.

I upgraded my VPS plan, added more memory. The speed problem went away, but a new one appeared: random freezes. The server would hang for several seconds at a time with no apparent cause.

Claude once again pinpointed the issue pretty accurately. The culprit was page_reporting_process — a mechanism that reports free memory pages from the guest VM to the hypervisor. On a VPS this is a typical situation: the hosting provider uses virtio-balloon to manage memory between virtual machines, and this process can cause latency spikes.

Claude helped compose a proper support ticket to the hosting provider requesting a migration to a different physical machine. Support responded, migrated the VPS — the freezes stopped.

Day-to-Day Administration

After these incidents, I started using Claude Code regularly for server tasks:

  • Setting up new Dokku apps — creating applications, connecting domains, configuring SSL via Let's Encrypt, environment variables
  • Database backups — setting up regular PostgreSQL backup routines
  • Migrations — running Django migrations on production
  • Debugging — analyzing logs, finding errors, diagnosing issues
  • Optimization — configuring memory and CPU limits for Docker containers so a single build doesn't hang the entire server

I think all of this could have been done manually, without Claude, but it would have taken far more time, effort, and reading through piles of assorted documentation.

So: How to Use Claude for Hosting Management?

After several months of using Claude as a server administrator, I've arrived at three key ideas:

1. Always approve commands manually. Claude Code asks permission before executing each command on the server by default. Don't disable this. Production is production. I review every command before hitting Enter, even if it looks harmless.

2. Create a dedicated hosting skill. Claude Code supports system-wide instructions that are available across all projects. I wrote down everything: how to connect to the server, the tech stack, config file locations, storage mounts, deployed applications. Now in any project, Claude already knows the server context and doesn't ask unnecessary questions. When something changes — gets added or removed — the skill needs to be updated periodically.

How to Build Your Own Hosting Skill

A skill in Claude Code is a markdown file with instructions, stored at ~/.claude/skills/<name>/skill.md. It starts with a YAML header containing the name and a description of when the skill should be activated. The rest is plain markdown with instructions.

The description acts as a trigger. Claude Code reads it and decides when to attach the skill to the context. I wrote something like: "use when the user asks to deploy, connect to the server, check logs, restart an app, or perform any server operations." Now in any project, when I say "deploy" or "check the logs," Claude automatically pulls in the right instructions.

Here's what's worth including in a skill like this:

Server connection. The SSH command with the key path and username. This is the first thing Claude will use for any server task. Example structure:

ssh -i "path/to/key" [email protected]

Application table. If you have multiple projects, a table with app names, deploy branches, and domains saves a lot of time. Claude won't ask "what's the Dokku app name?" every time:

| Project | App Name | Branch | Domain | |-------------|-------------|--------|-------------------| | My Web App | myapp-web | main | myapp.com | | My API | myapp-api | main | api.myapp.com |

Deploy commands. How exactly to push code — via git push dokku, through CI/CD, or some other way. If deployment requires setting environment variables (e.g., GIT_SSH_COMMAND), that's worth documenting too.

Frequently used commands. Viewing logs, restarting apps, running migrations, managing environment variables — everything you do regularly. No need to memorize the syntax; Claude will pull it from the skill:

dokku logs <app-name> --tail dokku ps:restart <app-name> dokku run <app-name> python manage.py migrate dokku config:set <app-name> KEY=value

Storage mounts. If your applications use persistent storage (media files, ML models, static assets) — document the mount paths. Without this, Claude might accidentally recreate a container and lose data.

Resource limits. If you limit memory and CPU for containers (and on a VPS you should), write down the current limits and the commands to configure them. This is especially important for builds — without limits, building one project can take down the entire server.

The whole file ends up being 50–80 lines — not enough to clutter the context, but enough for Claude to handle any server task without unnecessary questions.

3. Never give automatic deployment access. Every commit, push, and deploy — only with explicit permission. Claude may suggest deploying, but the human should be the one to do it. One approval doesn't carry over to the next action. There's one problem I haven't fully solved yet, even though I've written this into the instructions both at the system level and in some project-level configs. If you tell Claude to deploy something several times and it does, eventually it starts deploying automatically without asking, assuming it now has standing permission. It's worth explicitly adding to your prompt: "do not deploy anything until you're asked directly." Then it listens.

Conclusion

AI won't replace a professional DevOps engineer. But for an indie developer who wears all the hats — it's already an indispensable tool. Claude found the crypto miner faster than I would've figured out htop. Diagnosed a virtualization issue I didn't even know existed. And continues to help with routine tasks that used to eat up my evenings.

Just remember — the responsibility for production is still on you. Claude is a very smart assistant, but not autopilot.

© 2026 Ivan Bezdenezhnykh. All rights reserved.