WebODM: self-hosted drone image processing, what the repository actually ships

What WebODM is for, and who ends up running it

WebODM is a web application for processing aerial imagery. According to the README, it generates "georeferenced maps, point clouds, elevation models, textured 3D models and gaussian splats from aerial images." The audience is anyone holding a folder of drone photos and a machine to process them on: surveyors producing an orthophoto, researchers building a DEM, or a team that wants a browser interface instead of a command line.

The repository layout tells you what kind of project this is. There is a Django app under app/, a worker/ directory, a manage.py, a requirements.txt pinned to Django 2.2.27, and a docker-compose.yml that wires a webapp container to PostgreSQL, Redis as the broker, and a separate worker container. This is a server application, not a desktop tool.

One note from the README matters more than any feature list: "WebODM has officially decoupled from OpenDroneMap" and "WebODM is not affiliated with OpenDroneMap and is not a user interface to OpenDroneMap." If you arrived expecting the classic OpenDroneMap front end, that framing is outdated.

The processing engines, and why ODX replaced ODM

Processing is delegated. The README lists three engines: ODX, MicMac and LGT. It states plainly that "for processing, WebODM uses ODX, not ODM." The Python dependencies back this up: requirements.txt pins pyodx==1.5.14, and there is no ODM package in the list.

That decoupling has practical consequences. A WebODM instance is a coordinator: it stores projects and tasks, queues them, and hands the image set to an engine. The compose files reflect the split. docker-compose.yml carries the comment "This configuration does not include a processing node, which makes for faster setup times," so a fresh install comes up with a working web interface but nothing to process with until you attach a node. The repository ships separate compose files for that: docker-compose.nodeodm.yml, docker-compose.nodeodm.gpu.nvidia.yml, docker-compose.nodeodm.volume.yml and docker-compose.nodemicmac.yml.

If you are comparing engines, the README does not document accuracy differences between ODX, MicMac and LGT. It only names them.

Installing WebODM and processing a first dataset

The README points to two paths. The official installers are at https://webodm.org/download and the README says they are free to download; it also warns that "if you paid for an installer after April 2026, you bought a different software." The manual path is Docker Compose from the repository root.

Start by cloning the repository and bringing up the base stack. This uses the compose file that deliberately omits a processing node, so the web interface starts quickly.

git clone https://github.com/WebODM/WebODM.git
cd WebODM
docker compose up -d

After the containers settle, the webapp is reachable on the port defined by the WO_PORT environment variable. The compose file maps "${WO_PORT}:8000/tcp" and the same port over UDP. The stack depends on db, broker and worker, and the webapp entrypoint waits for PostgreSQL and Redis before running start.sh.

To process anything you need a node. The repository provides a compose file for a NodeODM-style node, which you can layer on top of the base stack.

docker compose -f docker-compose.yml -f docker-compose.nodeodm.yml up -d

With a node running, log in to the web interface, create a project, upload your aerial images, and start a task. The README does not document the upload workflow step by step; the documentation site at https://docs.webodm.org/ is where that lives. Hardware sizing is also not in the README, which instead links to a hardware requirements page under docs.webodm.org/installation.

Where WebODM stops being the right tool

The most common failure is a stack that looks healthy but cannot process. Because the default docker-compose.yml ships without a processing node, a user who runs only that file gets an interface with no engine behind it. The README's own comment about faster setup times is a hint, not a warning.

Resource limits are the second wall. The compose file sets oom_score_adj values of -100 for the database, -500 for the Redis broker and 250 for the worker, which means the worker is the process the kernel is most willing to kill under memory pressure. Photogrammetry is memory-hungry, and a worker that dies mid-task is the expected outcome on an undersized host. The repository also carries docker-compose.worker-cpu.yml and docker-compose.worker-memory.yml, which suggests resource tuning is a normal part of running this.

There is also a licensing boundary. WebODM is AGPL-3.0 and carries a separate TRADEMARK.md. If your plan involves offering a modified WebODM as a network service, the AGPL and the trademark guidelines are the two files to read before you commit to that architecture. Nothing here is legal advice; read the actual files.

Finally, if you only need a one-off orthophoto and already know OpenDroneMap's command line, WebODM's database, queue and web layer are overhead you are paying for a UI you will not use.

WebODM against WebODM Lightning and against raw OpenDroneMap

The README links to https://webodm.net/ under the label Lightning and lists LGT as one of the processing engines, but it does not explain the relationship between the self-hosted application and the hosted service. What can be confirmed is narrower: WebODM is software you install and run yourself, and Lightning is a separate thing the README points at with a badge and a URL. Anyone deciding between them should treat the hosted option as a distinct product and read its own documentation, because the repository does not describe its pricing, limits or data handling.

The OpenDroneMap comparison is easier to state because the README makes it explicitly. WebODM is not a user interface to OpenDroneMap, and its processing path runs through ODX. So the difference in approach is architectural: OpenDroneMap is a processing toolchain you invoke, while WebODM is a Django application with a PostgreSQL database, a Redis broker, a worker process and a browser front end that manages projects and tasks across engines. If you want to script a pipeline, the first fits better. If you want a shared, persistent place where several people upload imagery and track jobs, the second does.

Maintenance, upgrades and what the release cadence implies

The last push to the default branch was on 2026-09-22, and the most recent tagged release is v3.3.0 from 2026-09-05, preceded by v3.2.8 on 2026-08-12 and v3.2.7 on 2026-07-19. That is a steady patch cadence rather than a frozen project, and the repository is not archived.

Upgrade cost is mostly the usual container story: pull new images, bring the stack down and up, and let the entrypoint scripts run. The compose file mounts ${WO_MEDIA_DIR} into /webodm/app/media and ${WO_DB_DIR} into the PostgreSQL data directory, so your projects and imagery survive a container replacement as long as those host paths are backed up. The wait-for-postgres.sh and wait-for-it.sh scripts in the repository root exist precisely because startup ordering is not guaranteed, which is worth knowing when an upgrade appears to hang.

One dependency worth flagging: requirements.txt pins Django 2.2.27, an old LTS line, and several packages are pulled from GitHub release zip URLs rather than PyPI. That is a deliberate choice by the maintainers, but it means an upgrade can depend on those release assets still being reachable. The README says nothing about a rollback procedure, so plan your own before upgrading a production instance.

Editorial conclusion

Adopt WebODM if you want aerial imagery processed on your own hardware and can run Docker Compose with PostgreSQL, Redis and a worker container. Do not adopt it if you expect a drop-in replacement for OpenDroneMap's CLI or a paid hosted tier, because the README states WebODM is not affiliated with OpenDroneMap and is not a user interface to it. Verify first that your engine of choice is reachable from the node you configure, and check the AGPL-3.0 and trademark files before you redistribute anything.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. Project website
3. README
4. Releases
5. WebODM/WebODM on GitHub