Se stai cercando di avviare OpenClaw per la prima volta, ciò che di solito ti rallenta non è il comando di installazione. È scegliere il percorso sbagliato prima ancora di iniziare.

La maggior parte delle persone finisce nello stesso giro. Vede setup da source, Docker, onboarding CLI, installazione locale, deployment cloud e all’improvviso una domanda semplice diventa un piccolo progetto di ricerca. Deve stare sul laptop o su un server? Il setup da source è la strada “corretta”? Docker è automaticamente più facile? Se voglio solo farlo funzionare oggi, quale percorso è davvero meno fastidioso?

Dopo aver riletto il README di OpenClaw e la documentazione Docker ufficiale, la risposta sembra molto meno drammatica di quanto suggeriscano i risultati di ricerca. Non è davvero una questione di quali comandi siano migliori. È soprattutto una questione di capire se vuoi usare OpenClaw adesso oppure se vuoi assumerti fin dal primo giorno la responsabilità del runtime e del processo di build.

Prima decidi: vuoi usarlo o possederne il runtime?

Se sei un utente normale e l’obiettivo è semplicemente far funzionare OpenClaw sulla tua macchina, non partirei dal setup da source. Il README indica già il percorso pensato per l’utente: usare un ambiente Node recente, attualmente Node 24 o almeno Node 22.16+, installare la CLI e avviare l’onboarding:

npm install -g openclaw@latest
openclaw onboard --install-daemon

Questo flusso sembra esattamente ciò che dovrebbe essere: il punto di ingresso per l’utente. Installi la CLI, lasci che l’onboarding ti guidi nella configurazione iniziale e scopri se il prodotto ti è davvero utile.

Il percorso da source ha una forma completamente diversa:

git clone https://github.com/openclaw/openclaw.git
cd openclaw

pnpm install
pnpm ui:build
pnpm build

pnpm openclaw onboard --install-daemon
pnpm gateway:watch

Non è soltanto un altro metodo di installazione. È molto più vicino all’assumersi un ambiente di sviluppo. Stai clonando il repository, costruendo la UI, compilando il progetto e mettendoti nella situazione in cui anche i futuri problemi di build diventano parte della tua vita. È ottimo se vuoi controllo. Molto meno se vuoi semplicemente OpenClaw funzionante prima di cena.

Penso che sia qui che molte persone si confondono. Il setup da source suona più serio, quindi può sembrare la scelta “giusta”. Ma per la maggior parte degli utenti alla prima installazione è soprattutto la scelta più pesante. Ti porti dietro versione di Node, installazione delle dipendenze, passaggi di build, compilazione della UI e attrito negli upgrade prima ancora di aver deciso se vuoi continuare a usare lo strumento.

Docker non è automaticamente più leggero: laptop vs server

Docker crea una confusione simile. Le persone sentono “Docker” e pensano automaticamente che significhi più facile. A volte sì. A volte decisamente no. La documentazione Docker di OpenClaw è piuttosto onesta: Docker è opzionale. Ha senso quando vuoi un gateway containerizzato, un ambiente isolato o un percorso di deployment su un host che conviene trattare come infrastruttura invece che come computer quotidiano. Se sei sulla tua macchina e vuoi soltanto la strada più breve verso un’installazione funzionante, la documentazione ti riporta al flusso normale.

Questa distinzione conta molto. Su un computer locale Docker porta spesso un proprio costo di setup. Servono Docker Desktop o Docker Engine, Compose v2, memoria sufficiente per build o runtime dell’immagine e un po’ più di pazienza su hardware modesto. La documentazione segnala perfino che l’image build richiede almeno 2 GB di RAM, altrimenti pnpm install può essere terminato su un host con poca memoria. Tutto questo non rende Docker cattivo. Significa soltanto che su un laptop non è automaticamente la strada di minor resistenza.

Su un VPS o un server Linux la storia cambia. Se il piano è mantenere OpenClaw lì nel lungo periodo, Docker inizia a risultare molto più naturale. Non perché sia magico, ma perché si adatta meglio al lavoro. L’isolamento del runtime aiuta. I rebuild sono più puliti. Spostare tutto su un’altra macchina è più facile da ragionare. In quel contesto Docker sembra meno un trucco d’installazione e più il confine di deployment corretto.

Il workflow Docker ufficiale lo riflette. Non è scritto come un simpatico tutorial one-liner. Il percorso documentato principale consiste nell’eseguire ./scripts/docker/setup.sh dalla root del repository e lasciare allo script la gestione di image setup, onboarding, .env e avvio Docker Compose. Se non vuoi fare build localmente, la documentazione mostra anche come indicare prima un’immagine precompilata:

export OPENCLAW_IMAGE="ghcr.io/openclaw/openclaw:latest"
./scripts/docker/setup.sh

Questo dice molto su cosa sta cercando di fare il percorso Docker. Non nasconde ogni parte mobile: impacchetta il runtime. Anche la documentazione distingue tra azioni di setup e workflow CLI dopo l’avvio. In altre parole, questo è territorio di deployment, non “prima installazione software su un nuovo laptop”.

Riassunto in una riga: scegliere un percorso significa scegliere il costo di manutenzione

Se dovessi dare la versione semplice: se OpenClaw gira sul tuo computer, inizia dal flusso di onboarding CLI ufficiale. Se va su una macchina Linux cloud e prevedi di lasciarlo lì, Docker è probabilmente più adatto. Se sai già di voler ispezionare gli internals, cambiare comportamento, restare vicino al repository e possedere il processo di build, allora il setup da source ha finalmente senso.

Per me la vera differenza tra source setup e Docker non è il numero di comandi. È dove vuoi che viva il peso della manutenzione. Il source setup offre trasparenza e flessibilità, ma rende installazione dipendenze, build UI, environment drift e modifiche repo-level un tuo problema. Docker sposta molto di questo dentro il confine del container, cosa ottima sui server; restano però da gestire persistenza, porte, health check, aggiornamenti immagine ed esposizione. La documentazione parla di healthz, readyz, lan, loopback e perfino di policy firewall Docker sugli host pubblici: un’indicazione abbastanza forte che questo è un workflow di deployment per operatori.

I quattro errori più comuni

Gli errori sono di solito prevedibili. Si tratta il setup da source come percorso predefinito anche se in realtà è più vicino a una modalità dev. Si presume che Docker debba essere più facile persino su una macchina locale. Si ignorano requisiti runtime come la versione Node e poi si perde tempo a diagnosticare i sintomi invece della causa. Oppure si fa partire una volta il deployment server e si dimentica che persistenza e recovery contano più del primo boot riuscito.

Se pensi di mantenere OpenClaw su un server, quello è anche il momento in cui i backup smettono di essere opzionali nella pratica. Il mio precedente articolo sul backup dei volumi Docker su GitHub come percorso di recovery economico vive esattamente in questa zona. È meno emozionante dell’installazione, ma diventa molto più prezioso la prima volta che devi ricostruire qualcosa.

Ciò che mi è piaciuto della documentazione OpenClaw, una volta smesso di leggerla come una guida di installazione generica, è che in realtà serve abbastanza bene tipi diversi di persone. C’è un percorso per chi vuole usare lo strumento, uno per chi vuole deployarlo e uno per chi vuole lavorare sul progetto. Gran parte della confusione nasce dal mescolare questi ruoli troppo presto.

Se stai costruendo il tuo workflow server, vale la pena guardare anche l’hub sul deployment. Continuerò ad aggiungere articoli nello stesso cluster: setup locale, deployment VPS, trade-off Docker e come evitare di rendere inutilmente pesanti installazioni semplici.