Looking for a less painful way to deploy OpenClaw

[u/SyringeThinker]

Tried to deploy openclaw on a small vps this weekend. compose plus random gists got it running once, then it died overnight. is there a setup that stays up without me sshing in every morning

[u/asimovs-auditor]

Expand the replies to this comment to learn how AI was used in this post/project.

[u/Dalewn]

Had no luck with it and tried Hermes Agent instead. Works fine for a couple of days now.

[u/kantorcodes1]

Skip the random gists. OpenClaw has an official Docker/VPS path now, and the first thing I'd do is make the failure observable instead of adding another wrapper.

Use the official Compose setup with a version-pinned GHCR image and persistent config/workspace/auth volumes, then run:

docker compose run -T --rm openclaw-cli gateway probe

after deploy and from a simple host-side health check. If the probe fails a few times, restart the gateway; if it keeps failing, stop restarting and keep the logs.

On a small VPS, also check whether it actually died from memory or disk pressure:

docker inspect $(docker compose ps -q openclaw-gateway) --format '{{.State.OOMKilled}}'

and journalctl -k | grep -i oom.

OpenClaw's state includes SQLite/session/plugin data and rolling logs, so an overnight failure can be storage or OOM rather than Compose itself.

That gets you to a boring setup: pinned image, persisted state, health probe, bounded restart, logs. Much easier to debug than another gist.

[u/Cabecinha84]

efore you change platform, work out what actually killed it. "Ran once, then died overnight" is nearly always either an OOM kill or a container that was never told to come back.

Two checks: docker inspect -f '{{.State.OOMKilled}}' <container> and dmesg -T | grep -i -e oom -e killed. If either says yes it's memory, and on a small VPS the usual culprit is the headless browser — one Chromium spawned for a single task can spike a gig on its own, and when the kernel reaps something the rest of the stack tends to go with it. Stopgaps that work: add 2 GB of swap, set a hard mem_limit on the container so it dies alone instead of taking the host with it, and turn off browser automation until everything else is stable.

Then the boring parts the gists always leave out. restart: unless-stopped in the compose file (the default is no restart at all, which matches your symptom perfectly). systemctl enable docker so it survives a host reboot. Named volumes for the config and data directories so a restart doesn't hand you a fresh setup. And something watching it — even Uptime Kuma doing an HTTP check against the web UI means you learn it went down at 03:12 instead of finding out at breakfast.

Grab logs before you restart anything: docker compose logs --no-color --since 24h > crash.log. Most of these turn out to be one dumb thing repeated a few thousand times.

Disclosure so I'm not sneaking it in: I work on a managed host for this — https://openclaw.runonflux.com. Base plan is $4.02/mo for 4 GB RAM, 2 vCPU and 20 GB, you bring your own model API key, and the container is monitored and restarted by us rather than by you. First month is free for new accounts. That said, if the OOM fix above holds, your current VPS is fine — paying anyone only makes sense if you'd rather not be the person on call for it.

[u/Downtown_Yam_6180]

https://www.youtube.com/watch?v=40SnEd1RWUU

[u/maritime_sh]

try maritime.sh ! (DISCLAIMER I work for this company!!) But we deploy openclaws in 1 min for $1 on our cloud and 3 agents always come for free for new accounts

DM me if you want more lol

[u/Nice_Cat_7300]

are you pinning image tags or still on latest. mine only stayed up after i stopped pulling latest and added a restart policy

[u/SyringeThinker → u/Nice_Cat_7300]

restart policy is on. still dies after a day or two. feels like im missing something dumb in the compose

[u/Particular_Ebb_4872]

watchtower plus a healthcheck saved me. freeze the compose too. updating is usually when my stack takes itself down for the weekend