Deploy an AI Agent on a VPS: Cheapest Always-On Setup

The cheapest always-on setup

If you want your agent running 24/7 without your laptop being on, a small VPS is the cheapest honest answer, and this post is how to deploy ai agent on a vps end to end. You'll pick a low-cost instance, lock down SSH, install a runtime, and run the agent under systemd or Docker so it restarts on crash or reboot. Then, because it's only fair, we'll cover the real limits: on a single VPS you own the patching, the backups, the isolation, and the uptime.

The appeal is money. A box that costs 4 to 6 EUR a month can keep an agent online all day. The catch is that "cheap" refers to the server bill, not the total cost. The rest of the price is your time. We'll be straight about both sides so you can decide whether the DIY route actually pays off for you.

How to Deploy AI Agent on a VPS in Five Steps

At a high level the whole job is five steps, and none of them are hard on their own:

1. Pick a cheap VPS from a reputable provider.

2. Create a non-root user and harden SSH.

3. Install your runtime (Python, Node, or Docker).

4. Run the agent under systemd or Docker so it auto-restarts.

5. Keep it always-on: logs, updates, and a basic backup.

Do those in order and you'll have an agent that survives a crash and a reboot. Here's each step in detail.

Step 1: Pick a cheap VPS

Any mainstream provider works. The differences that matter at this size are price, where the data centers sit, and how sane the control panel is. A few real options as of 2026:

For most single agents, 1 to 2 GB of RAM is enough, since the heavy lifting (the model) runs on someone else's API, not your box. If you're running a local model on the same server, that changes everything and you'll want far more RAM and probably a GPU. Pick the smallest plan that fits, you can resize later.

Choose Ubuntu LTS as the image unless you have a reason not to. It has the most copy-pasteable instructions on the internet, which matters when something breaks at 1 a.m.

Step 2: Create a user and harden SSH

Never run day-to-day as root, and never leave password login on a public box. Bots scan for open SSH within minutes. First, from your own machine, make a key if you don't have one:

ssh-keygen -t ed25519 -C "agent-vps"

ssh-keygen -t ed25519 -C "agent-vps"

Then, on the server, create a normal user, give it sudo, and install your public key:

adduser agent
usermod -aG sudo agent
mkdir -p /home/agent/.ssh
# paste your public key into this file:
nano /home/agent/.ssh/authorized_keys
chmod 700 /home/agent/.ssh
chmod 600 /home/agent/.ssh/authorized_keys
chown -R agent:agent /home/agent/.ssh

adduser agent
usermod -aG sudo agent
mkdir -p /home/agent/.ssh
# paste your public key into this file:
nano /home/agent/.ssh/authorized_keys
chmod 700 /home/agent/.ssh
chmod 600 /home/agent/.ssh/authorized_keys
chown -R agent:agent /home/agent/.ssh

Now turn off the two things attackers rely on. Edit /etc/ssh/sshd_config and set:

PermitRootLogin no
PasswordAuthentication no

PermitRootLogin no
PasswordAuthentication no

Restart SSH with sudo systemctl restart ssh, then open a second terminal and confirm you can still log in as agent before you close the first one. Locking yourself out of a fresh VPS is a rite of passage you can skip. Finally, a minimal firewall:

sudo ufw allow OpenSSH
sudo ufw enable

sudo ufw allow OpenSSH
sudo ufw enable

Step 3: Install the runtime

Update the box, then install whatever your agent needs. For a Python agent:

sudo apt update && sudo apt upgrade -y
sudo apt install -y python3 python3-venv python3-pip git
git clone https://github.com/you/your-agent.git
cd your-agent
python3 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt

sudo apt update && sudo apt upgrade -y
sudo apt install -y python3 python3-venv python3-pip git
git clone https://github.com/you/your-agent.git
cd your-agent
python3 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt

Put your API keys in an env file that only your user can read, rather than hard-coding them:

touch /home/agent/your-agent/.env
chmod 600 /home/agent/your-agent/.env
# add lines like ANTHROPIC_API_KEY=sk-... inside

touch /home/agent/your-agent/.env
chmod 600 /home/agent/your-agent/.env
# add lines like ANTHROPIC_API_KEY=sk-... inside

If you'd rather ship a container, install Docker instead and skip straight to the Docker option in the next step. Both are fine. Docker is tidier for reproducibility; a plain venv is lighter on a tiny box.

Step 4: Run the agent so it restarts on crash

This is the part that makes it "always-on." Running python agent.py in an SSH session dies the moment you disconnect. Even tmux or nohup won't bring the agent back after a reboot or a crash. You want a supervisor, and you already have one: systemd.

Create /etc/systemd/system/agent.service:

[Unit]
Description=My AI Agent
After=network-online.target
Wants=network-online.target

[Service]
User=agent
WorkingDirectory=/home/agent/your-agent
EnvironmentFile=/home/agent/your-agent/.env
ExecStart=/home/agent/your-agent/.venv/bin/python agent.py
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

[Unit]
Description=My AI Agent
After=network-online.target
Wants=network-online.target

[Service]
User=agent
WorkingDirectory=/home/agent/your-agent
EnvironmentFile=/home/agent/your-agent/.env
ExecStart=/home/agent/your-agent/.venv/bin/python agent.py
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

