AI Agent

How to Run AI Agents 24/7 on a VPS

· 5 min read · YayaAgent Team

Most people picture "running an agent 24/7" as just leaving the terminal window open. It's not — the moment your SSH session drops, your laptop sleeps, or the process crashes on an unhandled error, the agent is gone until someone notices and restarts it by hand. Running something 24/7 means a supervisor that restarts it automatically, logs it goes to journald or a file instead of nowhere, and a workspace that's clean enough not to break on the tenth run just because it worked on the first one.

This guide covers that setup for OpenClaw and Hermes as background agents, and for n8n as a workflow engine — using the same VPS, the same principles, different process managers.

This assumes you've already installed OpenClaw or Hermes on your server and just need to make it stay running. If you haven't gotten that far yet, start there first.

Quick Decision Guide

Tool 24/7 Method
OpenClaw Built-in daemon installer (--install-daemon), or a hand-written systemd unit for more control
Hermes Hand-written systemd unit (recommended), or Docker with --restart unless-stopped
n8n Docker Compose with restart: unless-stopped, already covered if you followed the server deployment path

Step 0: Get the Basics Right First

Two things will sabotage a 24/7 setup before you even get to process supervision, and both are easy to rule out in five minutes.

Auth. A systemd unit that restarts a process every 5 seconds because the API key is wrong just produces an infinite crash loop with a slightly longer interval between crashes. Before configuring auto-restart, make sure your API keys are correctly set — test the agent manually in the foreground first, confirm it responds, then move it into the background.

Environment. A daemon that inherits a broken or inconsistent environment will fail in ways that are much harder to debug once it's running headless with no terminal to watch. A clean environment is the foundation for stable 24/7 operation — resolve dependency conflicts before you wrap anything in a supervisor, not after.

1. Running OpenClaw 24/7

OpenClaw has a built-in daemon installer that handles most of this for you:

openclaw onboard --install-daemon

This registers OpenClaw as a background service — systemd on Linux, launchd on macOS — that survives reboots and restarts automatically on crash. For an existing install, the equivalent is:

openclaw daemon restart
openclaw doctor --fix       # health check + auto-fix common issues
openclaw logs --follow      # real-time log tail

If you want more control than the installer gives you (resource limits, a dedicated non-root user, custom restart behavior), write the systemd unit by hand instead:

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

[Service]
Type=simple
User=openclaw
WorkingDirectory=/home/openclaw
ExecStart=/usr/bin/openclaw start --daemon
Restart=on-failure
RestartSec=5
StartLimitIntervalSec=300
StartLimitBurst=5
Environment=HOME=/home/openclaw
StandardOutput=journal
StandardError=journal
SyslogIdentifier=openclaw
MemoryMax=2G
CPUQuota=200%

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now openclaw.service
sudo journalctl -u openclaw.service -f    # follow logs

StartLimitBurst=5 inside StartLimitIntervalSec=300 matters more than it looks — without a cap, a genuinely broken config restarts in a tight loop forever instead of giving up and telling you something's wrong. On a VPS with under 2GB of RAM, add a swap file before you start — OpenClaw's install and update steps can spike memory in ways a small instance won't absorb otherwise.

2. Running Hermes 24/7

Hermes doesn't ship a one-command daemon installer the way OpenClaw does — the documented path is a hand-written systemd unit, with Docker as the cleaner alternative if you're already running containers.

systemd (recommended for bare-metal installs):

[Unit]
Description=Hermes Agent gateway
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=youruser
WorkingDirectory=/home/youruser
Environment="HOME=/home/youruser"
ExecStart=/home/youruser/.local/bin/hermes gateway start
Restart=on-failure
RestartSec=10
StandardOutput=journal
StandardError=journal
SyslogIdentifier=hermes
MemoryMax=2G
CPUQuota=200%

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now hermes-gateway.service

If you're running as a non-root user and the service keeps dying on logout, you're missing lingering enablement:

loginctl enable-linger $(whoami)

Docker (cleaner isolation, simpler restarts):

docker run -d \
  --restart unless-stopped \
  --name hermes \
  -v $HOME/.hermes:/root/.hermes \
  ghcr.io/nousresearch/hermes-agent:latest serve

The volume mount is what makes memories, skills, and config survive a container restart or upgrade — don't skip it. If you're on WSL2 specifically, systemd support is unreliable there; fall back to hermes gateway run inside a tmux session instead of fighting the service manager.

3. Running n8n 24/7

If you followed the server deployment path when installing n8n, you already have this covered — the Docker Compose setup there uses restart: unless-stopped on both the n8n and Postgres services, which handles reboots and crashes the same way Restart=on-failure does for a systemd unit. The one thing worth double-checking on an existing deployment:

docker compose ps        # confirm both services show "Up"
docker compose logs -f n8n

If a container shows Restarting on a loop, treat it the same way as an OpenClaw or Hermes crash loop — check auth and environment first (Step 0 above) before assuming it's an n8n-specific bug.

4. Monitoring, Not Just Restarting

A supervisor that restarts a crashed process is necessary but not sufficient — a process that's technically "up" but responding slowly is a different failure mode that Restart=on-failure won't catch, because the process never actually crashes. Watching for that is part of running anything in production:

docker stats --no-stream      # quick resource check across all containers

Monitoring latency is part of any production setup — the same context-bloat, database, and tool-overhead issues that make an agent feel slow in a chat session compound quietly when nothing's watching for hours or days at a stretch.

5. Orchestrating Scheduled Tasks

Both OpenClaw and Hermes have built-in cron-style schedulers for recurring jobs (daily briefings, hourly checks) delivered straight to a messaging platform. That's the right tool when the job lives entirely inside one agent's context. Once you're coordinating multiple steps across different services — pulling from an API, transforming data, then notifying a channel — pairing your VPS agent with an automation platform gives you a visual, debuggable workflow instead of scheduling logic buried inside agent config, with per-step execution history to see exactly where something failed.

Myth vs. Reality

Myth: Once I set Restart=always (or unless-stopped), my agent is production-ready.

Reality: Auto-restart handles crashes, not slowness, silent failures, or a broken config that fails identically every single time it restarts. Think of a restart policy less like a safety net and more like a smoke detector — it tells you something's wrong and keeps the fire from spreading, but it doesn't fix the wiring. Logs, health checks, and rate-limited restart attempts are what turn "it keeps coming back" into "it keeps working."

Troubleshooting

Symptom Fix
OpenClaw gateway dies the moment SSH disconnects You're running it in a bare terminal — use openclaw onboard --install-daemon or a systemd unit
Hermes systemd service dies on logout (non-root user) Missing loginctl enable-linger $(whoami)
Service restarts in a tight, endless loop Auth or environment issue, not a supervisor issue — check API keys and config first
n8n container shows "Restarting" repeatedly Same as above — check docker compose logs -f n8n before assuming it's n8n-specific
Everything's "up" but responses feel slow Restart policies don't catch this — see the latency diagnosis guide

Bottom Line

24/7 operation isn't one setting, it's a supervisor (systemd, Docker's restart policy, or a built-in daemon installer), a clean environment underneath it, and monitoring on top so you find out about slowness before a user does. OpenClaw's --install-daemon and Hermes' hand-written systemd unit solve the same problem in slightly different ways; n8n solves it at the Docker Compose level if you already set it up with restart: unless-stopped. Get auth and environment right before you wrap anything in a supervisor — a restart policy just makes a broken config fail faster, not less.

Further reading: