SokkoSokko
← Back to blog

Run an AI Agent on a VPS: Cost, Setup, Maintenance Tax

Sokko Team9 min read

What It Actually Takes to Run an AI Agent on a VPS

The cheapest honest way to run an AI agent on a VPS is a small cloud server, Docker, and a systemd unit that restarts the process when the box reboots. That is the whole recipe, and for a hobby agent it works. You rent a virtual private server for a few dollars a month, install a runtime, drop in your API keys, and leave it running. Within an hour you have a persistent agent reachable from anywhere.

The part the tutorials skip is what happens on day 40, not day one. A VPS hands you the entire operating system, which means you also inherit patching, monitoring, log rotation, backups, and the pager. This article covers both halves honestly: the genuinely cheap and simple setup, then the recurring maintenance tax that setup quietly signs you up for. If you want the higher-scale version of this same tradeoff, our piece on running AI agents on Kubernetes covers the cluster path, and the first-agent guide is the gentlest starting point.

What a VPS Costs for an AI Agent

Pricing is the easy part, and it is genuinely low. Two providers dominate the budget tier.

  • Hetzner Cloud CX22: 2 vCPU, 4 GB RAM, 40 GB disk, roughly 4 to 5 EUR per month. See current numbers on the Hetzner Cloud pricing page.

  • DigitalOcean basic droplet: 1 vCPU, 1 GB RAM starts near 4 USD, and the 2 GB tier lands around 12 USD. Check the droplet pricing page for the live grid.

For a single lightweight agent (a research assistant that calls a hosted model API and does modest local work) 2 GB of RAM is comfortable and 1 GB is tight but usable. The model inference happens on the provider's side, so your VPS mostly shuttles requests, holds a working directory, and runs tool commands.

Costs climb when the agent itself does heavier work. A coding agent that clones large repositories, runs builds, and holds several processes wants 4 GB or more, which pushes you toward the Hetzner CX32 or a 4 GB droplet in the 20 to 24 USD range. If you plan to run local models rather than a hosted API, none of these tiers are enough and you are shopping for GPUs, a different budget entirely. For most personal agents, plan on 5 to 15 USD a month for the server, plus whatever your model API usage costs on top.

Setting Up the Agent: Docker Plus systemd

Here is a real setup path on a fresh Ubuntu VPS. It installs Docker, runs the agent container, and wires a systemd service so the agent survives a reboot. If you want each choice explained rather than the condensed version, the full walkthrough on deploying an AI agent on a VPS goes step by step.

# 1. SSH into the fresh server
ssh root@your.server.ip

# 2. Create a non-root user and give it sudo
adduser agent
usermod -aG sudo agent

# 3. Install Docker from the official convenience script
curl -fsSL https://get.docker.com | sh
usermod -aG docker agent

# 4. Store the API key outside the unit file
mkdir -p /etc/agent
printf 'ANTHROPIC_API_KEY=sk-ant-your-key\n' > /etc/agent/agent.env
chmod 600 /etc/agent/agent.env

# 5. Pull and smoke-test the agent image
docker pull registry.example.com/hermes:latest
docker run --rm --env-file /etc/agent/agent.env \
  registry.example.com/hermes:latest --version

Now make it durable with a systemd unit so it restarts on crash and on reboot. Create /etc/systemd/system/agent.service:

sudo tee /etc/systemd/system/agent.service > /dev/null <<'EOF'
[Unit]
Description=Personal AI Agent
After=docker.service
Requires=docker.service

[Service]
Restart=always
RestartSec=5
ExecStartPre=-/usr/bin/docker rm -f agent
ExecStart=/usr/bin/docker run --rm --name agent \
  --env-file /etc/agent/agent.env \
  -v /srv/agent/workspace:/workspace \
  registry.example.com/hermes:latest
ExecStop=/usr/bin/docker stop agent

[Install]
WantedBy=multi-user.target
EOF

sudo systemctl daemon-reload
sudo systemctl enable --now agent
sudo systemctl status agent

Two details are doing real work here. Restart=always with RestartSec=5 means a crashed agent comes back in five seconds instead of staying dead until you notice. The -v /srv/agent/workspace:/workspace bind mount keeps the agent's files on the host disk, so a container restart does not wipe the working directory. That volume is the difference between an agent that remembers its work and one that starts from zero every time the process cycles.

Check the logs with journalctl -u agent -f and you have a running, self-restarting agent for the price of a coffee per month.

First-boot hardening you should not skip

A fresh VPS is exposed to the public internet the second it boots, and bots start probing its SSH port within minutes. Before you consider the setup done, close the obvious doors. Disable password login so only your SSH key works, which alone stops the vast majority of automated attacks:

# Confirm your key works, then turn off password auth
sudo sed -i 's/^#\?PasswordAuthentication.*/PasswordAuthentication no/' \
  /etc/ssh/sshd_config