The two load-bearing lines are Restart=always and RestartSec=5: if the agent crashes, systemd waits five seconds and starts it again. Enable and launch it:

sudo systemctl daemon-reload
sudo systemctl enable --now agent
sudo systemctl status agent
journalctl -u agent -f   # follow the logs live

sudo systemctl daemon-reload
sudo systemctl enable --now agent
sudo systemctl status agent
journalctl -u agent -f   # follow the logs live

Because it's enabled, systemd also starts the agent automatically after a reboot. The systemd.service documentation covers every directive if you want to tune restart limits or add resource caps.

Prefer Docker? The container equivalent uses a restart policy, which handles both crashes and host reboots:

docker run -d --name my-agent \
  --restart unless-stopped \
  --env-file /home/agent/your-agent/.env \
  -v agent-workspace:/workspace \
  my-agent:latest

docker run -d --name my-agent \
  --restart unless-stopped \
  --env-file /home/agent/your-agent/.env \
  -v agent-workspace:/workspace \
  my-agent:latest

The named agent-workspace volume matters more than it looks. Without it, every restart wipes the agent's working files. That whole subject deserves its own read: see persistent state for AI agents for how to make sure a restart doesn't erase what the agent has done. The Docker docs cover restart policies and volumes in depth.

Step 5: Keep it always-on

"Always-on" is a habit, not a one-time toggle. A short checklist:

• Logs. Use journalctl -u agent (systemd) or docker logs my-agent to see what happened after a crash.

• Updates. Run apt upgrade regularly, or enable unattended-upgrades for security patches.

• Backups. If state lives on the box, snapshot the volume or copy /workspace somewhere off-server on a cron schedule. Most providers sell automatic snapshots for a small fee. Take it.

• Monitoring. A basic uptime ping (UptimeRobot, Healthchecks.io) tells you when the agent is down instead of you finding out days later.

That's a complete, working, cheap deployment. One agent, one box, restarts on failure, survives reboots.

The honest limits of a single VPS

Here's the part the cheap-VPS blog posts skip. A single VPS is a great way to run an agent, and it's also a pile of responsibilities that quietly become yours the moment you ssh in.

• You own patching. Kernel and package security updates are on you. Skip them and the box drifts toward being a liability.

• You own backups. If the disk dies or you rm -rf the wrong directory, whatever wasn't backed up is gone. Nobody is holding a copy for you.

• You own isolation. Run two agents on one box and, by default, they share the same filesystem, network, and blast radius. One compromised dependency can reach the other. Real isolation takes deliberate work, and it's the reason running multiple AI agents on one server is trickier than it first looks.

• You own secrets. That .env file is your entire security model for API keys. There's no vault, no rotation, no audit trail unless you build it.

• You own scaling. Need a second agent, or a bigger one? You resize, migrate, or repeat the whole setup by hand.

• You own uptime. This is the big one. A single VPS is a single point of failure. If that one machine has a bad day, a noisy neighbor, a failed disk, a data-center incident, your agent is simply down until you notice and fix it. There's no automatic failover on a 5 EUR box.

None of this makes the VPS route wrong. It makes it a real job. For a hobby agent or a proof of concept, that job is small and the price is unbeatable. For something you or customers depend on, the maintenance tax adds up, and it's paid in your evenings.

When a VPS is the right call (and when it isn't)

A quick gut check:

If you're building your very first agent and want the smallest possible on-ramp before worrying about servers at all, deploying your first agent is the gentler starting point.

How Sokko fits

The VPS route is legitimately good, and cheaper on paper: a $5/month box will always undercut a managed service on the raw bill. What you're really deciding is whether you'd rather pay in euros or in evenings. If your time is worth more than the difference, that's where managed hosting earns its keep.

That's the gap Sokko fills. It's managed AI-agent hosting where the patching, the always-on supervision, the per-agent isolation, and the secret handling are done for you. Each agent runs in its own private, isolated space, your API keys are kept in secure storage (never a plaintext .env on a public disk), and its files persist across restarts and redeploys. It's hosted in US and EU regions, GDPR-ready with a signed DPA. You pick one of four ready-made agent runtimes (OpenClaw, Hermes, Paperclip, OpenSRE) from the dashboard in a couple of clicks, and you still bring your own model keys (Claude, GPT, or Gemini) with no token markup, or use Sokko credits. There's a live web terminal per agent, so you don't lose the ssh-in-and-poke-around feeling.

To be fair about price: a bare VPS is cheaper than the roughly $12/month per agent Sokko starts at, and if you love running your own boxes, keep doing it. But if the maintenance tax above sounds like work you'd rather not own, there are $100 in trial credits to see whether handing off the servers is worth it for you.

Key takeaways

• Deploying an agent on a cheap VPS is five steps: pick a box, harden SSH, install a runtime, run it under systemd or Docker, and keep it patched and backed up.

• Use Restart=always in systemd or --restart unless-stopped in Docker so the agent recovers from crashes and reboots.

• Persist working state to a volume or the agent loses everything on restart.

• A single VPS is cheap but makes you the owner of patching, backups, isolation, secrets, scaling, and uptime, and it's a single point of failure.

• The choice is money versus time. For hobby agents the VPS wins; for things people depend on, weigh the maintenance tax honestly.