Vai al contenuto principale

​
Server Linux

Esegui il Gateway OpenClaw su qualsiasi server Linux o VPS cloud. Questa pagina ti aiuta a scegliere un provider, spiega come funzionano i deployment cloud e copre le ottimizzazioni Linux generiche che si applicano ovunque.

​
Scegli un provider

Railway

Configurazione nel browser con un clic

Northflank

Configurazione nel browser con un clic

DigitalOcean

VPS a pagamento semplice

Oracle Cloud

Livello ARM Always Free

Fly.io

Fly Machines

Hetzner

Docker su VPS Hetzner

GCP

Compute Engine

Azure

VM Linux

exe.dev

VM con proxy HTTPS

Raspberry Pi

ARM self-hosted
Anche AWS (EC2 / Lightsail / free tier) funziona bene. È disponibile una guida video della comunità su x.com/techfrenAJ/status/2014934471095812547 (risorsa della comunità — potrebbe non essere più disponibile).

​
Come funzionano le configurazioni cloud

  • Il Gateway viene eseguito sul VPS e gestisce stato + workspace.
  • Ti connetti dal tuo laptop o telefono tramite la Control UI o Tailscale/SSH.
  • Considera il VPS come fonte di verità ed esegui backup regolari di stato + workspace.
  • Impostazione predefinita sicura: mantieni il Gateway su loopback e accedivi tramite tunnel SSH o Tailscale Serve. Se fai bind a lan o tailnet, richiedi gateway.auth.token o gateway.auth.password.
Pagine correlate: Accesso remoto al Gateway, Hub delle piattaforme.

​
Agente aziendale condiviso su un VPS

Eseguire un singolo agente per un team è una configurazione valida quando ogni utente si trova nello stesso confine di fiducia e l’agente è solo per uso aziendale.
  • Mantienilo su un runtime dedicato (VPS/VM/container + utente/account OS dedicati).
  • Non autenticare quel runtime con account Apple/Google personali o con profili personali di browser/password manager.
  • Se gli utenti sono avversari tra loro, separa per gateway/host/utente OS.
Dettagli del modello di sicurezza: Sicurezza.

​
Uso dei nodi con un VPS

Puoi mantenere il Gateway nel cloud e associare nodi sui tuoi dispositivi locali (Mac/iOS/Android/headless). I nodi forniscono funzionalità locali di schermo/fotocamera/canvas e system.run mentre il Gateway resta nel cloud. Documentazione: Nodi, CLI dei nodi.

​
Ottimizzazione dell’avvio per piccole VM e host ARM

Se i comandi CLI sembrano lenti su VM poco potenti (o host ARM), abilita la cache di compilazione dei moduli di 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 migliora i tempi di avvio dei comandi ripetuti.
  • OPENCLAW_NO_RESPAWN=1 evita overhead aggiuntivo di avvio dovuto a un percorso di auto-respawn.
  • La prima esecuzione di un comando riscalda la cache; le esecuzioni successive sono più rapide.
  • Per dettagli specifici su Raspberry Pi, vedi Raspberry Pi.

​
Checklist di ottimizzazione systemd (facoltativa)

Per host VM che usano systemd, considera quanto segue:
  • Aggiungi variabili di ambiente del servizio per un percorso di avvio stabile:
    • OPENCLAW_NO_RESPAWN=1
    • NODE_COMPILE_CACHE=/var/tmp/openclaw-compile-cache
  • Mantieni esplicito il comportamento di riavvio:
    • Restart=always
    • RestartSec=2
    • TimeoutStartSec=90
  • Preferisci dischi con SSD per i percorsi di stato/cache per ridurre le penalità di cold start dovute a I/O casuale.
Per il percorso standard openclaw onboard --install-daemon, modifica l’unità utente: 
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
Se invece hai installato deliberatamente un’unità di sistema, modifica openclaw-gateway.service tramite sudo systemctl edit openclaw-gateway.service. Come aiutano le policy Restart= nel recupero automatico: systemd can automate service recovery.