How to Let Claude AI Manage Your Production Server Safely

Part 1 of a 5-part series on using Claude AI to run, secure, and ship a real production server. This is the honest, screenshot-by-screenshot account — what I typed, what the AI found, where I got stuck, and how each problem got solved.

I Let Claude AI Manage My Production Server — Here's How I Did It Safely (Part 1)

I run a VPS hosting around 20 live projects — client sites, e-commerce, a medicare system, a couple of crypto bots. One afternoon I decided to try something most people are still nervous about: connecting Claude AI directly to that production server and letting it help me audit, secure, and fix things.

The result genuinely surprised me. Within its first hour, Claude found a security hole I'd walked past for months. But the reason it was safe to do this at all is the setup — the guardrails I put in place before the AI touched anything. This first post is that foundation. If you follow along, by the end you'll have an AI agent working on your server without the power to break it behind your back.

The One Rule That Makes This Safe

Before any command, understand the model that makes AI-on-production sane: the AI gets the brains, you keep the keys.

Claude reads your system, finds problems, plans fixes, writes scripts, and verifies results. But every command that actually changes something goes through you. Think of it like a brilliant new engineer on day one — incredibly capable, but they don't get root access and a blank cheque on their first afternoon. Every guardrail below enforces that split.

Step 1: Harden the Server First (Never Install an AI on a Soft Target)

The AI inherits the security of the account it runs as. So I shaped that account before installing anything — a dedicated non-root user, SSH keys, a firewall:

adduser deploy_user
usermod -aG sudo deploy_user

# In /etc/ssh/sshd_config: PermitRootLogin no, PasswordAuthentication no
sudo systemctl restart ssh

sudo ufw allow OpenSSH && sudo ufw enable

The single most important decision here: the AI runs as a normal user, never as root. Later, that boundary turned out to be a feature, not a limitation — you'll see why in Part 2.

Step 2: Install Claude Code and Live Inside tmux

Claude Code is Anthropic's terminal-based AI agent. It installs on the server itself:

curl -fsSL https://claude.ai/install.sh | bash
echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.bashrc && source ~/.bashrc

tmux new -s setup
claude

Why tmux? An AI session is long-running. If your Wi-Fi drops mid-task, tmux keeps it alive on the server — you reconnect with tmux attach -t setup and pick up exactly where you left off.

A tmux Survival Guide (Because I Got Trapped Too)

If you've never used tmux, one concept unlocks it: every command starts with a "prefix" — Ctrl+B — which you press and release before the next key. Beginners fail at tmux for exactly one reason: they mash all the keys at once. Knock first, then speak.

The commands this whole series uses:

⚠ The trap that catches everyone: the moment you press Ctrl+B [, your keyboard stops typing into the shell — the arrows scroll history instead. It feels like the terminal froze. It happened to me and for a full minute I thought I'd broken everything. The escape is one key: press q and you're back. Nothing was frozen; you were just in a different mode.

Step 3: The Three Guardrails

Guardrail 1 — Manual mode, always. Claude Code asks permission before every command. On production, never enable any auto-approve. Reviewing each command takes seconds and it is the safety model.

Guardrail 2 — Scope the workspace. When Claude starts, it asks whether you trust the current folder. Broad scope for read-only mapping, narrow scope for changes. I launched from the web root once for a read-only audit, but for editing work you launch from the one specific project folder.

Guardrail 3 — Snapshot before, not after. Take a full server snapshot in your host's panel before any session that will change things. It's your catastrophic-failure undo button.

Step 4: The First Task Is Always a Read-Only Audit

Don't ask an AI to change anything on day one. Ask it to map. Here's the kind of prompt I used — notice how hard it leans on "change nothing" and "never read secrets":

Read-only audit — do not modify, create, or delete anything.
Do not read the contents of .env files; check existence and
permissions only.

1. List every project in /var/www and its stack
2. Cross-reference with nginx to find what's actually live
3. List all listening ports and the processes behind them
4. Flag exposed .env files, world-writable dirs, .git in web roots
Output a summary table and rank the top 5 risks.

That "never read .env contents" rule matters: Claude can audit file permissions without a single database password ever entering the AI conversation. Asking for a ranked risk list turned raw findings into an action plan.

The payoff was immediate. Claude produced a full inventory table of every site, cross-referenced against nginx to show which were truly live, listed every open port — and flagged, among other things, a Python API listening on 0.0.0.0:8100, wide open to the internet. Months of exposure I'd never noticed, surfaced by an AI in its first session.

What You've Got After Part 1

• A hardened, non-root account for the AI to operate through
• Claude Code running in a persistent tmux session
• Manual-approval mode so nothing runs without you
• A complete, ranked map of your server's risks — written by the AI, reviewed by you

The mental shift is the real lesson: an AI agent's first hour on your server will probably find something you missed. Mine found a publicly exposed financial API. In Part 2, we fix it — and you'll see the exact human-in-the-loop pattern that lets an AI plan a production change while you keep your hand on the trigger.

👉 Coming up in Part 2: "The Exposed API Claude Found in Its First Hour." Have you ever run sudo ss -tlnp on your own server? Try it and tell me in the comments what's listening that you forgot about.