ODM vs ODX: The April 2026 Fork, Explained for Drone Operators

You Google “ODM” and the first three results contradict each other. One page says the engine is called ODM. The next says it’s ODX. A Stack Overflow answer references NodeODM, but the repo WebODM points you to is NodeODX. A YouTube tutorial from last month walks through webodm.sh start, and you end up with a Docker image named webodm/nodeodx, not the opendronemap/nodeodm image the tutorial’s pinned comment swears you should see.

You’re not losing your mind. You’re catching the tail end of a real split that happened on April 6, 2026, and the new names haven’t fully propagated through the internet’s documentation yet.

Here’s the short version: there are now two separate stacks with shared ancestry. OpenDroneMap maintains the ODM tools. WebODM maintains the ODX tools. Same layers, different code, different teams. This article maps the names, tells you which one you’re actually installing, and explains what to watch for.

What Actually Happened in April 2026

On April 6, 2026, WebODM split from OpenDroneMap. WebODM’s documentation puts it plainly: “WebODM is no longer affiliated or connected to OpenDroneMap. They are two separate projects.” WebODM now lives in its own GitHub organization at github.com/WebODM, led by its lead maintainer, Piero Toffanin. The WebODM split migration guide covers what changed for users.

What matters for naming: the WebODM project didn’t just move the web interface. It forked the whole engine stack and gave the forks new names. ODM became ODX. NodeODM became NodeODX. ClusterODM became ClusterODX. PyODM became PyODX. CloudODM, a command-line tool for cloud processing, became CloudODX.

These are forks, not renames. WebODM describes ODX as “forked from, faster than ODM,” and its migration guide pitches ODX as an improvement over ODM, not a copy of it.

OpenDroneMap at github.com/OpenDroneMap kept the original names. It continues developing ODM and NodeODM. Its ClusterODM, PyODM, and CloudODM repositories are still there but have had no commits since the split. As WebODM’s migration guide puts it, ClusterODX keeps receiving updates and ClusterODM does not.

Licences differ by component. WebODM, ODX, NodeODX, and ClusterODX are AGPL-3.0, as are OpenDroneMap’s ODM, NodeODM, and ClusterODM. PyODX is BSD-3-Clause and CloudODX is GPL-3.0. Both stacks share commit history up to the fork. From there, they’re developed separately.

GitHub’s redirects show the change on WebODM’s side: WebODM/ODM 301-redirects to WebODM/ODX. WebODM/NodeODM redirects to WebODM/NodeODX. OpenDroneMap/WebODM redirects to WebODM/WebODM. These aren’t unofficial mirrors.

The Naming Map

If you only remember one table from this article, make it this one:

The layers line up across both projects: engine, API, load balancer, UI. The code behind each layer doesn’t. Each project develops its own, so don’t treat the two columns as interchangeable. If you want the long-form explanation of what each layer does, the ODM/WebODM ecosystem deep dive walks through every component.

One row trips people up. OpenDroneMap sells installers for forks of WebODM, called “WebUI” or “OpenDroneMap Desktop.” As WebODM’s own site puts it, those are not WebODM. WebODM itself is a free download from webodm.org.

Docker image namespaces follow the same split:

• webodm/odx, webodm/nodeodx, webodm/clusterodx, webodm/webodm_webapp — WebODM’s images
• opendronemap/odm, opendronemap/nodeodm, opendronemap/clusterodm — OpenDroneMap’s images

Both namespaces still pull today. OpenDroneMap still develops ODM and NodeODM; its images just don’t receive WebODM’s updates. Do not mix images across the two projects in the same Docker Compose file. WebODM only guarantees compatibility with its own NodeODX, so running current WebODM against opendronemap/nodeodm is not a supported setup.

Which One Are You Actually Installing?

This trips up most people. You don’t pick “ODM vs ODX” the way you pick “Pix4D vs Metashape.” You pick it implicitly based on which install path you follow, and the WebODM install paths all lead to ODX.

You’re installing the WebODM stack (ODX/NodeODX) if:

• You ran ./webodm.sh start after cloning from github.com/WebODM/WebODM. The default setup pulls webodm/webodm_webapp and webodm/nodeodx, which runs ODX.
• You’re using the Windows or macOS native installer downloaded from webodm.org.
• You followed any installation tutorial published after April 2026 that referenced the canonical github.com/WebODM/WebODM URL.

You’re installing the OpenDroneMap stack (ODM/NodeODM) if:

• You specifically pulled opendronemap/odm, opendronemap/nodeodm, or opendronemap/clusterodm Docker images in your own Compose file or Kubernetes manifest.
• You cloned from github.com/OpenDroneMap/ODM and built or ran the engine directly without a UI on top.
• You’re running the standalone ODM CLI for batch processing on a server, integrating it into your own pipeline.

You’re on neither if you use WebODM Lightning at webodm.net. Lightning processes on LGT, its own engine, which is only available on Lightning. It doesn’t run ODM or ODX.

If you previously installed WebODM through the standard route and never touched the configuration, you’re now on the WebODM stack. The switch to ODX happened at your next git pull or image refresh. Your existing projects and finished outputs stay where they are.

What This Means Going Forward

The two stacks share ancestry. They don’t share a roadmap.

Bug fixes may or may not cross over. When a contributor finds a SfM bug and patches it in ODM, will the patch land in ODX? Only if someone ports it. No public source describes plans to sync fixes between the projects, so expect each fix to land on one side unless someone carries it over.

Docker images aren’t interchangeable. ODX and ODM are separate engines, maintained by different teams. If you mix images across namespaces — running opendronemap/nodeodm behind current WebODM, for example — you’re outside what WebODM supports. Don’t.

Community support fragments. The OpenDroneMap forum at community.opendronemap.org continues for users of OpenDroneMap’s stack. WebODM has its own Discord, linked from webodm.org. Ask ODX questions in WebODM’s channels and ODM questions on the OpenDroneMap forum.

Documentation is split. docs.webodm.org covers WebODM and ODX. docs.opendronemap.org covers OpenDroneMap’s stack. Don’t rely on the OpenDroneMap docs for current WebODM behaviour. Bookmark accordingly.

Check your accuracy. Don’t assume it. Both engines build on OpenSfM, OpenMVS, and PDAL, but ODX is developed separately and WebODM says it’s faster than ODM. If you switched engines, re-run a dataset you know and compare. ODX’s Quality Report makes that straightforward: give checkpoints a CHK- label prefix in your GCP file, and the report lists each checkpoint’s X, Y, and Z error alongside reprojection error, overlap, and camera calibration.

The fork is real. The new names are not a typo. ODM and ODX share ancestry, but they’re separate engines, maintained by different teams.

If you installed or updated WebODM from webodm.org or github.com/WebODM after the split, you’re on the WebODM stack — ODX and NodeODX — whether you meant to be or not. That’s fine for the vast majority of operators. It’s the stack WebODM develops and supports. And if you ever decide to stop self-hosting, WebODM Lightning is the hosted option, running its own LGT engine.

If you want OpenDroneMap’s engine, you can still get it, but you have to ask for it explicitly by pulling the opendronemap/* images or cloning from github.com/OpenDroneMap. The WebODM install path doesn’t point there.

Pick one stack. Stay on it. Don’t mix Docker namespaces. Update your bookmarks, update your docker-compose.yml, and get back to processing imagery — which, comparing the open-source stack to Pix4D, Metashape, and the commercial alternatives, still comes out free and still produces real maps.

The address changed, and so did the engine: WebODM now runs ODX.