Come fare il self-hosting di OpenClaw nel 2026: Gateway, canali e sicurezza

Considera OpenClaw come un piccolo sistema, non come un'immagine Docker. L'obiettivo per gli utenti di OpenClaw è chiaro: un gateway per un assistente AI con oltre 22 integrazioni di canale; il deployment è accettabile solo quando puoi associare un canale di messaggistica, inviare un messaggio in ingresso, approvare il mittente, invocare uno strumento innocuo e riconnettere la Control UI dopo il riavvio del Gateway.

Questa distinzione permette di individuare il problema che gli operatori incontrano dopo i test locali: il Gateway si associa solo al loopback oppure il proxy scarta gli upgrade WebSocket. Inoltre, rende il piano di backup e upgrade abbastanza specifico da poter essere testato.

Scegli la topologia OpenClaw più semplice possibile

La topologia OpenClaw minima e corretta contiene un listener privato sulla porta 18789, una route di ingresso e un confine dello stato documentato. Il requisito esterno per OpenClaw è una chiave del model provider e almeno un canale associato. Testa DNS in uscita, TLS e il comportamento del provider senza pubblicare un altro servizio in ingresso.

Convalida la topologia chiedendo a un client pulito di associare un canale di messaggistica, inviare un messaggio in ingresso, approvare il mittente, invocare uno strumento innocuo e riconnettere la Control UI dopo il riavvio del Gateway. Durante l'esecuzione, monitora i turni paralleli degli agenti, la latenza del modello, i processi degli strumenti browser e le dimensioni della cronologia delle sessioni accumulata. Il risultato indica se il prossimo miglioramento riguarda memoria, storage, networking o un worker separato, invece di incoraggiare un dimensionamento arbitrario del container.

Diagnostica un'istanza OpenClaw apparentemente sana

Un health check inattivo dice poco su OpenClaw. Monitora i turni paralleli degli agenti, la latenza del modello, i processi degli strumenti browser e le dimensioni della cronologia delle sessioni accumulata, quindi genera alert sul sintomo effettivamente riscontrato dagli utenti: il fallimento dell'azione “associare un canale di messaggistica, inviare un messaggio in ingresso, approvare il mittente, invocare uno strumento innocuo e riconnettere la Control UI dopo il riavvio del Gateway”. Mantieni il liveness check locale ed economico; lascia che il readiness check segnali migrazioni o inizializzazione senza causare una raffica di riavvii.

L'area più rischiosa durante un upgrade è che una release possa modificare lo schema di configurazione del Gateway, le skill incluse, le dipendenze del browser o gli adapter dei canali. Leggi le note di rilascio, crea uno snapshot dello stato, esegui la versione target su una copia ripristinata e ripeti il test di accettazione. Se il Gateway si associa solo al loopback oppure il proxy scarta gli upgrade WebSocket, correla la richiesta del client con il primo log applicativo pertinente invece di eliminare lo stato o aggiungere redirect alla cieca.

Cinque verifiche più efficaci dell'health check del container

Il record della release di OpenClaw deve contenere fatti, non un semplice “sembra tutto a posto”. Salva il digest dell'immagine selezionata, il checksum della configurazione, l'hostname pubblico e il risultato con timestamp per: associare un canale di messaggistica, inviare un messaggio in ingresso, approvare il mittente, invocare uno strumento innocuo e riconnettere la Control UI dopo il riavvio del Gateway. Usa dati di esempio non di produzione, in modo che la verifica possa essere eseguita dopo ogni deployment.

Dimostra separatamente due eventi del ciclo di vita. La sostituzione di un container deve preservare il normale funzionamento; un ripristino pulito deve dimostrare che il Gateway ripristinato può riaprire il proprio workspace, riconoscere il canale associato e usare l'autenticazione del provider senza richiedere nuovamente l'onboarding. Durante le verifiche, misura i turni paralleli degli agenti, la latenza del modello, i processi degli strumenti browser e le dimensioni della cronologia delle sessioni accumulata, quindi conserva il risultato come intervallo atteso per questa versione.

Testa anche una condizione negata o non valida: nega temporaneamente il percorso di test usato da una chiave del model provider e da almeno un canale associato. OpenClaw deve fallire in modo diagnosticabile e non deve sovrascrivere lo stato integro. Ripristina la condizione valida, esegui nuovamente l'esempio e allega i log pertinenti, con i dati sensibili rimossi. Questi artefatti forniscono a una futura decisione di rollback prove concrete.

Esegui la prima istanza simile alla produzione

Mantieni la prima esecuzione di OpenClaw abbastanza riproducibile da poter essere revisionata in una pull request.

docker run -d \
  --name openclaw \
  --restart unless-stopped \
  -p 127.0.0.1:18789:18789 \
  -v openclaw-data:/home/node/.openclaw \
  -e OPENCLAW_GATEWAY_TOKEN=replace-with-a-long-random-value \
  -e OPENCLAW_GATEWAY_BIND=lan \
  ghcr.io/openclaw/openclaw:latest node dist/index.js gateway --bind lan --port 18789

Non fare affidamento su latest dopo che esistono dati reali. Registra il digest funzionante, l'utente del container e la proprietà del mount. Segui il log dell'applicazione per tutta la durata di un test completo — associare un canale di messaggistica, inviare un messaggio in ingresso, approvare il mittente, invocare uno strumento innocuo e riconnettere la Control UI dopo il riavvio del Gateway — e annota eventuali migrazioni prima di instradare il traffico di produzione.

