OpenClaw Gateway Linux VPS 2026 | GitLab CI/CD vs. SSH-Handupdate

Wenn ein OpenClaw-Gateway auf einem schlanken Linux-VPS läuft, ist der Deploy-Pfad keine Modefrage, sondern Betriebspsychologie: GitLab CI/CD schiebt jedes Release als Job über Runner und SSH (oder Container-Registry-Pull) auf den Host — oder Sie aktualisieren per git pull, docker compose pull und up -d von Hand. Beides kann stabil sein; der Unterschied liegt in wer deployt, welche Secrets wo liegen und ob zwei Pipelines gleichzeitig denselben Port anfassen. Diese Notiz fasst die Entscheidung in einer Matrix zusammen, nennt typische GitLab-Fallen und verweist auf Grundlagen zu Installation und Upstreams.

Release-Stile

Gateway pro VPS (Referenz)

FAQ-Kernfragen

Einordnung: dasselbe Artefakt, andere Verantwortlichkeit

GitLab verschiebt den „Knopf zum Livegang" in Merge Requests, geschützte Branches und .gitlab-ci.yml: Deploy-Jobs laufen nach Review oder Tag, schreiben Logs in die Pipeline-Historie und können Approvals nutzen. Reines SSH-Handupdate hält die Wahrheit auf dem Server in compose.yaml, lokalen .env-Dateien und Ihrem Kopf — schnell zu bootstrapen, aber leichter driftet Konfiguration auseinander, wenn mehr als eine Person Root-Zugang hat. Für die Basis des Gateways (curl vs. Docker, erste Checks) lohnt ein Blick auf 2026 OpenClaw Linux-Cloud-VPS in der Praxis: curl-Installation vs. Docker, Umgebungschecks und FAQ zu typischen Fehlern.

Entscheidungsmatrix

Kriterium	GitLab CI/CD	Reines SSH-Handupdate
Team & Frequenz	Mehrere Maintainer, häufige Releases — klare Pipeline-Logs	Solo oder kleines Ops-Team, seltene Änderungen
Audit & Rollback	Job-Artefakte, Tags, reproduzierbare Schritte	Shell-Historie, manuelle Notizen — schnell, aber dünn belegbar
Secrets	CI/CD-Variablen, geschützte Umgebungen, Masking — Rotation zentral	`.env` auf dem Host, ggf. SOPS — weniger SaaS-Abhängigkeit
Fehlerdiagnose	Runner-Logs + VPS-Logs; Abhängigkeit von GitLab.com/SME	Direkt auf dem Host; kein Zwischen-Orchestrator
Bootstrap-Aufwand	Höher (Runner, Deploy-Keys, YAML-Disziplin)	Niedriger (einmal Compose, dann iterativ)

Hybrid ist üblich

Viele Teams beginnen mit SSH und führen erst bei zweitem Maintainer oder öffentlichen Webhooks GitLab-Deploy-Jobs ein. Entscheidend ist eine feste Reihenfolge (Volumes, Ports, Healthcheck) — nicht das Label auf dem Werkzeug.

Wann GitLab CI/CD die ruhigere Wahl ist

Wenn mehrere Personen deployen dürfen, wenn Sie main schützen und Releases nur über Tags auslösen, lohnt sich die Investition: Deploy-Identitäten lassen sich auf git pull und docker compose im Zielverzeichnis begrenzen, und fehlgeschlagene Jobs blockieren nicht still den nächsten Push. Kombinieren Sie das mit Registry-Images (Digest pinnen), dann bleibt der VPS dünn und Rollbacks sind ein Wechsel des Image-Tags. Upstream-Themen (Ollama, TLS, NO_PROXY) ordnen wir separat ein — siehe 2026 OpenClaw Linux-Cloud-VPS mit LAN- oder lokalem Ollama: Gateway-Upstream, TLS-Trennung, SSH-Tunnel und NO_PROXY-Matrix.

