How to host an AI agent 24/7

Most agents that call a hosted model API do not need a GPU. A small always-on Linux server or container is enough, provided it has a process supervisor, persistent storage, secrets kept out of the code and backups that leave the machine. Managed platforms take restarts and deploys off your hands, but check their scale-to-zero defaults, or a background agent stops when no requests arrive. Rent a GPU only when the agent runs its own model, and size it for the context length the agent needs. Budget with the price a plan renews at, not an introductory first-term price.

• API-backed agents run on a small VPS or container; the model bill is separate from hosting.
• Keep it running with a supervisor: a systemd service, a container restart policy or a platform set to always-on.
• Keep its state: persistent storage plus off-machine backups of memory, sessions and configuration.
• Contain it: private admin access, allow-listed senders, sandboxed tools and secrets outside the workspace.
• Budget with the renewal price: an always-on agent outlives any introductory term.

An agent that runs around the clock is a long-running process with state. It listens to chat channels or webhooks, runs scheduled work and remembers earlier conversations. OpenClaw, for example, is a self-hosted gateway that connects messaging apps such as WhatsApp, Telegram, Slack and Signal to AI agents, and its setup guide describes an “always-on AI assistant” [1]. Hermes Agent’s documentation says it can live on a small VPS, a GPU cluster or serverless infrastructure that hibernates when idle [2].

Whatever the framework, “24/7” means the host has to provide six things:

• a process that comes back after a crash and after a reboot;
• state that survives restarts and redeploys: memory, sessions, credentials, configuration;
• a way to receive events: an inbound HTTPS endpoint for webhooks, or outbound polling;
• scheduled work (heartbeats, cron jobs) that runs even when nobody is talking to the agent;
• logs and alerts, so you notice when it stops;
• a spending cap on the model API, because an always-on agent spends money while you sleep.

The deciding question is where the model runs. If the agent calls a hosted model, the host only needs CPU, memory and disk. If it runs its own model, the model’s memory need decides everything else. Hermes Agent, for instance, requires a model with at least 64,000 tokens of context and asks local-model users to set it explicitly, for example --ctx-size 65536 for llama.cpp or -c 65536 for Ollama [3]. A 64K-token context has a real memory cost, which the VRAM guide shows how to estimate.

An API-backed gateway is light. OpenClaw’s DigitalOcean guide runs it on 1 vCPU, 1 GB of RAM and a 25 GB SSD, recommends adding swap on 1 GB machines, prefers hosted models because “local LLM inference does not fit in 1 GB”, and suggests moving to 2 GB if you still run out of memory [4]. Browser automation, code-execution sandboxes and local embedding models all raise that floor, so watch the memory peak for a few days before you downsize.

Follow the framework’s own install guide for your host where one exists. OpenClaw’s documentation links step-by-step guides for 14 hosting targets, including DigitalOcean, Fly.io and Hetzner [5].

The cheapest verified plan per provider that clears a 2 GB floor:

Budget for the renewal price, not the first term

Some VPS hosts advertise a lower introductory price for a long first term, and an always-on agent keeps running long after it ends. Plan with the price the plan renews at. Every introductory price in our dataset, next to its renewal price:

On a VPS: a systemd service

systemd does not restart a service unless you ask it to: the default is Restart=no. The manual calls Restart=on-failure “the recommended choice for long-running services”, and restarts are rate-limited by StartLimitIntervalSec= and StartLimitBurst= [6]. OpenClaw’s installer creates a user service with Restart=always and RestartSec=5 [5].

In Docker: a restart policy

Docker’s default policy is no. With unless-stopped, Docker restarts the container if it exits or when the daemon restarts, but not after you stopped it yourself; a policy only takes effect once the container has been up for at least 10 seconds. Pick one supervisor: Docker warns against combining restart policies with a host-level process manager such as systemd [7].

On Fly.io: switch off autostop for background agents

Apps created with fly launch default to auto_stop_machines = "stop" with min_machines_running = 0, so the proxy stops Machines when no requests arrive. An agent that works on its own schedule needs auto_stop_machines = "off", and Fly.io’s docs pair it with auto_start_machines = false to keep Machines running continuously [8].

Whichever you use, add an external check that alerts you when the agent stops answering or its last scheduled run is too old, and set a monthly budget alert at your model provider.

An agent’s memory, sessions and configuration are the part you cannot rebuild from a container image. OpenClaw keeps its instructions and memory files in a workspace directory and recommends making it a private git repository; session data lives in a SQLite database under ~/.openclaw/agents/ [1]. Its VPS guide is blunt: “Treat the VPS as the source of truth and back up the state + workspace regularly” [5].

Know your platform’s storage model before trusting it. On Fly.io, a Machine’s root file system is ephemeral, a volume is a slice of an NVMe drive on one physical server, Fly recommends at least two volumes per app, and its daily snapshots, kept for 5 days by default, “shouldn’t be your primary backup method” [9].

• Back up off the machine, to object storage or another provider, on a schedule.
• Encrypt backups that contain conversations or credentials.
• Restore a backup to a fresh machine once, before you need to.
• Keep configuration in version control, and secrets outside it.

A connected agent can act. Depending on its tool policy it “can run commands, work with files in its workspace, and message people on your behalf” [1]. OWASP’s Top 10 for LLM applications lists prompt injection (LLM01), excessive agency (LLM06) and unbounded consumption (LLM10) among the main risks [10], and an always-on agent is exposed to all three.

• Keep admin interfaces private. OpenClaw’s secure default keeps the gateway on loopback and reaches it through an SSH tunnel or Tailscale [5].
• Allow-list who can talk to it. OpenClaw asks you to always set allowFrom for WhatsApp and to use a dedicated number for the assistant [1].
• Sandbox tool execution. Hermes Agent recommends running its terminal in a Docker container or on a remote server [3].
• Keep secrets out of the workspace. Hermes stores secrets in ~/.hermes/.env, separate from its configuration file [3]; on managed platforms, use the platform’s secret store.
• Limit the blast radius. Give API keys the narrowest scope, set spending limits at the model provider, keep SSH on keys only and apply security updates.

1. Decide where the model runs: a hosted API (CPU server) or your own model (GPU). The Agent Hosting Selector walks through the choice.
2. Pick a region by where your data may live and where your users and channels are.
3. Provision at least 2 GB of RAM for an API-backed agent, with swap and SSD storage.
4. Install it as a service with a restart policy, then reboot once to prove it comes back.
5. Put state on persistent storage, schedule off-machine backups and test a restore.
6. Close the admin port, allow-list senders, sandbox tools and move secrets into a secret store.
7. Add uptime checks, log retention and model-spend alerts.

Providers with documented support for OpenClaw and Hermes Agent are compared on OpenClaw hosting and Hermes Agent hosting.