Après les guides d’installation trois plateformes et Docker en production, vous pouvez encore vouloir OpenClaw Gateway en Node sur hôte nu + systemd sur Ubuntu 24.04, avec Cloudflare Tunnel pour que la passerelle n’écoute pas sur l’interface publique. Cet article propose le périmètre par rapport à Docker, une décomposition des points de friction, deux tableaux, des extraits systemd et tunnel, un runbook en six étapes et trois indicateurs d’astreinte, avec des liens vers le triage post-installation, la production Docker, le guide d’installation et la sécurité avancée du Gateway pour une mise en production reproductible.
Le hôte nu remet versions Node, droits, adresses de liaison et supervision des processus sur la machine. Si vous gardez l’habitude « Gateway au premier plan sur un portable », les redémarrages coupent les services, les journaux manquent de structure, et la dérive entre ufw et les groupes de sécurité cloud rend les incidents anecdotiques. Décomposez ces six familles avant de copier des configurations.
sudo npm i -g répétés désynchronisent la prod par rapport à la doc ; figez ExecStart sur un binaire Node fixe ou un shim de gestionnaire de versions.0.0.0.0 plus une règle pare-feu oubliée expose le plan de contrôle ; avec des tunnels, préférez 127.0.0.1 et laissez le tunnel accepter l’entrant.openclaw donne « ça marche à la main, ça casse en service ».cloudflared pointant vers le mauvais port local produit un 502 externe sans lien avec les timeouts modèle.ExecStart connu bon et l’empreinte de config bloque un rollback rapide.Deux tableaux condensent Docker vs hôte nu et tunnel vs reverse proxy direct pour les dossiers de revue.
L’article avancé sur la sécurité du Gateway couvre jetons, exposition et rotation des secrets ; celui-ci couvre la liaison loopback sur Linux et le déléguage de l’ingress au tunnel. Ensemble ils forment « ingress en périphérie, secrets dans le plan dépôt, processus sous systemd ». Complétez l’onboarding et les clés modèle via le guide d’installation avant le durcissement prod décrit ici.
L’article production Docker traite des images figées, volumes et rollback Compose ; celui-ci couvre unités hôte + tunnel. Le tableau 1 sert à la revue d’architecture—ce n’est pas un choix dogmatique.
| Dimension | Docker / Compose | Node nu + systemd (cet article) |
|---|---|---|
| Reproductibilité | Images et digests figent l’exécution | La pile hôte varie ; compensez avec gestion de config et versions figées |
| Profondeur de triage | Journaux conteneur et droits volumes d’abord | Outils niveau hôte disponibles si la politique le permet |
| Outils d’exploitation existants | Monitoring conteneurs et flux registre | Réutiliser journald, node_exporter, scripts de sauvegarde |
| Chemin de mise à jour | Changer les tags d’image ; volumes explicites | Node et paquets globaux bougent ensemble—scripter le retour arrière |
| Adéquation typique | Équipes déjà standardisées sur conteneurs | Obligation de tourner sur métal ou couplage fort à des services systemd hérités |
Les tunnels déchargent TLS et l’ingress public vers le bord ; Nginx/Caddy terminent souvent TLS en local et proxifient vers la boucle. Vous pouvez les combiner, mais les surfaces d’écoute doivent rester minimales. Croisez le tableau 2 avec les règles des groupes de sécurité.
| Modèle | Liaison Gateway | Surface publique | Notes d’exploitation |
|---|---|---|---|
| Tunnel vers loopback | 127.0.0.1:PORT (selon la doc OpenClaw) | Pas de port Gateway direct ; processus tunnel en sortie uniquement | Aligner l’ingress sur le port local du service réellement actif |
| Nginx/Caddy local | Souvent toujours amont loopback | 443 sur le proxy ; gérer certificats et limitation de débit | Vérifier trois fois ufw et SG cloud pour éviter une double exposition |
| Déconseillé : Gateway sur 0.0.0.0 | Toutes les interfaces | Plan de contrôle sur Internet | Exige jetons stricts, listes d’autorisation et WAF—pas le défaut |
# /etc/systemd/system/openclaw-gateway.service (squelette ; ExecStart selon la CLI officielle) [Unit] Description=OpenClaw Gateway (hôte nu) After=network-online.target Wants=network-online.target [Service] User=openclaw Group=openclaw WorkingDirectory=/var/lib/openclaw Environment=NODE_ENV=production ExecStart=/usr/bin/node /path/to/openclaw/cli.js gateway start --bind 127.0.0.1 Restart=on-failure RestartSec=5 LimitNOFILE=65535 [Install] WantedBy=multi-user.target
# Fragment cloudflared : hostname vers Gateway local
tunnel: YOUR_TUNNEL_ID
credentials-file: /etc/cloudflared/YOUR_TUNNEL.json
ingress:
- hostname: claw.example.com
service: http://127.0.0.1:18789
- service: http_status:404
Remarque : les ports et chemins binaires sont des exemples. Alignez-vous sur la doc OpenClaw actuelle et openclaw --help ; consignez empreintes et commandes de rollback dans le ticket de changement.
127.0.0.1, curl ou health check selon la doc, puis ajoutez le tunnel.daemon-reload && enable --now ; suivez journalctl -u openclaw-gateway -f pour les erreurs d’ordonnancement.ExecStart et les configs connus bons ; n’avancez en échec que dans votre RTO.Séparez santé locale (processus + port loopback) de santé externe (DNS, chaîne de certificats, routage edge). Ne mettre à jour qu’un des deux lors des releases produit des faux positifs « vert dedans, rouge dehors ». Les gabarits de ticket doivent exiger la version OpenClaw, la mineure Node et la version cloudflared, plus un extrait de journal pour la piste d’audit.
curl -v 127.0.0.1:PORT d’abord, puis journaux tunnel ; échec local = couche appli, succès local / échec distant = tunnel ou DNS.Addendum : sur les petits VPS qui n’exécutent que Gateway et tunnel, si la latence fluctue alors que le CPU semble inactif, vérifiez les descripteurs de fichiers par processus, le nombre de WebSocket longue durée et le RTT TLS vers les fournisseurs avant d’ajouter des vCPU.
Un VPS Linux générique suffit aux démos, mais la variance I/O et les contraintes sans tête façonnent encore l’automatisation longue durée. OpenClaw en production exige une supervision reproductible, des surfaces d’écoute auditables et un alignement avec CI et les flux de secrets.
Pour les builds iOS, le Simulateur ou le triage GUI, Linux ne remplace pas Apple Silicon ; beaucoup d’équipes placent le Gateway sur un bord Linux et délèguent le travail lourd Xcode à des Mac distants. Les portables de rechange et les postes fragmentés peinent en agents 24/7 : veille et invites transforment l’automatisation en échecs aléatoires. MACCOME propose des Mac Mini M4 / M4 Pro bare-metal multi-régions—utiles comme backend de build et de sessions longues pendant que Linux concentre l’ingress. Ouvrez le centre d’aide, puis alignez les tarifs de location avec la page de votre région.
Pilotez avec de courtes locations pour mesurer la latence bout en bout « tunnel + charge Mac distant » avant de colocaliser ingress et compilation sur un même hôte.
FAQ
Docker ne suffit-il pas ?
Souvent oui—voir la production Docker. systemd sur hôte nu convient à une intégration serrée avec l’exploitation existante ou à des besoins de triage au niveau machine.
127.0.0.1 ou 0.0.0.0 pour le Gateway ?
Préférez la boucle locale derrière tunnel ou proxy local ; n’élargissez qu’avec pare-feu, jetons et supervision. Les étapes de validation sont dans le triage post-installation.
Où sont les commandes d’installation et les différences entre plateformes ?
Installation et choix de plateforme ; tarifs sur les tarifs publics et aide sur le centre d’aide.