2026 OpenClaw on Fly.io vs a plain Linux cloud VPS: persistence, public ingress, channel webhooks, and health checks (matrix + FAQ)

OpenClaw needs a stable process, durable state for sessions and tokens, and a single HTTPS URL that chat providers can reach for webhooks. In 2026 the two most common footprints are a Fly.io machine with attached volumes and managed TLS, or a generic Linux VPS with systemd, a reverse proxy, and a bind-mounted data directory. This note compares them on the dimensions that actually break production: where state lives, how the public URL behaves under deploys, how Slack or Telegram retries interact with your gateway, and how health checks should be wired so restarts do not wipe paired channels.

Decision matrix at a glance

Use Fly when you want the platform to own rolling deploys, anycast routing, and certificate renewal with minimal Ansible. Use a VPS when you need fixed egress IPs, arbitrary kernel modules, side-by-side agents on the same host, or a compliance boundary you control end to end. For minimal public exposure patterns (loopback gateway plus SSH or split-horizon HTTPS), see OpenClaw Linux minimal attack surface: firewall and ingress matrix.

Persistence: volumes versus bind mounts

On Fly, declare a volume in the same region as the machine and mount it to the path your container entrypoint uses for credentials, channel metadata, and local caches. Scale-out with multiple machines without shared storage will fork state; for OpenClaw you almost always want one writer instance until the project documents explicit multi-node semantics. On a VPS, prefer a single bind-mounted directory owned by a non-root service user, with filesystem backups that are crash consistent enough for SQLite-style stores.

If you are still choosing how to install the runtime, curl install versus Docker on a Linux cloud VPS walks through environment checks that apply before you even expose port 443.

Ingress, webhooks, and replay pressure

Channel vendors deliver events with retries and tight latency budgets. Your gateway must return quickly, verify signatures at the edge when possible, and enqueue work instead of doing heavy model calls inline. Under Fly, confirm that internal HTTP timeouts are shorter than the vendor’s client timeout so you do not accumulate duplicate deliveries that look like replay bugs. Under Nginx or Caddy, log the upstream status separately from TLS handshake failures so a certificate renewal issue is not misread as an application 500.

Health checks that survive rollouts

Expose a cheap GET endpoint that exercises configuration parsing and disk writability on the volume mount, not live calls to third-party APIs on every probe. Pair that with a synthetic “can enqueue work” check in your observability stack. On Fly, tune check intervals so transient CPU steal during neighbor activity does not replace healthy machines. On systemd, prefer Type=notify only if your binary supports sd_notify; otherwise rely on exit codes and backoff limits instead of aggressive restart storms.

Log shipping deserves the same discipline as the probe itself: if you scrape only stdout from a container, make sure file-based logs written under the state directory are also rotated or forwarded, otherwise a full disk will pass a shallow health check until the process finally blocks on write. For dual-stack hosts, confirm whether your health client uses IPv4 or IPv6 by default so you are not green on loopback while the public AAAA record points at a dead listener.

1. curl -v https://your-host/healthz   # TLS + routing
2. ls -la $OPENCLAW_STATE_DIR        # volume mounted?
3. journalctl -u openclaw -b         # or fly logs --app …
4. diff webhook secret vs provider UI # silent 401/403 loops

FAQ: reproducible failures

Q: Slack marks the Events URL bad after each deploy. Start the listener before switching traffic; keep the request path identical between preview and production; confirm the signing secret in the provider UI matches the runtime environment.

Q: Sessions vanished overnight. Almost always an unmounted volume or a container that wrote state into the image layer. Verify the mount inside the running task, not only in the Dockerfile.

Q: Health check green but users see timeouts. Your probe probably hits localhost while webhooks hit a saturated TLS front. Add a second synthetic check from outside the VPC or use an external monitor.

Q: Fly shows multiple machines after a scale bump. Unless you have designed for leader election, scale horizontally only after shared storage or a single-writer queue is in place; otherwise duplicate webhooks will race the same downstream automations.