2026 — OpenClaw Gateway sur hébergement cloud Linux : GitLab CI/CD automatique ou mise à jour pure par SSH

Sur un VPS Linux dédié à OpenClaw Gateway, la question « qui pousse en production ? » se tranche souvent entre un pipeline GitLab CI/CD et une session SSH où l'on enchaîne à la main git pull, rebuilds et redémarrages systemd. L'automatisation promet une traçabilité continue ; le SSH pur reste tentant lorsque l'équipe est minuscule ou que le fournisseur impose déjà son propre panneau d'orchestration. En 2026, le bon choix dépend moins du prestige de la plateforme Git que du risque opérationnel accepté : fenêtre d'indisponibilité, audits et surface des secrets.

Avant d'écrire la première ligne du .gitlab-ci.yml, listez les acteurs : compte machine sur le VPS, clé de déploiement en lecture seule sur le dépôt Gateway, jeton vers un registre d'images. Avec OIDC, GitLab peut émettre un court jeton signé échangé contre des rôles du cloud qui héberge le registre — évitez de stocker un mot de passe root du VPS dans une variable masquée si une identité fédérée suffit. Sur un hébergeur modeste, une paire clé SSH dédiée au pipeline reste courante, avec authorized_keys restreinte à une commande forcée ; planifiez la rotation dès le premier jour.

Matrice de décision rapide

GitLab excelle lorsque plusieurs personnes déploient, que la Gateway vit derrière un reverse proxy versionné et que vous devez rejouer exactement la même release sur deux régions. Le SSH seul reste défendable pour un prototype isolé ou lorsqu'un bastion déjà durci constitue votre seule interface — à condition de formaliser tout de même un mini journal de commandes et une checklist de santé post-déploiement. Pour une comparaison voisine autour de GitHub Actions et de conteneurs, voir aussi notre guide OpenClaw Gateway : GitHub Actions face au Docker manuel.

Ce qui casse vraiment dans un pipeline GitLab

La première classe d'erreurs concerne systemd : votre job pousse un binaire ou un compose mais oublie systemctl daemon-reload après modification d'une unité, ou deux workers redémarrés en parallèle se disputent le même socket. La seconde classe vient des runners partagés : un cache Docker mal isolé peut réintroduire une dépendance fantôme absente du VPS cible. Verrouillez un runner par environnement ou publiez une image OCI figée dans un registre privé, puis déployez uniquement le digest. Séparez explicitement « build » et « apply » : compiler lourdement sur le serveur de production allonge la fenêtre où HTTPS est exposé sans processus prêt à servir les webhooks.

Les merge trains et pipelines parallèles peuvent envoyer deux commits valides sur le même hôte dans le désordre. Utilisez un resource_group ou un verrou d'environnement GitLab pour sérialiser les écritures ; sinon le dernier docker compose up « gagne » sans laisser une trace claire pour l'astreinte.

stages: [build, deploy]

build-gateway:
  stage: build
  script:
    - docker build -t registry.internal/openclaw:$CI_COMMIT_SHA .
  only:
    - main

deploy-prod:
  stage: deploy
  when: manual
  environment: { name: production }
  script:
    - scp compose.yml $DEPLOY_HOST:/srv/openclaw/
    - ssh $DEPLOY_HOST "cd /srv/openclaw && docker compose pull && docker compose up -d"

SSH : discipline minimale pour rester sûr

Même sans GitLab, imposez un bastion unique, des clés éphémères et une liste de commandes autorisées ; documentez la séquence exacte pour mettre à jour la Gateway et redémarrer le service utilisateur. Limitez l'accès direct aux ports d'administration : notre article surface d'exposition minimale (pare-feu, loopback, SSH) explique pourquoi la Gateway doit souvent rester en loopback derrière nginx ou Caddy. Sans pipeline, programmez tout de même des vérifications post-update : endpoint de santé, rotation des journaux et test d'un webhook entrant représentatif.

FAQ — questions qu'on pose à 22 h

• Le pipeline passe mais la Gateway ne répond pas — inspectez les variables injectées par GitLab : un espace en fin de ligne suffit à invalider un jeton TLS ou un chemin de fichier.
• Double déploiement concurrent — sérialisez avec resource_group ou verrou d'environnement pour éviter deux docker compose qui se marchent dessus.
• Migrations de schéma — exécutez-les avant de basculer le trafic ; gardez une étape manuelle si elles ne sont pas idempotentes.

GitLab CI/CD amortit vite le coût de la discipline lorsque l'équipe grandit ou lorsqu'il faut prouver qui a déployé quoi ; le SSH pur reste acceptable uniquement si vous compensez par des runbooks verrouillés et une surface réseau réduite. Choisissez d'abord la granularité de rollback et la visibilité dont vous avez besoin pour dormir, puis adaptez la complexité du YAML.