OpenClaw Gateway Linux VPS 2026 | GitHub Actions vs. manuelles Docker-Deploy

Wer ein OpenClaw-Gateway dauerhaft auf einem Linux-VPS betreibt, steht früh vor einer pragmatischen Frage: Änderungen per SSH und docker compose pull plus up -d ausrollen — oder jedes Release über GitHub Actions auf den Server schicken? Beides ist legitim; der Unterschied liegt in Nachvollziehbarkeit, Secret-Handling und wer um drei Uhr nachts den kaputten Deploy erklärt. Diese Notiz ordnet die Varianten ein, liefert eine Entscheidungsmatrix und skizziert reproduzierbare Minimal-Schritte ohne eine konkrete Distribution zu „verkaufen".

Typische Deploy-Pfade

1×

Gateway pro VPS (Referenz)

FAQ-Kernfragen

Einordnung: gleiches Ergebnis, anderer Betriebs-Stil

Manuelles Docker-Deploy bedeutet: Sie halten Compose-Datei, Images und Umgebungsvariablen unter Kontrolle und treffen auf dem Server die relevanten Befehle — spontan oder nach Checkliste. GitHub Actions CI/CD verschiebt dieselben Schritte in einen Workflow: Checkout, optional Build/Push eines Images, SSH oder Remote-Docker, Healthcheck. Der VPS ändert sich physikalisch nicht; ändern sich Betriebskosten, Risiko und Schulungsbedarf.

Entscheidungsmatrix (Kurzfassung)

Kriterium	GitHub Actions	Manuelles Docker-Deploy
Änderungsfrequenz	Ideal bei häufigen, kleinen Releases und mehreren Maintainer:innen	Oft ausreichend bei seltenen Updates und klarem Owner
Audit / Nachweis	Workflow-Runs, Logs, genehmigte Secrets — gut für Teams	SSH-Historie und manuelle Notizen — schwächer, aber einfacher
Secret-Fläche	GH Secrets + Deploy-Keys; Rotation über Org-Prozesse	`.env` auf dem Host, ggf. verschlüsselte Backups — weniger moving parts
Fehler bei Netz/Timing	Retries im Workflow, aber Abhängigkeit von GitHub + VPS-Uplink	Direktes Debugging auf dem Host, kein Zwischen-Orchestrator
Bootstrap-Zeit	Höher (Repo, Runner-Minuten, YAML-Pflege)	Niedriger (einmal Compose, dann iterativ)

Hybrid ist erlaubt

Viele Teams starten manuell und ziehen erst bei zweitem Maintainer oder öffentlichen Webhooks CI nach. Wichtig ist eine dokumentierte Reihenfolge (Volumes, Env, Ports), nicht das Etikett auf dem Werkzeug.

Wann GitHub Actions die sauberere Wahl ist

Wenn mehrere Personen deployen dürfen, wenn Sie Release-Tags oder Branch-Protection als „Einheitliche Wahrheit" nutzen und wenn wiederholbare Logs für Audits oder On-Call wichtig sind, amortisiert sich YAML-Arbeit schnell. Actions eignen sich auch, wenn Images in eine Registry gepusht und vom VPS nur noch gezogen werden — dann bleibt der Server schlank und Rollbacks sind ein Pin auf eine Digest.

Für Apple-seitige CI-Themen (wartende Builds, Runner-Kapazität) lohnt ein Vergleich mit verwalteten Executors vs. dediziertem Cloud-Mac — siehe 2026 Kurzzyklus-iOS-Builds: CircleCI Cloud-macos-Executor vs. Self-hosted Cloud-Mac pro Tag — private Dependencies, Parallelität und Warteschlangen-SLO (Matrix & FAQ).

Wann manuelles Deploy oft schneller bleibt

Einzelpersonen-Projekte, interne Tools mit wenigen Releases pro Quartal oder stark regulierte Umgebungen ohne SaaS-Orchestrierung profitieren von weniger Moving Parts: Sie sehen sofort Kernel-, Docker- und Compose-Fehler im Terminal. Manuelles Vorgehen ist auch dann attraktiv, wenn Sie ohnehin per SSH pflegen und keine zusätzliche Secret-Schicht in GitHub etablieren wollen.

Reproduzierbare Minimal-Schritte

Manuell (Referenzablauf)

Frisches Ubuntu/Debian: Docker + Compose Plugin installieren, unprivilegierten Nutzer in der docker-Gruppe nur wenn nötig.
Projektverzeichnis mit versionierter compose.yaml, daneben .env mit Tokens — niemals ins Git.
docker compose pull && docker compose up -d, danach Healthcheck (HTTP-Port, Prozess, Journal).
Optional systemd-Unit nur als Wrapper — Compose bleibt die Quelle der Wahrheit.

Mit GitHub Actions (Skizze)

Deploy-Key oder SSH-Agent mit eingeschränktem command=, nur für das Deploy-Verzeichnis.
Workflow auf workflow_dispatch oder geschütztem Branch; Secrets für Host, User, Fingerprint.
Schritte: Checkout → optional Build/Push → SSH git pull / Registry Pull → compose up → Smoke-Test mit curl.
Artifact: konsolidiertes Log archivieren oder in einen Nur-Lesen-Kanal spiegeln.

Smoke-Check nach Deploy (Beispiel)

# TLS-Endpunkt oder Loopback je nach Setup
curl -fsS "https://127.0.0.1:PORT/health" --resolve "gateway.example:443:127.0.0.1"

Secrets und öffentliche Kanten

Weder CI noch Compose entschärfen eine falsch geöffnete Firewall. Tokens gehören in Secret Stores oder minimale .env-Dateien mit restriktiven POSIX-Rechten. Für öffentliche Webhooks und dynamischen Egress vergleichen wir Tunnel vs. VPS-Reverse-Proxy in 2026 OpenClaw: Kanal-Webhooks und dynamischer Egress — Cloudflare Tunnel vs. Tailscale Funnel vs. Linux-Cloud-VPS mit öffentlichem Reverse-Proxy (Matrix + FAQ).

FAQ

Brauche ich überhaupt CI für ein Hobby-VPS?

Nicht zwingend. Wenn Sie alleine deployen und Änderungen dokumentieren, reicht eine kurze Runbook-Datei plus monatlicher „Dry-Run" auf einem Staging-Knoten.

Wie rolle ich ohne lange Downtime zurück?

Image auf vorherige Digest pinnen oder Compose-File mit vorherigem Tag auschecken; Volumes nur anfassen, wenn Schema-Kompatibilität explizit dokumentiert ist.

Soll der Runner direkt auf dem VPS Docker steuern?

Möglich, aber erhöht Blast-Radius. Sauberer: Registry-Pull auf dem VPS und strikt getrennte Deploy-Identität mit minimalen Rechten.

Was ist mit Datenpersistenz?

Bind-Mounts oder benannte Volumes vor dem ersten up planen; Backups und Restore-Tests gehören zum gleichen Runbook wie der Deploy selbst.

Wie harmoniert das mit HTTPS-Onboarding?

Zertifikate und Reload-Zyklen sollten im gleichen Runbook wie Gateway-Upgrades stehen — siehe OpenClaw-Gateway in Produktion auf Linux: HTTPS-Onboarding, Rollback und Night-time Playbook für TLS, Reverse-Proxy und kontrolliertes Zurücksetzen.