Repository, immagini Docker e migrazioni tra le due linee

Perché i nomi contano#

Un'installazione Docker di WebODM o di ODM è fatta di tre cose: un repository Git con gli script, immagini Docker scaricate da un registro e volumi Docker con i tuoi dati. Dopo il 6 aprile 2026 le prime due hanno indirizzi diversi per le due linee, e molti tutorial in rete mescolano i vecchi con i nuovi. Sapere esattamente da dove arriva ogni pezzo è la premessa per migrare senza perdere progetti.

Termini usati qui: un repository (repo) è l'archivio del codice sorgente; un'immagine Docker è il pacchetto immutabile da cui si avvia un container; un volume Docker è lo spazio persistente dove il container scrive dati che devono sopravvivere; un tag è l'etichetta di versione di un'immagine (per esempio latest). Altre definizioni nel glossario.

I repository GitHub#

Il fatto centrale di questa tabella è nella seconda riga: la nonprofit non pubblica, alla data di verifica, il codice della sua interfaccia. Chi vuole un'interfaccia completa nella linea OpenDroneMap acquista OpenDroneMap Desktop (a pagamento su Windows, gratuito su Linux con installazione manuale). Chi vuole solo il motore o un nodo trova tutto il codice su github.com/OpenDroneMap. Lo scriviamo come fatto datato: la situazione può cambiare, e la aggiorneremo.

I namespace Docker#

Le immagini si distinguono dal prefisso, chiamato namespace: webodm/ per la linea WebODM, opendronemap/ per la linea OpenDroneMap.

Un'attenzione sui tag. Il tag latest cambia nel tempo, e da due linee diverse arriveranno contenuti diversi con lo stesso nome. Per un ambiente di produzione conviene fissare un tag esplicito o, meglio, il digest dell'immagine; la guida Stesso dataset, due motori spiega come leggerlo con docker inspect. Non riportiamo qui l'elenco dei tag perché cambia con ogni release: la fonte è la pagina dell'immagine su Docker Hub.

Un'attenzione sulle immagini opendronemap/webodm_webapp e sui vecchi cloni: un'installazione fatta prima del 2026 dal repository dell'organizzazione OpenDroneMap usa questa immagine. Dopo la separazione non è più aggiornata dall'autore originale di WebODM. Se resta com'è funziona, ma non riceve correzioni. Chi la trova sulla propria macchina deve scegliere: portarla sulla linea WebODM (sezione seguente) o passare al motore ODM della nonprofit con una delle vie della sezione successiva.

Migrazione da un'installazione OpenDroneMap alla linea WebODM#

Questa è la direzione più semplice, perché il codice dell'interfaccia è lo stesso e il repository di destinazione è pubblico. Riguarda chi ha clonato github.com/OpenDroneMap/WebODM prima di aprile 2026 e vuole ricevere gli aggiornamenti di WebODM.

1. Backup prima di tutto#

I dati di WebODM vivono in due volumi Docker: webodm_dbdata (database: utenti, progetti, metadati) e webodm_appmedia (file dei task e output). Salvali in archivi tar nella cartella dell'installazione.

mkdir backup
docker run --rm --volume webodm_dbdata:/temp --volume `pwd`/backup:/backup ubuntu tar cvf /backup/dbdata.tar /temp
docker run --rm --volume webodm_appmedia:/temp --volume `pwd`/backup:/backup ubuntu tar cvf /backup/appmedia.tar /temp

Al termine trovi backup/dbdata.tar e backup/appmedia.tar. Copiali anche fuori dalla macchina. La procedura di ripristino è in Aggiornare, fare backup e ripristinare.

2. Cambio del repository remoto e aggiornamento#

Nella cartella dell'installazione, sostituisci l'indirizzo remoto e aggiorna.

git remote set-url origin https://github.com/WebODM/WebODM.git
./webodm.sh update

Il primo comando cambia solo l'indirizzo da cui Git scarica il codice. Il secondo scarica il codice aggiornato e le nuove immagini con prefisso webodm/, poi riavvia i container. Progetti, utenti e risultati restano nei volumi e non vengono toccati.

3. Verifica#

git remote -v
docker images

Il primo comando deve mostrare WebODM/WebODM; il secondo deve mostrare immagini con prefisso webodm/. Le vecchie immagini opendronemap/ possono restare nel sistema e occupare spazio: rimuovile con docker image prune o docker rmi solo dopo aver verificato che tutto funzioni.

Un'osservazione: poiché l'indirizzo storico reindirizza già al nuovo repository, ./webodm.sh update su un vecchio clone potrebbe funzionare anche senza cambiare il remoto. Il cambio esplicito resta consigliabile, perché i reindirizzamenti non sono garantiti nel tempo.

Migrazione dalla linea WebODM alla linea OpenDroneMap#

Qui va detto con chiarezza che la direzione inversa non è simmetrica. Non esiste, alla data di verifica, un repository open dell'interfaccia della nonprofit verso cui puntare il proprio clone con un git remote set-url. Non è un giudizio: è la conseguenza del fatto che OpenDroneMap Desktop è distribuito come installer e non come codice pubblico. Le vie praticabili sono due, con caratteristiche diverse.

Via A: tenere WebODM come interfaccia e usare il motore ODM#

