Przejdź do głównej treści
Uruchom OpenClaw Gateway na dowolnym serwerze Linux lub VPS w chmurze. Ta strona pomaga wybrać dostawcę, wyjaśnia, jak działają wdrożenia w chmurze, i omawia ogólne strojenie Linux, które ma zastosowanie wszędzie.

​
Wybierz dostawcę

Railway

Konfiguracja jednym kliknięciem w przeglądarce

Northflank

Konfiguracja jednym kliknięciem w przeglądarce

DigitalOcean

Prosty płatny VPS

Oracle Cloud

Zawsze bezpłatny poziom ARM

Fly.io

Fly Machines

Hetzner

Docker na VPS Hetzner

Hostinger

VPS z konfiguracją jednym kliknięciem

GCP

Compute Engine

Azure

Maszyna wirtualna Linux

exe.dev

Maszyna wirtualna z proxy HTTPS

Raspberry Pi

Samodzielnie hostowane ARM
AWS (EC2 / Lightsail / warstwa bezpłatna) również działa dobrze. Społecznościowy przewodnik wideo jest dostępny pod adresem x.com/techfrenAJ/status/2014934471095812547 (zasób społecznościowy — może stać się niedostępny).

​
Jak działają konfiguracje w chmurze

  • Gateway działa na VPS i jest właścicielem stanu oraz przestrzeni roboczej.
  • Łączysz się z laptopa lub telefonu przez Control UI albo Tailscale/SSH.
  • Traktuj VPS jako źródło prawdy i regularnie twórz kopie zapasowe stanu oraz przestrzeni roboczej.
  • Bezpieczna konfiguracja domyślna: trzymaj Gateway na loopback i uzyskuj dostęp przez tunel SSH lub Tailscale Serve. Jeśli wiążesz z lan lub tailnet, wymagaj gateway.auth.token albo gateway.auth.password.
Powiązane strony: zdalny dostęp do Gateway, centrum platform.

​
Najpierw wzmocnij dostęp administracyjny

Zanim zainstalujesz OpenClaw na publicznym VPS, zdecyduj, jak chcesz administrować samym serwerem.
  • Jeśli chcesz mieć dostęp administracyjny tylko przez tailnet, najpierw zainstaluj Tailscale, dołącz VPS do swojego tailnetu, zweryfikuj drugą sesję SSH przez adres IP Tailscale lub nazwę MagicDNS, a następnie ogranicz publiczny SSH.
  • Jeśli nie używasz Tailscale, zastosuj równoważne wzmocnienie dla swojej ścieżki SSH przed udostępnieniem kolejnych usług.
  • To jest oddzielne od dostępu do Gateway. Nadal możesz utrzymywać OpenClaw powiązany z loopback i używać tunelu SSH lub Tailscale Serve dla panelu.
Opcje Gateway specyficzne dla Tailscale znajdują się w Tailscale.

​
Współdzielony agent firmowy na VPS

Uruchamianie jednego agenta dla zespołu jest poprawną konfiguracją, gdy każdy użytkownik znajduje się w tej samej granicy zaufania, a agent służy wyłącznie do pracy.
  • Utrzymuj go w dedykowanym środowisku uruchomieniowym (VPS/VM/kontener + dedykowany użytkownik/konta systemu operacyjnego).
  • Nie loguj tego środowiska uruchomieniowego do osobistych kont Apple/Google ani osobistych profili przeglądarki/menedżera haseł.
  • Jeśli użytkownicy są wobec siebie nieufni, rozdziel ich według gateway/hosta/użytkownika systemu operacyjnego.
Szczegóły modelu bezpieczeństwa: Bezpieczeństwo.

​
Używanie węzłów z VPS

Możesz utrzymywać Gateway w chmurze i sparować węzły na swoich lokalnych urządzeniach (Mac/iOS/Android/headless). Węzły zapewniają lokalny ekran/kamerę/canvas oraz możliwości system.run, podczas gdy Gateway pozostaje w chmurze. Dokumentacja: Węzły, CLI węzłów.

​
Strojenie startu dla małych maszyn wirtualnych i hostów ARM

Jeśli polecenia CLI wydają się wolne na maszynach wirtualnych o niskiej mocy (lub hostach ARM), włącz cache kompilacji modułów Node: 
grep -q 'NODE_COMPILE_CACHE=/var/tmp/openclaw-compile-cache' ~/.bashrc || cat >> ~/.bashrc <<'EOF'
export NODE_COMPILE_CACHE=/var/tmp/openclaw-compile-cache
mkdir -p /var/tmp/openclaw-compile-cache
export OPENCLAW_NO_RESPAWN=1
EOF
source ~/.bashrc
  • NODE_COMPILE_CACHE poprawia czas startu powtarzanych poleceń.
  • OPENCLAW_NO_RESPAWN=1 utrzymuje rutynowe restarty Gateway w tym samym procesie, co pozwala uniknąć dodatkowych przekazań między procesami i upraszcza śledzenie PID na małych hostach.
  • Pierwsze uruchomienie polecenia rozgrzewa cache; kolejne uruchomienia są szybsze.
  • Szczegóły dotyczące Raspberry Pi znajdziesz w Raspberry Pi.

​
Lista kontrolna strojenia systemd (opcjonalna)

W przypadku hostów VM używających systemd rozważ:
  • Dodanie zmiennych środowiskowych usługi dla stabilnej ścieżki startu:
    • OPENCLAW_NO_RESPAWN=1
    • NODE_COMPILE_CACHE=/var/tmp/openclaw-compile-cache
  • Utrzymanie jawnego zachowania restartu:
    • Restart=always
    • RestartSec=2
    • TimeoutStartSec=90
  • Preferowanie dysków opartych na SSD dla ścieżek stanu/cache, aby zmniejszyć koszty zimnego startu wynikające z losowego I/O.
Dla standardowej ścieżki openclaw onboard --install-daemon edytuj jednostkę użytkownika: 
systemctl --user edit openclaw-gateway.service

[Service]
Environment=OPENCLAW_NO_RESPAWN=1
Environment=NODE_COMPILE_CACHE=/var/tmp/openclaw-compile-cache
Restart=always
RestartSec=2
TimeoutStartSec=90
Jeśli celowo zainstalowano zamiast tego jednostkę systemową, edytuj openclaw-gateway.service przez sudo systemctl edit openclaw-gateway.service. Jak zasady Restart= pomagają w automatycznym odzyskiwaniu: systemd może automatyzować odzyskiwanie usług. Informacje o zachowaniu Linux przy OOM, wyborze procesu potomnego jako ofiary oraz diagnostyce exit 137 znajdziesz w presji pamięci w Linux i zabijaniu przez OOM.

​
Powiązane