How to Set Up a VPS for Your AI Agents (Step by Step)

This is the practical companion to our AI agent hosting guide: a start-to-finish walkthrough for giving an agent its own server. Thirty minutes, $5–20 a month, and you never have to worry about an agent experiment eating your laptop again.

Step 1 — Pick a provider and size

Any major VPS provider works: Hetzner, DigitalOcean, Vultr, Linode, and friends all offer the two things that matter — root SSH and an API. For a single agent doing web work, 2 vCPU / 4GB RAM / 40GB disk is a comfortable start; you can resize later, so err small. Choose the datacenter region closest to the services your agent talks to, not to you — the agent doesn’t care about its own ping times to your house.

Step 2 — Provision with a key, not a password

Create the server with Ubuntu LTS (the boring choice is the right choice — every tool documents Ubuntu first). Add an SSH public key at creation time and disable password login from day one. If your agent framework manages its own keys, generate a dedicated keypair for the agent rather than reusing yours — you want to be able to revoke the agent without locking yourself out.

Step 3 — The ten-minute hardening pass

• Create a non-root user for the agent with sudo where needed: adduser agent && usermod -aG sudo agent
• Firewall: ufw allow OpenSSH && ufw enable, then open only the ports the agent’s services actually need.
• Unattended security updates: apt install unattended-upgrades.
• fail2ban for SSH: apt install fail2ban. Done.

Step 4 — Install the agent’s toolbox

Most agents want the same base kit: git, docker, a modern runtime (Node and/or Python), and whatever CLI your agent framework uses. Docker earns its place immediately — it lets the agent run databases, apps, and experiments in containers it can destroy without hurting the box.

Step 5 — Connect your agent

How the agent reaches the server depends on your stack, but the patterns are consistent: SSH access configured with the agent’s own key; environment variables or a secrets file for API tokens (never hard-coded); and if the agent manages applications like WordPress, an MCP connector or application password scoped to that one site — our MCP explainer covers why that beats screen-driving an admin panel.

Step 6 — Snapshot before you let it loose

Take a provider snapshot the moment the box is configured and clean. That snapshot is your undo button for everything the agent does afterward. Snapshot again before any big experiment. Storage is pennies; rebuilding a server from memory is an afternoon.

The whole setup as one copy-paste block

Once you’ve done steps 2–4 manually and understand them, here’s the condensed version for every server after the first. Run as root on a fresh Ubuntu box, then log out and back in as the agent user:

adduser --disabled-password --gecos "" agent
usermod -aG sudo agent
mkdir -p /home/agent/.ssh
cp ~/.ssh/authorized_keys /home/agent/.ssh/
chown -R agent:agent /home/agent/.ssh
ufw allow OpenSSH && ufw --force enable
apt update && apt -y install unattended-upgrades fail2ban git docker.io
usermod -aG docker agent
systemctl enable --now docker fail2ban

Ten lines, ninety seconds, and the box matches everything this guide covered. Better yet: paste this guide’s URL into your agent and let it run the setup itself — that’s not a joke, it’s the workflow.

Knowing it’s alive: minimum viable monitoring

You don’t need an observability stack for one agent box. You need two things: a free uptime ping (UptimeRobot, Better Stack, or your provider’s built-in monitoring) pointed at any service the agent exposes, and the provider’s billing alert set at twice your expected spend. The first tells you the box died; the second tells you the agent got creative. Add real monitoring when you add real workloads — not before.

When something breaks: the five-minute triage

Sooner or later the agent reports it can’t reach the server, or the server stops answering entirely. Before you rebuild anything, walk this list — it resolves the majority of incidents:

• Can you SSH in yourself? If yes, the server is fine and the agent’s credentials or config drifted. Check its key and its known_hosts.
• Provider console says what? Every VPS provider has an emergency console that works even when SSH doesn’t. If the box is out of memory, you’ll see it here first.
• Disk full? The most common agent-inflicted wound — logs and Docker images pile up. df -h then docker system prune fixes more incidents than any other command.
• Did the agent change the firewall? If it was “improving security” recently, it may have locked you both out. The provider console gets you back in.
• Still stuck after ten minutes? Restore the snapshot. This is why you took it. A rebuilt-from-snapshot server in four minutes beats an archaeology session every time.

Notice what’s not on the list: panic. Nothing on a properly set up agent box is unique or irreplaceable, so the worst case is always “restore and move on.”

The rules that keep this safe

• One agent, one server (or one container) — isolation is the whole point.
• The agent’s box holds nothing you’d cry about losing. Backups flow off the box, not onto it.
• Scoped, revocable credentials only. When in doubt, make a new token.
• Set a billing alert at 2× expected spend. Loops happen.

That’s the whole setup. The free Hosting for AI Agents course will go deeper on multi-agent fleets, MCP servers, and production patterns — this page gets your first agent its first home today.

Frequently asked questions

Which VPS provider is best for AI agents?

Any provider with root SSH, an API, and snapshots works — the workflow in this guide is identical across Hetzner, DigitalOcean, Vultr, and Linode. Pick on price and datacenter region. Hetzner tends to win on price per GB of RAM; DigitalOcean has the gentlest interface for first-timers.

How big a server does an agent need?

Start with 2 vCPU and 4GB RAM. That comfortably runs a web-work agent with Docker. Resizing up later is a five-minute operation at every major provider, so buying headroom in advance mostly wastes money.

Should each agent get its own server?

One agent per server is the simplest safe pattern and the right starting point. Move to one bigger box with a container per agent only when the fleet is large enough that the per-server cost hurts — and accept that isolation gets a little weaker when you do.

Is it safe to give an agent root access?

On its own disposable box, with nothing valuable stored there and a snapshot to roll back to — yes, that is the design. The rule that matters is the blast radius: the agent can have root on its server precisely because that server holds nothing you cannot rebuild in ten minutes.