Puoi mantenere l'interfaccia WebODM e affidare le elaborazioni a un nodo NodeODM della nonprofit, cioè al motore ODM. È possibile perché al 6 aprile 2026 le API di NodeODM e NodeODX erano identiche. Va detto altrettanto chiaramente che questa configurazione non è supportata ufficialmente da nessuna delle due linee: funziona finché le API restano compatibili, e la compatibilità va verificata con le versioni in uso.

La procedura, in linea di principio:

1. Avvia un container opendronemap/nodeodm su una porta libera, diversa da quelle usate da WebODM. La porta predefinita storica di NodeODM è la 3000: verifica nel README dell'immagine il comando docker run consigliato.
2. In WebODM, aggiungi un nodo di elaborazione (menu Processing Nodes) con l'indirizzo e la porta del container.
3. Crea un task e scegli esplicitamente quel nodo.

Le opzioni che WebODM mostra per il task provengono dal nodo interrogato: se il nodo è NodeODM vedrai le opzioni di ODM, se è NodeODX quelle di ODX. Questo è anche il modo più diretto per confrontare i due motori dalla stessa interfaccia. Dettagli e cautele in NodeODX, ClusterODX e nodi remoti.

Via B: passare a OpenDroneMap Desktop e importare i progetti#

La seconda via è acquistare OpenDroneMap Desktop (o installarlo su Linux con la procedura manuale documentata dalla nonprofit) e portare i progetti. WebODM offre nell'interfaccia la funzione di importazione di task da altre istanze e da file: la funzione esiste nell'interfaccia di WebODM e, dato che OpenDroneMap Desktop è un fork di WebODM, è ragionevole aspettarsela anche lì, ma non lo abbiamo verificato. I dettagli sull'esportazione e sull'importazione sono su docs.webodm.org per WebODM e su docs.opendronemap.org per OpenDroneMap Desktop. Non descriviamo la procedura dell'interfaccia della nonprofit perché non l'abbiamo verificata.

I dati grezzi non dipendono dall'interfaccia: le immagini originali, i file GCP e gli output (GeoTIFF, LAS/LAZ, OBJ) sono file normali e si spostano da una linea all'altra senza conversioni, alla data di verifica.

Le due direzioni, affiancate:

Coesistenza: entrambe le linee sulla stessa macchina#

Per confrontare i motori, per servire utenti con esigenze diverse o per una transizione graduale, puoi tenere entrambe le linee sulla stessa macchina. Il principio è uno: due installazioni non devono contendersi le stesse risorse. Le risorse in gioco sono tre.

Porte. Due servizi non possono ascoltare sulla stessa porta. WebODM usa la 8000 per impostazione predefinita; NodeODM e NodeODX usano storicamente la 3000. Se avvii un secondo servizio, assegnagli una porta diversa. In webodm.sh esiste un'opzione documentata per cambiare la porta dell'interfaccia: trovala con ./webodm.sh --help e su docs.webodm.org. Per i container avviati a mano, la mappatura -p porta_host:porta_container di docker run fa lo stesso lavoro.

Nomi dei container. Docker rifiuta due container con lo stesso nome. Gli script webodm.sh assegnano nomi fissi ai propri container; due cloni di WebODM nella stessa macchina entrano in conflitto se non li rinomini. Le opzioni di webodm.sh per farlo, se disponibili nella versione in uso, sono documentate con ./webodm.sh --help. Per i container avviati a mano usa --name con un nome esplicito.

Volumi. Il punto più delicato, perché riguarda i dati. WebODM scrive in webodm_dbdata e webodm_appmedia. Due installazioni che condividono questi volumi si corromperebbero a vicenda. Per un secondo stack usa --media-dir e --node-dir verso cartelle diverse e verifica con ./webodm.sh --help come rinominare i volumi del database. Per NodeODM e ODM da riga di comando, monta cartelle dati diverse con -v.

Le combinazioni più comuni e il loro livello di rischio, alla data di verifica:

Una regola pratica: prima di avviare la seconda installazione, esegui docker ps per vedere porte e nomi in uso e docker volume ls per vedere i volumi esistenti. Dopo l'avvio, ripeti i due comandi e controlla che ogni installazione abbia i propri.

Problemi frequenti#

Dopo ./webodm.sh update i progetti sono spariti. Quasi sempre i volumi non sono stati toccati ma la nuova installazione ne sta usando altri, per esempio perché hai clonato in una cartella diversa o cambiato --media-dir. Controlla docker volume ls e ripristina dal backup solo se necessario.

Il nodo NodeODM non compare o dà errore in WebODM. Verifica che il container sia in esecuzione (docker ps), che la porta mappata sia quella inserita in WebODM e che le API siano compatibili con la tua versione di WebODM. Ricorda che la configurazione non è supportata ufficialmente.

Docker dice che il nome del container è già in uso. Due installazioni con gli stessi nomi. Ferma quella che non serve con ./webodm.sh down o rinomina i container come descritto sopra.

Voglio tornare indietro. Se hai il backup dei volumi, puoi ripristinarli su qualunque installazione di WebODM con la procedura della guida sui backup. Anche per questo il backup è il primo passo di ogni migrazione.

Prossimi passi#

• Scopri come confrontare le opzioni dei due motori dopo averli affiancati: Opzioni a confronto.
• Configura i nodi con le cautele del caso: NodeODX, ClusterODX e nodi remoti.
• Se stai valutando OpenDroneMap Desktop: OpenDroneMap Desktop.