Wann SSH ohne Pipeline pragmatisch bleibt

Einzelpersonen-Setups, interne Bots mit wenigen Releases pro Quartal oder stark segmentierte Netze ohne SaaS-Orchestrierung profitieren von weniger Moving Parts: Sie sehen Kernel-, Docker- und Compose-Fehler sofort im Terminal. Auch wenn GitLab nur Self-Managed hinter VPN erreichbar ist und Runner-Betrieb teurer wird als ein dokumentiertes Runbook, kann Handarbeit die geringere Gesamtkomplexität haben — vorausgesetzt, Sie versionieren compose.yaml und sichern .env getrennt.

Pipeline-Fallen (GitLab-spezifisch)

Runner-Blindflug: Shell-Runner auf demselben VPS wie das Gateway erhöhen den Blast-Radius — besser dedizierter Runner oder Remote-SSH mit eingeschränktem command=. Doppel-Deploys: Zwei Merge-Requests können parallel laufen; ohne File-Lock oder resource_group im Job riskieren Sie halb aktualisierte Container. Variablen-Lecks: Unmaskierte Tokens in Debug-Logs oder set -x in Skripten sind klassische Fehler — nutzen Sie geschützte Umgebungen pro Stage. Branch-Schutz: Wenn nur main deployen darf, aber der Job auf Feature-Branches getestet wird, entsteht Drift zwischen „grün in CI" und „grün in Prod".

Secrets & SSH-Keys

Deploy-Keys sollten nur Pull oder eingeschränktes Push erlauben; CI-Variablen niemals in öffentlichen Forks vererben. Für TLS und kontrolliertes Rollback gehören Zertifikats-Renews in dasselbe Runbook wie Gateway-Upgrades — siehe OpenClaw-Gateway in Produktion auf Linux: HTTPS-Onboarding, Rollback und Night-time Playbook.

Minimal-Skizze: Deploy-Job (nur Muster)

deploy:
  stage: deploy
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'
  script:
    - ssh deploy@"$VPS_HOST" 'cd /srv/openclaw && git pull && docker compose pull && docker compose up -d'
    - ssh deploy@"$VPS_HOST" 'curl -fsS http://127.0.0.1:PORT/health'

Wartungsfenster

Kurze Unterbrüche beim Image-Wechsel sind normal — planen Sie Healthchecks und ggf. docker compose-Profiles, damit Kanal-Webhooks nicht in 502-Fallbacks laufen, während der neue Prozess startet.

FAQ

Brauche ich GitLab Runner auf dem VPS?

Nicht zwingend. Viele Teams nutzen einen getrennten Runner, der per SSH deployt — so bleibt der Gateway-Host schlanker und der Runner kann isoliert gepatcht werden.

Wie verhindere ich parallele Deploys?

In GitLab 15+ helfen resource_group im Job oder externe Locks (z. B. flock auf dem Server), damit nicht zwei Pipelines dieselbe Compose-Instanz anfassen.

Was ist mit GitLab.com-Ausfällen?

Bei Hand-SSH deployen Sie weiter; bei CI brauchen Sie einen Plan B (lokales Runbook, gespiegelter Runner). Dokumentieren Sie beides.

Soll ich `CI_JOB_TOKEN` für Registry-Pull nutzen?

Möglich, aber Scope und Ablauf prüfen — für langlebige Produktions-Pulls sind Deploy-Tokens mit minimalem Scope oft auditierbarer.

Wie rolle ich zurück?

Image-Digest oder Git-Tag des letzten funktionierenden Stands pinnen; Volumes nur anfassen, wenn Schema-Kompatibilität dokumentiert ist.

Wo dokumentiere ich Upstreams wie Ollama?

Getrennt vom Deploy: Upstream-URL, TLS und Proxy-Ausnahmen in einer Matrix pflegen — siehe verlinkten Ollama-Artikel oben.