OpenClaw 24/7 su un VPS: installazione sicura

Su un portatile, OpenClaw tace appena chiudi il coperchio: i messaggi WhatsApp si accumulano, i job pianificati aspettano che torni. Su un server continua a rispondere. Il problema è che il gateway non è un widget di chat. Custodisce le credenziali dei tuoi canali e, finché non attivi una sandbox, esegue gli strumenti direttamente sull'host. Spostarlo su una macchina sempre accesa ha senso solo se il modello di sicurezza trasloca insieme a lui.

Questa guida lo fa in circa 20 minuti su un VPS Ubuntu 24.04 appena creato.

Ultima verifica il 2026-10-04 con OpenClaw 2026.9.8 (npm), Node 24.21 LTS e Ubuntu 24.04.

Cosa ti serve

• Un VPS Linux. Noi usiamo il nostro piano AI-Agent: 4 vCPU, 4 GB di RAM, 40 GB di disco, 10 $ al mese. La documentazione di OpenClaw cita 6 GB di RAM, ma è per buildare la loro immagine Docker dai sorgenti; il pacchetto npm non richiede build.
• Una chiave API del tuo provider di modelli e gli account di messaggistica da collegare.
• Una chiave SSH sul portatile. Se non l'hai ancora: accesso con chiave SSH.

Un piano in NAT va bene qui, anzi probabilmente è più adatto. Il gateway non ha mai bisogno di una porta in ingresso aperta: WhatsApp, Discord e Telegram (long polling di default) si collegano verso l'esterno, e alla dashboard arrivi via SSH. Prendi un IPv4 dedicato solo se un canale che ti serve consegna via webhook o se vuoi mettere davanti un reverse proxy pubblico.

1. Un utente che non sia root

OpenClaw esegue gli strumenti come l'utente proprietario del gateway. Se quell'utente è root, lo è anche ogni comando che un modello confuso o manipolato via prompt injection decide di lanciare. La documentazione di OpenClaw definisce l'esecuzione come root insicura e non supportata. Crea un utente dedicato senza sudo:

# come root
apt update && apt -y upgrade
adduser --disabled-password --gecos "" claw
install -d -m 700 -o claw -g claw /home/claw/.ssh
install -m 600 -o claw -g claw ~/.ssh/authorized_keys /home/claw/.ssh/authorized_keys   # la chiave aggiunta in fase d'ordine
loginctl enable-linger claw

L'ultima riga conta più di quanto sembri. OpenClaw installa un servizio systemd utente, e senza lingering quel servizio si ferma quando esci. È il «ieri funzionava» più comune sui server.

2. Node 24 e OpenClaw

OpenClaw 2026.9.8 richiede Node >=24.16.0 <25 oppure >=26.1.0. Il pacchetto nodejs di Ubuntu è più vecchio, quindi prendiamo la 24 LTS da NodeSource:

# come root
curl -fsSL https://deb.nodesource.com/setup_24.x | bash -
apt install -y nodejs
node -v          # v24.16.0 o successiva
npm install -g openclaw@latest
openclaw --version