sudo sed -i 's/^#\?PermitRootLogin.*/PermitRootLogin no/' /etc/ssh/sshd_config
sudo systemctl restart ssh

# Turn on the firewall and allow only what you need
sudo ufw allow OpenSSH
sudo ufw enable

That is the ten-minute version of hardening. It is not complete, but it moves you from wide open to reasonably closed. The point of listing it here is that this step is part of the true setup cost, even though quickstarts tend to leave it out.

The Hidden Maintenance Tax

Here is the part that does not fit in a quickstart. The moment you own a VPS, you own the operating system on it, and an OS in production is never finished. The server that took an hour to set up will ask for attention every week for as long as it exists. This is the hidden maintenance tax, and it is the real cost of the cheap tier.

Consider a realistic timeline. Week two, a Docker base image ships a security fix and your running container is now vulnerable until you rebuild and redeploy. Week five, the disk fills because container logs were never rotated and the agent starts failing writes to /workspace. Week nine, the agent hits an edge case, wedges in a tight loop, and pins the CPU at 100 percent while you are asleep, which is where the 3am page comes from. Week twelve, a kernel CVE lands and you need to patch and reboot, which means planning for the agent to lose its in-flight task unless you handled graceful shutdown. None of these are exotic. They are the normal weather of running a Linux box.

The recurring items you now own

  • OS patching: security updates for the kernel and every installed package, plus the reboots they require.

  • Monitoring: something has to watch CPU, memory, and disk and tell you before they run out, not after.

  • Log rotation: container and system logs grow without bound and will fill the disk if left alone.

  • Backups: the /workspace volume holds the agent's accumulated state, so it needs a real backup schedule and a tested restore.

  • Crash recovery: Restart=always handles process crashes, but not a full host failure or a corrupted volume.

  • Security hardening: SSH key-only auth, a firewall, fail2ban or equivalent, and closing every port the agent does not need.

  • Secret rotation: API keys leak and expire, and rotating them means editing the env file and restarting cleanly.

  • The 3am page: someone is on call for the runaway loop, the full disk, and the provider's own network blips.

Each item is small. Together they are a part-time job. And a single VPS gives you no isolation between agents: if you run three agents on one box and one of them executes hostile code, it can reach the other two, read their keys, and touch their files. Adding real isolation means network namespaces, separate users, or per-agent containers with locked-down capabilities, which is exactly the boundary work that Kubernetes handles with NetworkPolicy and namespaces once you outgrow one server.

Putting a number on the tax

It helps to estimate the real cost rather than wave at it. Say each of the recurring items above averages twenty minutes a month once things are running smoothly, and something breaks badly enough to demand an hour of attention every other month. That is roughly two to three hours a month of steady upkeep, plus the occasional bad evening. At any reasonable value for your time, those hours dwarf the 5 dollar server bill. The server was never the expensive part; the attention is. This is the arithmetic that quietly flips as an agent moves from a toy to something you depend on, and it is why the sticker price of a VPS is misleading on its own.

There is also a reliability ceiling. A single VPS is a single point of failure: if the host has a hardware fault or the provider has a regional incident, your agent is down until they recover, and there is nothing you can do but wait. Building real redundancy on top of one server means a second server, health checks, and failover, at which point you are assembling a small cluster by hand and the maintenance tax roughly doubles.

VPS or Managed: How to Decide

A VPS is the right call when you are learning, when the agent is a personal side project, and when you actively want to understand the Linux underneath. You get full control, the lowest possible bill, and a genuinely educational setup. The tradeoff is that you are the operations team.

A managed platform makes sense the moment the agent matters enough that a 3am outage is a real problem, or when you are running several agents and want them isolated from each other without hand-building the boundaries. This is the honest place for Sokko: it is managed infrastructure for AI agents that absorbs the maintenance tax described above. You deploy in a couple of clicks, each agent's files and memory survive restarts, every agent runs in its own private space walled off from the others, and the patching, monitoring, and upkeep are handled for you instead of landing on your pager.

The decision is not about which is technically superior. It is about whose time the maintenance costs. On a VPS the answer is yours. Weigh the 5 dollar server against the hours you will spend keeping it healthy, and pick deliberately. If you are still at the experimentation stage, start with the personal agent deploy walkthrough and keep the VPS. If the agent is becoming load-bearing, the maintenance tax is the number that should move you.

Wrapping Up

Running an AI agent on a VPS is cheap and satisfying: a 4 to 6 dollar Hetzner or DigitalOcean box, Docker, a bind-mounted workspace, and a systemd unit gets you a persistent, self-restarting agent in under an hour. The catch is everything that comes after the first hour. Patching, monitoring, log rotation, backups, security hardening, and the on-call pager are recurring costs that the quickstart never mentions. Run the VPS with your eyes open to that tax, and switch to a managed layer when your time is worth more than the savings.