Rendi misurabile il ripristino di OpenClaw

Un'immagine container può essere scaricata di nuovo; il workspace di OpenClaw, lo stato dei canali e la configurazione no. Monta /home/node/.openclaw prima del bootstrap, scrivi dati di esempio innocui e sostituisci il container per dimostrare che il percorso è effettivamente persistente. Ispeziona il mount effettivo invece di fidarti del nome di un file Compose e verifica che l'utente runtime possa scrivere nel percorso previsto da OpenClaw.

Scegli la retention e una destinazione off-host, quindi prova il ripristino senza toccare la produzione. L'esercitazione ha esito positivo solo quando il Gateway ripristinato può riaprire il proprio workspace, riconoscere il canale associato e usare l'autenticazione del provider senza richiedere nuovamente l'onboarding. Per lo stato basato su database, abbina gli snapshot dello storage a export coerenti con l'applicazione, come descritto in ripristino point-in-time e snapshot.

Testa OpenClaw dall'esterno del server

Considera l'URL esterno di OpenClaw come una configurazione che deve sopravvivere ai redeploy. Configura prima l'indirizzo pubblico del Gateway e un proxy compatibile con WebSocket; quindi instrada l'hostname verso la porta 18789 mantenendo invariati l'host e lo schema originali.

La checklist per verificare la raggiungibilità del deployment può dimostrare che le richieste entrano nel container. Da quel momento, il problema noto — il Gateway si associa solo al loopback oppure il proxy scarta gli upgrade WebSocket — deve essere analizzato in OpenClaw, nel suo stato o nel suo workload, non nell'automazione dei certificati.

Riduci le autorizzazioni detenute da OpenClaw

Le credenziali di bootstrap sono temporanee; il modello di trust è permanente. Con OpenClaw, verifica che il token del Gateway non venga lasciato non impostato e che non vengano approvate associazioni di canali sconosciute; usa un solo confine di trust per Gateway, esamina ogni associazione DM e applica il sandboxing agli strumenti che interagiscono con l'host.

Gestisci OPENCLAW_GATEWAY_TOKEN in base al suo ruolo in OpenClaw: mantieni i valori sensibili fuori da Git, documenta gli effetti della rotazione e non sostituire mai un esempio pubblico in produzione. Esegui l'immagine senza funzionalità Linux non necessarie ed esponi solo la route pubblica dell'applicazione. Mantieni visibile l'attività degli amministratori senza registrare valori segreti.

Collega OpenClaw al ciclo di vita di Dockup

Il layer della piattaforma per OpenClaw comprende la porta 18789, l'ingress, TLS, la configurazione runtime, lo storage e la raggiungibilità delle dipendenze. Dockup può riprodurre questi componenti sulla propria infrastruttura o su un server collegato dal cliente.

A quel punto l'operatore completa il layer del prodotto: configura l'indirizzo pubblico del Gateway e un proxy compatibile con WebSocket; applica questa regola di accesso — usa un solo confine di trust per Gateway, esamina ogni associazione DM e applica il sandboxing agli strumenti che interagiscono con l'host — ed esegue “associare un canale di messaggistica, inviare un messaggio in ingresso, approvare il mittente, invocare uno strumento innocuo e riconnettere la Control UI dopo il riavvio del Gateway”. Registrare questo test insieme al deployment evita di confondere il provisioning automatizzato con la readiness dell'applicazione.

Domande frequenti

Di cosa ha bisogno OpenClaw per un deployment in produzione?

Instrada il container OpenClaw sulla porta 18789 attraverso un'unica origine HTTPS. Il requisito esterno per la delivery è una chiave del model provider e almeno un canale associato. Non considerare OpenClaw pronto finché non puoi associare un canale di messaggistica, inviare un messaggio in ingresso, approvare il mittente, invocare uno strumento innocuo e riconnettere la Control UI dopo il riavvio del Gateway.

Quali dati di OpenClaw devono essere inclusi in un backup?

Rendi persistente /home/node/.openclaw e includi il workspace di OpenClaw, lo stato dei canali e la configurazione nello stesso manifest di ripristino. Un ripristino pulito di OpenClaw ha esito positivo solo quando il Gateway ripristinato può riaprire il proprio workspace, riconoscere il canale associato e usare l'autenticazione del provider senza richiedere nuovamente l'onboarding.

OpenClaw richiede HTTPS dietro un reverse proxy?

Usa HTTPS per l'origine pubblica di OpenClaw e mantieni la porta 18789 sulla route interna. Applica correttamente l'impostazione di OpenClaw: configura l'indirizzo pubblico del Gateway e un proxy compatibile con WebSocket. Per OpenClaw, HTTPS protegge le credenziali o i contenuti degli utenti durante il transito e mantiene coerente il comportamento del client sensibile all'origine.

Come si deve testare un upgrade di OpenClaw?

Ripristina lo stato corrente di OpenClaw in un deployment isolato, applica la versione candidata e ripeti la transazione di accettazione. Presta particolare attenzione perché una release può modificare lo schema di configurazione del Gateway, le skill incluse, le dipendenze del browser o gli adapter dei canali. Conserva la precedente immagine di OpenClaw finché non avrai compreso i limiti della migrazione dei dati e del rollback.