Anche il comando ufficiale su una riga (curl -fsSL https://openclaw.ai/install.sh | bash) funziona e installa Node per te. Su un server preferiamo i due passaggi espliciti: vedi cosa finisce dove, e il binario sta in /usr/bin invece che in una home dove l'agente può scrivere.

3. Onboarding come utente dell'agente

Accedi come claw via SSH, non con su. Solo un vero login avvia il gestore utente di systemd di cui il servizio ha bisogno:

# dal portatile (piano NAT: aggiungi -p <la tua porta SSH>)
ssh claw@<server>

openclaw onboard --install-daemon
openclaw gateway status

La procedura guidata verifica l'accesso al modello, scrive ~/.openclaw/openclaw.json, genera un token del gateway e installa il servizio. Se systemctl --user si lamenta del bus, esegui export XDG_RUNTIME_DIR=/run/user/$(id -u) e riprova.

Poi chiudi i file. La raccomandazione di OpenClaw stesso è 700 sulla directory di stato e 600 sulla configurazione:

chmod 700 ~/.openclaw && chmod 600 ~/.openclaw/openclaw.json
openclaw security audit --deep

openclaw security audit --fix applica la parte sicura delle correzioni: permessi più stretti e allowlist al posto di policy di gruppo aperte. Non cambia l'indirizzo di ascolto e non configura firewall; l'esposizione di rete resta compito tuo.

4. Tieni il gateway su loopback

Il gateway serve la sua API WebSocket e la dashboard su un'unica porta, 18789, legata a 127.0.0.1 per impostazione predefinita. Lascialo lì. Una configurazione minima che lo mette per iscritto:

// ~/.openclaw/openclaw.json
{
  gateway: {
    mode: "local",
    bind: "loopback",
    port: 18789,
    auth: { mode: "token", token: "paste-output-of-openssl-rand-hex-32" },
  },
}

Genera il token con openssl rand -hex 32 o openclaw doctor --generate-gateway-token. Il gateway rifiuta token vuoti e i valori d'esempio, e l'audit avvisa sotto i 24 caratteri.

Cosa non fare: impostare bind su "lan" e aprire la porta. La documentazione è chiara: mai esporre il gateway senza autenticazione su 0.0.0.0, e mai inoltrare la porta in modo ampio, nemmeno con un token. Chi ottiene quel token diventa operatore di un processo che può eseguire comandi sul tuo server.

Lato firewall, consenti SSH e nient'altro:

# come root
ufw allow OpenSSH
ufw enable
ufw status verbose

Sui nostri piani NAT la dashboard mostra una porta SSH esterna, ma dentro il server sshd ascolta sempre sulla 22. Consenti OpenSSH (porta 22), non il numero di porta esterno, altrimenti ufw enable ti chiude fuori. Approfondimenti nella guida a UFW.

5. Raggiungi la dashboard via SSH

Dal portatile apri un tunnel e lascialo aperto:

ssh -N -L 18789:127.0.0.1:18789 claw@<server>
# piano NAT: ssh -N -p <la tua porta SSH> -L 18789:127.0.0.1:18789 claw@<host>

Apri http://127.0.0.1:18789/ e incolla il token del gateway. Lo sshd predefinito di Ubuntu consente l'inoltro locale; se l'hai irrobustito, AllowTcpForwarding local è l'impostazione che permette -L bloccando gli inoltri remoti. Se il tunnel fallisce con administratively prohibited, controlla proprio quella riga.

Va bene anche una tailnet: Tailscale Serve tiene il gateway su loopback e gestisce l'accesso. Entrambe le strade vanno bene. Una porta pubblica no.

6. Pairing, sandbox e chi può parlargli

I canali di chat sono l'altra porta d'ingresso. Per impostazione predefinita i canali con messaggi diretti chiedono ai mittenti sconosciuti di fare prima il pairing; approvi tu dal server:

openclaw pairing approve <channel> <code>

Nei gruppi richiedi una menzione, così l'agente non risponde a ogni messaggio della stanza. La configurazione irrobustita di OpenClaw usa dmPolicy: "pairing" e groups: { "*": { requireMention: true } } per canale.

Due avvertenze oneste. Primo: il pairing controlla chi può avviare un turno, non cosa finisce nel contesto del modello; un messaggio inoltrato o una pagina web scaricata possono comunque orientare un turno avviato da te. Secondo: gli strumenti della sessione principale girano sull'host finché non abiliti la sandbox (agents.defaults.sandbox.mode: "non-main" isola tutto tranne la tua sessione principale). La sandbox è disattivata di default e il suo backend predefinito è Docker, quindi installa Docker prima di attivarla: Docker su un VPS. Se persone di cui non ti fidi condividono un canale con il bot, usa un gateway separato, meglio ancora su un server separato.

7. Aggiornamenti e backup

openclaw update
openclaw gateway status
openclaw backup create --output ~/backups/openclaw --verify

~/.openclaw contiene la configurazione, le credenziali dei canali (sessione WhatsApp compresa), i profili di autenticazione dei modelli e le trascrizioni delle sessioni. Perderlo significa rifare tutti i pairing; farlo trapelare significa che qualcun altro è te su WhatsApp. Fai il backup e tienilo fuori dal server: scaricalo con scp o usa restic con la cifratura.

Checklist

Dove si inserisce EQVPS

Molti provider possono far girare un processo Node. Noi aggiungiamo il pagamento in crypto senza KYC, un piano NAT adatto a un gateway solo su loopback e un server MCP che il tuo agente può usare per gestire i propri server. Se ci colleghi OpenClaw, leggi prima le protezioni MCP: un token che può ordinare server merita la stessa attenzione del token del gateway. Per una panoramica più ampia sugli agenti su un VPS, vedi la guida agli agenti IA.

La nostra opinione: questi 20 minuti fanno la differenza tra un assistente e una shell aperta con un'interfaccia di chat. Fai almeno i passaggi 1, 4 e 5, anche se salti il resto.