OpenClaw Gateway VPS Linux 2026 | GitHub Actions vs Docker manuel

Faire tourner OpenClaw comme Gateway sur un VPS Linux tient autant à la surface réseau (TLS, webhooks, callbacks) qu’à la façon dont vous promouvez une nouvelle image ou un nouveau paquet : soit vous industrialisez avec une CI comme GitHub Actions, soit vous gardez la main avec Docker et un runbook SSH. Les deux approches peuvent être saines ; la mauvaise nouvelle, c’est qu’elles n’exigent pas les mêmes compétences ni le même budget « temps d’astreinte ». Pour aligner les jetons côté forge et les déclencheurs distants, la boucle webhooks décrite dans 2026 — Git auto-hébergé (Gitea/Forgejo) sur VPS léger, exécution iOS sur Mac cloud à la journée : webhooks, jetons minimaux et matrice des pools entreprise (FAQ) reste un bon repère, même si votre dépôt vit sur GitHub.

Traçabilité PR → déploiement

SSH

Boucle manuelle maîtrisable

TLS

Terminaison au bord du VPS

Matrice de décision rapide (2026)

En pratique, la question n’est pas « Actions ou Docker », mais « qui porte le risque quand un tag casse la passerelle un vendredi soir ». Le tableau suivant résume les compromis que nous observons sur des petits VPS à fort enjeu opérationnel.

Critère	GitHub Actions (CI/CD)	Docker manuel + SSH
Preuve & audit	Workflow versionné, journaux centralisés par run	Dépend des notes runbook et de l’historique shell
Latence de mise en prod	Minutes après merge si gates courts	Immédiat si vous êtes déjà connecté
Surface des secrets	Secrets Actions + déploiement distant à durcir	Clés SSH sur poste et VPS ; rotation artisanale
Complexité initiale	YAML, environnements, jetons GitHub	Compose ou docker run, pare-feu, systemd

Règle simple

Choisissez GitHub Actions lorsque plusieurs personnes poussent souvent des changements ; gardez le déploiement manuel si vous êtes seul, que vous changez rarement d’image et que vous savez déjà journaliser vos commandes.

Pour structurer l’isolation réseau, l’egress et la gestion des secrets lorsque la CI déclenche des jobs sensibles vers un VPS, voir aussi 2026 — essais d’outillage IA à court cycle et rafales batch : Mac cloud quotidien vs VPS léger — matrice isolation, egress et secrets (FAQ) : la logique « budget de confiance » est la même pour une passerelle exposée.

Étapes reproductibles — déploiement Docker manuel

Cette voie privilégie la prévisibilité : vous touchez le serveur, vous validez le digest d’image, vous redémarrez proprement.

1. Figez un tag d’image et notez son digest ; évitez :latest en production.
2. Sauvegardez le répertoire de données ou le volume nommé OpenClaw avant remplacement.
3. Appliquez la nouvelle image avec la même carte de ports et variables d’environnement.
4. Vérifiez le healthcheck local (curl loopback) puis la terminaison TLS (Nginx/Caddy).
5. Documentez la commande exacte et l’horodatage dans votre ticket interne.

Étapes reproductibles — GitHub Actions (schéma)

Le principe : build ou promotion d’artefact sur GitHub, puis étape distante sur le VPS via SSH ou runner auto-hébergé. Gardez les secrets dans GitHub, limitez les permissions du compte machine et séparez « staging » et « prod » par environnements.

Workflow minimal (illustration)

# .github/workflows/deploy-gateway.yml — squelette
on:
  push:
    branches: [main]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Pull & restart on VPS
        run: |
          ssh deploy@${{ secrets.VPS_HOST }} \
            'docker compose pull && docker compose up -d'

Attention

Une clé SSH déposée dans GitHub Actions agrège le risque : préférez un utilisateur dédié, des commandes sudo NOPASSWD minimales et une IP allowlist sur le VPS lorsque c’est possible.

FAQ

Faut-il obligatoirement passer par Docker ?

Non : certaines équipes installent via paquets ou binaire et supervisent avec systemd. Docker facilite le rollback par tag ; sans conteneur, gardez deux répertoires versionnés et un lien symbolique « courant ».

GitHub Actions remplace-t-il un inventaire d’actifs ?

Non. Les workflows simplifient le déploiement mais pas la cartographie des ports ouverts, des certificats ni des dépendances transitives. Maintenez une liste vivante des endpoints exposés.

Comment tester sans casser la prod ?

Dupliquez le compose sur un second port ou un sous-domaine ; réutilisez les mêmes variables mais des jetons limités. Promouvez ensuite la configuration validée vers le hostname public.

Que journaliser en premier en incident ?

Version d’image, digest, variables sensibles masquées, extrait des journaux gateway et état du reverse proxy. Ces quatre éléments suffisent souvent à distinguer régression applicative et problème TLS.