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 while the GitHub link it points to redirects to NodeODX. A YouTube tutorial from last month walks through webodm.sh start and you end up with Docker images named webodm/odx — not the opendronemap/odm images the tutorial’s pinned comment swears you should see.

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

Here’s the short version: there are now two parallel sets of names for the same four-layer photogrammetry stack, maintained by two different organizations, sharing one codebase that’s just starting to diverge. This article maps the names, tells you which one you’re actually installing, and explains what to watch for as the forks pull apart.

What Actually Happened in April 2026

On April 6, 2026, Piero Toffanin — the creator and primary maintainer of WebODM — pulled the project out of the OpenDroneMap nonprofit and re-established it as its own GitHub organization at github.com/WebODM. The full story, including the governance and revenue disagreements that drove the split, lives in the WebODM splits from OpenDroneMap migration guide.

What matters for naming: Toffanin didn’t just fork the WebODM web interface. He forked the entire stack. The processing engine, the REST API, the load balancer, the Python SDK — all of it moved into the new organization, and all of it got renamed. ODM became ODX. NodeODM became NodeODX. ClusterODM became ClusterODX. PyODM became PyODX. A net-new component — CloudODX, a CLI for headless cloud processing — was added on top.

The OpenDroneMap nonprofit at github.com/OpenDroneMap kept the original names — ODM, NodeODM, ClusterODM, PyODM — and continues developing them.

Both stacks remain under AGPL-3.0. Neither side can close the source. Both started from the same commit history. As of the fork date, the code is functionally identical. From here forward, the codebases will drift apart as each team merges its own pull requests.

GitHub’s redirects confirm the rename is real: 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 rename is baked into git history.

The Naming Map

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

The four-layer architecture is identical across both forks — engine, API, load balancer, UI. Only the names and the GitHub home change. If you want the long-form explanation of what each layer does, the ODM/WebODM ecosystem deep dive walks through every component.

Docker image namespaces follow the same split:

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

Both namespaces still pull successfully today. The opendronemap/* images are not deprecated and not abandoned — the OpenDroneMap nonprofit is actively publishing to them. They just won’t receive WebODM-fork updates anymore. Do not mix images across forks in the same Docker Compose file. Tag compatibility between webodm/nodeodx:3.6.0 and opendronemap/odm:3.6.0 was guaranteed on the day of the split. It is not guaranteed three months from now.

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 most install paths quietly default to the WebODM fork.

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

• You ran ./webodm.sh start after cloning from github.com/WebODM/WebODM. The default docker-compose.yml in that repo pulls webodm/* images.
• You’re using the Windows or macOS native installer downloaded from webodm.org.
• You’re a paying WebODM Lightning customer at webodm.net. Lightning runs the WebODM-fork stack end to end.
• You followed any installation tutorial published after April 2026 that referenced the canonical github.com/WebODM/WebODM URL.

You’re installing the OpenDroneMap fork (ODM/NodeODM/ClusterODM) 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 the WebODM UI on top.
• You’re running the standalone ODM CLI for batch processing on a server, integrating it into your own pipeline.

If you previously installed WebODM through the standard route and never touched the configuration, you’re now on the WebODM fork — the rename happened under your feet at the next git pull or image refresh. Your existing projects, settings, GCPs, and outputs are unaffected.

What This Means Going Forward

The forks are siblings today. They will not stay siblings.

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? Possibly, if either team cherry-picks it. The relationship between Toffanin and the OpenDroneMap board is strained enough that systematic upstream/downstream syncing seems unlikely. Expect each fix to be a one-off negotiation.

Docker tag compatibility will break. Today, webodm/odx:3.6.0 and opendronemap/odm:3.6.0 are the same engine. Six months from now they probably aren’t. If you mix images across namespaces — running opendronemap/nodeodm against webodm/odx, for example — you’re crossing a line that wasn’t a line on April 5 and is a line as of April 6. Don’t.

Community support fragments. The OpenDroneMap forum at community.opendronemap.org continues, populated mostly by users of the OpenDroneMap-fork stack. The WebODM project is building a separate community channel for users on the WebODM-fork stack. If you post a question with “ODX” in it on the OpenDroneMap forum, expect blank stares. Same in reverse.

Documentation is split. docs.webodm.org covers the WebODM fork. docs.opendronemap.org covers the OpenDroneMap fork. The legacy URL docs.opendronemap.org/webodm/ still loads but is increasingly stale for WebODM-fork users. Bookmark accordingly.

The accuracy of your maps doesn’t change. Both forks still call OpenSfM, OpenMVS, PDAL, and GRASS GIS. The pipeline order is identical. Your checkpoint RMSE will not shift because you switched namespaces. None of this fork drama touches the math.

Bottom Line

The fork is real. The renames are not a typo. ODM and ODX are the same engine today, maintained by different teams, on a trajectory to diverge.

If you ran the standard WebODM installer any time after April 6, 2026, you’re on the WebODM-fork stack — ODX, NodeODX, ClusterODX — whether you meant to be or not. That’s fine for the vast majority of operators. It’s the actively developed path, it ships with the WebODM UI most people actually use, and it powers WebODM Lightning if you ever decide to stop self-hosting.

If you want the OpenDroneMap nonprofit’s continuation, 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 default install path no longer points 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. The software didn’t.