We’re keeping the projects coming at OpenDroneMap. In addition to crucial library updates on the photogrammetry engine, we needed a new front end. To that end, we announce today OpenDroneMap WebUI:
3D model your world with OpenDroneMap
This is a web front end for OpenDroneMap for those that require a modernized web stack for reasons of performance and security.
What makes WebUI new? As a hard fork of WebODM, it carries forward the functionality of it’s ancestor, while updating the underlying images, libraries, web framework, and broker (oh my!).
How much newer is this new kid? As compared with the competition, rather than dependencies 5-10 years old, major dependencies are 5-10 months old.
Ubuntu 20.04 → Alpine 3.24
Postgres 9.5.25 → 18
Postgis 2.3.2 → 3.6.4
Redis 7.0.10 → Valkey 9.1.0
Django 2.2.27 → 6.0.7
This work was tirelessly executed by Sashin Ranasinghe, and represents some really fantastic effort and execution https://sashin.dev/
3 Likes
system
Closed
October 18, 2026, 9:49pm
2
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
Now with migration scripts from WebODM, in case you want all the features, and upgrade to a modernized, more secure stack:
main ← migrations
opened 03:06PM - 27 Oct 26 UTC
We updated both Django and Postgres when forking to WebUI. Both require migratio… ns.
There are two main variants we need to consider.
1. A default user will have the data stored in a docker volume.
2. Expert users may use --db-dir to store the data on the native
filesystem.
Both cases have extra checks in place to ensure we do not lose any data. The full migration in both cases is carefully constructed to allow WebODM to function afterwards if the migration fails. Data will always be preserved.
On first boot of WebUI, we check to see if the WebUI database exists. If it doesn't, we prompt for the migration process. If accepted, we start up both the old and new database and run `pg_dump` and pipe it to the new database. Finally once we know the data is secure, in the case of a native disk, we swap the new and old files. This gives us an updated Postgres database. We don't copy or modify the media files to avoid excessive disk consumption.
If the user declines to migrate their data, it is possible to still do the migration as long as the new database remains empty.
```
Found a WebODM database (docker volume webodm_dbdata). Import it? [Y/n] y
Importing from WebODM
================================
WebODM database: webodm_dbdata
WebODM media: docker volume webodm_appmedia (used in place)
================================
Starting the WebODM database...
Starting the OpenDroneMap WebUI database...
Copying the database...
time="2026-10-27T14:59:10Z" level=warning msg="/tmp/webui-fresh/docker-compose.yml: the attribute `version` is obsolete, it will be ignored, please remove it to avoid potential confusion"
users: 2
projects: 1
tasks: 1
processing nodes: 1
Done! WebODM data imported.
docker compose -f docker-compose.yml -f docker-compose.nodeodm.yml up
```
The implementation is split into a python file `importwebodm.py` and a bash file `import-webodm.sh`. This is to aid reusability.
Once the postgres migration is complete, the next step is to migrate the Django models. This is done automatically when the app is first run. eg.
```
webapp | Operations to perform:
webapp | Apply all migrations: admin, app, auth, contenttypes, guardian, nodeodm, sessions
webapp | Running migrations:
webapp | Applying app.0045_django52_field_updates... OK
webapp | Applying app.0052_merge_0045_django52_field_updates_0051_init_basemaps... OK
webapp | Applying app.0053_alter_basemap_id_alter_plugindatum_id_and_more... OK
webapp | Applying app.0054_alter_setting_organization_name_and_more... OK
webapp | Applying auth.0012_alter_user_first_name_max_length... OK
webapp | Applying guardian.0002_generic_permissions_index... OK
webapp | Applying nodeodm.0010_django52_jsonfield_update... OK
webapp | Applying nodeodm.0011_merge_20260630_2319... OK
webapp | Applying nodeodm.0012_alter_processingnode_id_and_more... OK
```
I've been testing this locally with dummy data. We obviously need to be extra careful testing this so I would appreciate it if others could also test to make sure. If you do want to help, please make sure you have a spare copy of the data if its important!
If you’re running on Linux, please dive in and help with testing!
Make good, verified, restorable backups
Run migration script
Test test test
1 Like