OpenClaw Gateway on Linux VPS in 2026: GitHub Actions CI/CD vs Manual Docker Deploy — Decision Matrix, Repro Steps, and FAQ

Running OpenClaw Gateway on a small Linux VPS is straightforward until upgrades, TLS, and channel tokens enter the picture. In 2026 the real fork is not “Docker or not” but whether you want repeatable automation (GitHub Actions pushing tagged images and configs) or hands-on control (SSH, compose files, and manual rollbacks). Both paths work; they optimize for different failure modes. For production HTTPS, onboarding wizards, and rollback layering, our companion walkthrough stays the canonical baseline — see 2026 OpenClaw Gateway production on Linux: onboard wizard, doctor --fix, HTTPS reverse proxy, upgrade and rollback.

Decision matrix: when Actions wins, when SSH wins

Use the table as a checklist — “green” does not mean mandatory, it means lower regret if that concern shows up in incidents.

Repro steps (GitHub Actions → Linux VPS)

Outline only — swap registry and paths for your environment. Goal: immutable artifact plus explicit version pin.

1. Build — workflow builds/pushes an image (tag + digest) to your registry; avoid anonymous latest in production.
2. Secrets — store SSH_PRIVATE_KEY, host fingerprint, and deploy token as GitHub Actions secrets; restrict who can approve deploy jobs.
3. Remote apply — job SSHes to the VPS, pulls the digest you just built, writes a small env file outside Git, and runs docker compose up -d (or your orchestrator).
4. Health gate — curl the Gateway health route through loopback or your reverse proxy; fail the job if TLS or upstream sockets are not ready.
5. Webhook symmetry — if Git-driven automation also triggers native builds elsewhere, mirror the same tagging discipline described in 2026 short-cycle self-hosted Git (Gitea/Forgejo), a light VPS control plane, and per-day cloud Mac for native iOS builds.

# On the VPS after SSH:
export GATEWAY_IMAGE_DIGEST="sha256:…"
docker compose pull
docker compose up -d
curl -fsS http://127.0.0.1:<health-port>/health

Repro steps (manual Docker on the VPS)

Manual deploy trades automation for clarity — ideal when you are learning surfaces (TLS termination, systemd user units, volume mounts).

1. Baseline host — firewall allows 22/443 as needed; install Docker + Compose plugin; create non-root deploy user.
2. Pinned image — pull explicit digest; record it in a local versions.txt you keep beside compose.
3. Persistent paths — mount token/session directories per upstream docs; snapshot volumes before upgrades.
4. Reverse proxy — terminate TLS with nginx or Caddy; keep Gateway on loopback unless you intentionally expose it.
5. Smoke tests — run openclaw doctor (or equivalent) after each bump; capture logs under journalctl --user if using systemd.

FAQ

Does CI/CD replace backups?

No. Automation redeploys artifacts; it does not resurrect corrupted state directories. Schedule filesystem snapshots or rsync-style backups for mounted data.

Which path is cheaper?

GitHub Actions adds metered minutes and artifact storage; manual deploy costs engineer time during incidents. Small fleets often pick manual until deploy frequency rises above weekly.

Can I mix — Actions build, manual apply?

Yes. Push images via CI, SSH manually to promote digest after review. Same audit trail on registry tags without wiring full remote compose automation immediately.