What "Always-On" Actually Requires From a Host

People buy a VPS, install an agent, watch it answer a test message, and conclude the hard part is done. The hard part has not started. What they have built is an agent that is online while they are logged in — and the evening they close the laptop is the first honest test.

The gap between “runs” and “stays running” is not a matter of degree. It is three specific configuration facts, and all three are written down by the projects themselves, usually in a troubleshooting subsection where nobody looks until something has already stopped.

The provider list is longer than the requirement list

OpenClaw’s documentation includes dedicated install pages for Azure, Daytona, DigitalOcean, exe.dev, Fly.io, GCP, Hetzner, Hostinger, Northflank, Oracle Cloud, Railway, Render, Raspberry Pi and Upstash — fourteen targets, from a $6 Droplet to Kubernetes. Hermes describes its own range the same way, from a cheap VPS to serverless.

That breadth is the answer to a question people ask in the wrong form. There is no special class of machine that agents require; there is a long tail of ordinary compute, and the documentation tells you the floor for each. What differs between them is not compatibility but what keeps the process alive when nobody is watching, and that is where the interesting failures live.

Fact one: a user service dies when your last session ends

This is the one that catches Linux users, because the service genuinely works right up until it does not.

openclaw onboard --install-daemon installs a systemd user unit, not a system unit. User units belong to a user manager, and the user manager, by default, exists while that user has a session. Log out, and it goes away — taking the service with it.

systemd’s own manual describes the fix and, in doing so, describes the problem precisely:

“Enable/disable user lingering for one or more users. If enabled for a specific user, a user manager is spawned for the user at boot and kept around after logouts. This allows users who are not logged in to run long-running services.”

Two things are happening in that sentence, and both matter. Lingering spawns the manager at boot — so it survives a reboot, not just a logout. And it keeps the manager around after logouts, which is the state a headless server is in permanently.

OpenClaw’s Raspberry Pi page states the operational consequence in one line: “On a headless Pi, also enable lingering once so the user service survives logout.” Its DigitalOcean walkthrough does it in the setup block, before onboarding, as loginctl enable-linger openclaw — run as root, for the non-root user that will own the service. The ordering is deliberate: if you create the user and immediately start the service as that user without lingering, the service is on borrowed time.

Check it with:

loginctl show-user "$(whoami)" -p Linger

If that returns Linger=no, you have an agent that will stop the next time your SSH session ends for the right reason.

Fact two: the restart policy is owned by the unit, and it is already set

The second fact is the reassuring one. Once lingering is on, a crash does not require your attention, because the managed unit already declares what to do. OpenClaw’s Linux server page states it as a property of the unit rather than a suggestion:

“The managed unit owns the generic restart policy: Restart=always, RestartSec=5.”

Restart=always means the process comes back after a clean exit as well as a crash — the difference matters, because plenty of failures end with a zero exit code after an unhandled condition. Five seconds is short enough that a chat message sent during a restart usually finds the service back.

The page also warns against the natural next move, which is editing that unit. Customisations should go in a drop-in via systemctl --user edit openclaw-gateway.service, keeping host-specific settings — a longer TimeoutStartSec on a slow box, an environment variable for the compile cache — separate from the managed definition. If you edit the unit itself, an upgrade can overwrite your change and you will not get an error when it happens.

Fact three: inside a container, a different supervisor is in charge

If you run the agent in Docker, none of the above is your supervision layer, and assuming it is causes a specific and confusing failure: systemctl inside the container does nothing, because there is no systemd there.

Hermes describes its own arrangement plainly:

“Inside the official Docker image, gateway run is automatically supervised by s6-overlay: if the gateway process crashes it’s restarted within a couple of seconds without losing the container, and the dashboard (when HERMES_DASHBOARD=1 is set) is supervised alongside it.”

So the container has an internal supervisor, and Docker has an external one. The internal one handles the agent process; the external one handles the container, and it only acts if you tell it to. That is what --restart unless-stopped is for in the documented docker run line, and the phrase “unless-stopped” is doing real work: it restarts after a daemon restart and after a host reboot, but respects a deliberate stop.

Two layers, two jobs. A container with the right restart policy but no internal supervisor loses the dashboard when the gateway restarts. A container with the internal supervisor but no restart policy loses everything when the host reboots.

The five-minute test that settles it

Reading the docs tells you what should happen. Only two actions tell you what does. Run them before you trust the thing with anything that matters.

Reboot the machine. Then, without logging in, check from outside:

ssh user@host 'systemctl --user is-active openclaw-gateway.service'

If this returns inactive or the SSH session reports no user manager, lingering is off or the unit was installed under a different user than the one you are checking.

Log out completely, wait a minute, and check again. loginctl terminate-user reproduces the end state faster than closing a terminal, and it is the honest test: it is exactly the event lingering is meant to survive. If the service dies here, the common cause is that linger was set for the wrong account — enabled as root for root, say, while the unit was installed under a different user. Lingering is a per-user property, so it has to be set for the user that owns the unit.

Then confirm it is actually serving, not merely running:

systemctl --user status openclaw-gateway.service
journalctl --user -u openclaw-gateway.service -n 50 --no-pager

status tells you the process exists. The journal tells you whether it has been failing and restarting every five seconds since the reboot — which is-active reports as active between attempts, and which is the most common way an “always-on” agent turns out to be a restart loop.

What “always-on” still does not promise

Three things, and they are worth naming because the phrase invites over-reading.

A reboot is not the only way to lose the process. Out-of-memory kills end with exit code 137, and a restart policy will faithfully restart a process that is going to be killed again. If the journal shows a repeating cycle, the machine is undersized, not misconfigured — the memory arithmetic is worth doing before you add another gigabyte.

Free tiers enforce their own uptime. An “always free” instance that is reclaimed for being idle is not always-on, no matter how well your unit file is written; the rules apply to the provider’s view of the machine, not yours. The exclusions are documented and they are specific.

Uptime is not availability. A $5 VPS has no SLA. The realistic posture is a heartbeat that messages you when the agent stops answering, so you learn about it before a client does. OpenClaw’s documentation treats periodic checks as an ordinary automation job rather than an advanced feature, which is the right framing: monitoring an agent is a scheduled task the agent can run for itself, as long as it is running.

The checklist, in the order that works

1. Create the non-root user that will own the agent’s state.
2. Enable lingering for that user, as root, before installing the service.
3. Install the daemon as that user, so the unit lands in the right user manager.
4. If containerised, set --restart unless-stopped on the container and rely on the image’s internal supervisor for the process.
5. Reboot. Check from outside without logging in. Log out. Check again.
6. Read the journal, not just the status, and confirm there is no restart loop.

None of these steps is difficult, and none of them is about the provider. That is the point worth keeping: “always-on” is a property of your configuration, not of the plan you bought. The plan decided the floor; the six lines above decide whether the thing is actually there at three in the morning.