WebODM, ODX & OpenDroneMap Explained: Two Separate Projects

Someone tells you to “use ODM” for processing your drone imagery. You Google it. You find OpenDroneMap. Then WebODM. Then NodeODX. Then ClusterODX. Then — if you dig further — ODX, CloudODX, PyODX, NodeODM, ClusterODM, PyODM. Two parallel sets of names, multiple GitHub organizations, and no obvious explanation of how any of it fits together.

You’re not confused because you’re uninformed. You’re confused because of an April 2026 split: WebODM became a separate project from OpenDroneMap, and the WebODM team forked the engine stack under new “ODX” names. OpenDroneMap kept the “ODM” names.

Here’s what’s actually going on: these are two separate projects that share a common origin. Each is a layered stack (engine, API, load balancer, and a web interface on top). Most people — including experienced operators — conflate them. That conflation leads to wrong installation choices, mismatched Docker image tags, and frustration when the “free Pix4D alternative” doesn’t behave the way they expected.

This article untangles the layers, explains what changed in the split, and tells you which components you actually need.

The Engine: ODX (WebODM) and ODM (OpenDroneMap)

The processing engine is a command-line toolkit written in Python. It takes aerial images as input and produces orthomosaics, point clouds, 3D textured models, and digital elevation models as output. That’s it. No interface. No buttons. Just a CLI that reads images from a directory and writes outputs to another directory.

The engine exists in two forks: ODX at github.com/WebODM/ODX (the engine WebODM uses, forked from ODM in April 2026; its README describes it as faster than ODM) and ODM at github.com/OpenDroneMap/ODM (OpenDroneMap’s original engine). Both are AGPL-3.0. They share an origin but are developed independently, so don’t treat them as interchangeable.

Under the hood, the engine chains together a sequence of open-source libraries: OpenSfM for structure-from-motion, OpenMVS for dense reconstruction, PDAL and Entwine for point cloud handling, MVS-Texturing and PoissonRecon for meshing and texturing, and GDAL for raster processing. The pipeline is sequential — feature extraction, matching, sparse reconstruction, dense point cloud, mesh generation, texturing, georeferencing, DEM, orthophoto. Each step feeds the next.

If you’re comfortable with Docker and terminal commands, you can run either engine directly. Most people aren’t, and that’s fine — both are designed to be wrapped by other tools. Think of it as the engine block inside a car. Essential, but you don’t interact with it by hand unless you’re a mechanic.

Which one you end up using is determined by which API layer (NodeODX vs NodeODM) you install. WebODM’s installers and its standard Docker setup use NodeODX + ODX.

NodeODX (and NodeODM): The API Layer

The API layer is a lightweight REST service written in Node.js that wraps the engine. It turns the command-line engine into a network-accessible processing service.

After the April 2026 split, this layer exists as NodeODX at github.com/WebODM/NodeODX (the WebODM fork, paired with ODX) and NodeODM at github.com/OpenDroneMap/NodeODM (OpenDroneMap’s version, paired with ODM). The APIs are similar, but WebODM only guarantees compatibility with NodeODX, and the two projects’ Docker images and release cadences are independent. The rest of this article uses NodeODX since it’s what ships with WebODM.

You send images and processing parameters to NodeODX over HTTP. It queues the task, hands the images to the engine, monitors progress, and returns results when processing completes. That’s the entire job — accept tasks, manage the queue, expose status, serve outputs.

Why does this exist? Because WebODM needs something to talk to. WebODM doesn’t process images itself. It’s a web interface that sends tasks to one or more NodeODX instances running somewhere on your network. NodeODX is the translation layer between “user clicks a button” and “the engine crunches 2,000 photos into an orthomosaic.”

You can also hit the API directly with Python (via the PyODX library at github.com/WebODM/PyODX, or PyODM at github.com/OpenDroneMap/PyODM for the OpenDroneMap stack), with curl, or with any HTTP client. If you’re building automated processing pipelines — a drone lands, uploads images to a server, processing kicks off without human intervention — this layer is the integration point.

One NodeODX (or NodeODM) instance equals one processing node. Running many projects at once means running multiple nodes — which brings us to ClusterODX.

ClusterODX: The Load Balancer

ClusterODX — the WebODM fork at github.com/WebODM/ClusterODX, sibling to OpenDroneMap/ClusterODM, which targets NodeODM — solves a specific problem: you have more tasks than a single NodeODX instance can handle.

It’s a reverse proxy and load balancer that sits in front of multiple NodeODX nodes. Submit a task to ClusterODX, and it routes that task to whichever node has available capacity — factoring in queue size, image count limits, and slot availability.

For a solo operator processing one dataset at a time on a single machine, ClusterODX is irrelevant. For a firm processing dozens of datasets per week, or a university research lab with multiple students submitting jobs, ClusterODX is what turns a single-machine tool into a scalable processing service.

The autoscaling is the interesting part. ClusterODX can automatically spin up cloud nodes on DigitalOcean, AWS, Hetzner, or Scaleway when the queue fills up, and tear them down when processing finishes. You submit 15 datasets on Monday morning. ClusterODX spins up 10 cloud instances, distributes the work, and shuts them down when the queue empties. You pay for compute time, not idle servers.

It can also split large datasets across multiple nodes using ODX’s split-merge strategy (--split with --sm-cluster). A single 5,000-image project gets divided into submodels, each submodel processes on a different node, and the results merge back together. Point clouds, elevation models, and orthophotos merge; textured meshes don’t.

One constraint worth noting: ClusterODX always needs at least one static NodeODX node attached as a reference. You can’t rely entirely on autoscaled cloud nodes.

WebODM: The Interface Most People Actually Use

WebODM is the web application at the top of its stack, and it’s what many people still mean when they say “I use ODM.” Behind the scenes, WebODM talks to NodeODX, which runs the ODX engine. But from the user’s perspective, you upload images, set processing parameters, click “Start,” and wait.

The interface handles project management, task configuration, map visualization (with a built-in Leaflet viewer), 3D model viewing, measurement tools, and result downloads. It supports GCP files for georeferencing, lets you set processing options through dropdown menus instead of CLI flags, and provides progress monitoring during processing.

WebODM comes in two flavors:

Self-hosted (free). You install it on your own hardware: a native installer on Windows, an installer on macOS that sets up Docker for you, or Docker directly on Linux. You manage the machine, the storage, the RAM, the processing power. The software is free, installers included. The hardware is your problem. This is the version with roughly 4,200 GitHub stars and an active open-source community.

WebODM Lightning (paid cloud service). You upload images to cloud servers operated by UAV4GEO, the company behind WebODM. Processing happens on their infrastructure — specifically on LGT, a separate processing engine that’s only available on Lightning. Plans range from pay-as-you-go to $99/month billed yearly ($119 monthly) for the Business tier (unlimited maps, up to 3,000 images per map, 1,000 GB storage). The Starter plan runs $29/month ($24 billed annually) for 12 maps per 30 days. The Pro plan — the most popular — runs $42/month ($35 billed annually) for unlimited maps, up to 1,500 images per map, and 100 GB storage.

Lightning uses a different processing engine (LGT), and you’re not managing hardware, Docker, or Linux administration. You can also add Lightning as a processing node inside a self-hosted WebODM.

Why “X”? The April 2026 Naming Split

If you’ve made it this far and you’re still wondering what the X stands for: it’s the marker the WebODM organization adopted to distinguish its forks after WebODM became a separate project from OpenDroneMap in April 2026. ODM → ODX, NodeODM → NodeODX, ClusterODM → ClusterODX, PyODM → PyODX, CloudODM → CloudODX. Same layered architecture, separate projects.

The split is covered in detail in the WebODM splits from OpenDroneMap article. The short version: WebODM, led by its lead maintainer Piero Toffanin, became an independent project on April 6, 2026. OpenDroneMap continues developing ODM and NodeODM at github.com/OpenDroneMap; its ClusterODM, PyODM, and CloudODM repositories remain there but have had no commits since the split. The WebODM organization at github.com/WebODM maintains its own forks under the new names, including CloudODX, a command-line tool for processing aerial imagery in the cloud via NodeODX without the WebODM UI in the middle.

One thing catches people out: OpenDroneMap sells installers for forks of WebODM, called “WebUI” or “OpenDroneMap Desktop”. As WebODM’s own site puts it, those are not WebODM. They are not the same application, and their installers are not interchangeable. WebODM itself is downloaded free from webodm.org.

The two stacks today:

Practical guidance: if you install WebODM with its Windows or macOS installer, the webodm.sh script, or the official webodm/* Docker images, you’re getting the WebODM stack — ODX and NodeODX (plus ClusterODX if you add it). If you specifically pull opendronemap/* Docker images or build from github.com/OpenDroneMap/*, you’re on the OpenDroneMap stack. Don’t mix images across forks; Docker tag compatibility is no longer guaranteed.

How the Pieces Fit Together

The architecture is a stack. The minimal install (WebODM + NodeODX + ODX) is all most people need; ClusterODX and CloudODX only enter the picture for specific use cases.

(OpenDroneMap’s stack fills the same layers with ODM/NodeODM/ClusterODM/CloudODM, but it’s a separate project, and WebODM only guarantees compatibility with its own components.)

A minimal installation is WebODM + NodeODX + ODX on a single machine. That’s what the installers and the standard Docker setup give you. ClusterODX only enters the picture when you need horizontal scaling. CloudODX is for headless integrations — drone lands, images upload, CloudODX kicks off processing on a remote NodeODX node, results come back without ever opening a web UI.

For programmatic access without the web interface, you can hit NodeODX’s API directly using PyODX or raw HTTP requests. For maximum scale, you point WebODM at ClusterODX instead of a single NodeODX instance, and ClusterODX handles distribution across multiple NodeODX nodes — including auto-scaled cloud nodes spun up on demand.

The License: AGPL-3.0 and What It Means for You

WebODM, ODX, NodeODX, and ClusterODX are released under the GNU Affero General Public License v3.0 (AGPL-3.0), as are OpenDroneMap’s ODM, NodeODM, and ClusterODM. The client tools differ: PyODX is BSD-3-Clause and CloudODX is GPL-3.0. The AGPL matters more than most users realize.

If you’re processing your own drone data and delivering orthomosaics to clients: No issue. You’re using the software as a tool. AGPL doesn’t restrict the outputs — your maps, point clouds, and models are yours.

If you’re building a SaaS product that wraps WebODM or ODX: Pay attention. AGPL requires that if you modify the software and make it available to users over a network, you must release your source code under the same license. This is the “network copyleft” clause — it closes the SaaS loophole that standard GPL leaves open.

If you’re wondering about WebODM Lightning: Lightning is operated by UAV4GEO, the company of WebODM’s lead maintainer, Piero Toffanin. It’s a hosted service that runs its own processing engine (LGT), not a relicensed copy of WebODM. WebODM itself is AGPL-3.0, and it isn’t open-core or dual-licensed. Piero holds copyright on most of WebODM’s code as lead maintainer, and other contributors hold copyright on their own contributions.

To put it plainly: use the engine to process your own imagery, no strings attached. Modify it and offer it as a competing cloud service, and you’re sharing your modified code with the world. For 95 percent of drone operators, the license is a non-issue.

Hardware Requirements: The Real Numbers

WebODM’s official minimum is a 64-bit CPU (on Windows, one with SSE3/SSSE3 support), 8 GB RAM, and 20 GB of free disk space. That limits you to about 100 images. The recommended setup is 16 GB RAM or more and 100 GB of free disk.

Here’s what you actually need (the documentation’s conservative estimates):

CPU cores matter — ODX parallelizes aggressively. A 20-core machine processes a 1,000-image dataset significantly faster than a 4-core laptop. The relationship isn’t linear, but more cores reliably means faster processing.

GPU acceleration? ODX supports NVIDIA CUDA acceleration. In a Docker-based WebODM install (Linux or WSL), start it with ./webodm.sh start --gpu, which uses the webodm/nodeodx:gpu image; standalone ODX uses webodm/odx:gpu with --gpus all. On Windows, ODX enables GPU acceleration by default. It speeds up certain stages of the pipeline rather than all of them. GPU is worth enabling if you have compatible hardware, but don’t expect end-to-end processing times to halve.

Storage needs scale with image count and resolution. A 500-image DJI Mavic 3E dataset at 20 MP per image requires roughly 50-80 GB of working space during processing. Use NVMe SSDs. Processing on spinning hard drives is painful.

WebODM vs. the Commercial Alternatives

The question everyone asks: how does WebODM compare to Pix4D, Metashape, and the other photogrammetry platforms?

Accuracy. Published peer-reviewed comparisons of ODM (the engine ODX was forked from) are mixed. Pell et al. (2022) in Drones compared WebODM, Metashape, Pix4Dmapper, and Correlator3D across five datasets and found no single winner across all metrics. Mora-Félix et al. (2024) in Physica Scripta processed a 630 ha site in difficult terrain with 27 GCPs and called the ODM results “unsatisfactory”: deformations and high planimetric and altimetric errors in the orthomosaic and DEM. Agisoft PhotoScan (now Metashape) was the most accurate of the three packages tested. So don’t assume parity. Validate ODM output against independent checkpoints on your own data, and get GCP placement, overlap settings, and flight altitude right first — see drone survey accuracy fundamentals for the RMSE and checkpoint validation framework behind those numbers.

Processing speed. This depends heavily on hardware, settings, and dataset. WebODM’s maintainers describe its speed as comparable to or better than proprietary software; Metashape and RealityCapture lean heavily on GPU acceleration. If turnaround matters, benchmark a representative dataset on your own hardware before choosing.

Quality reporting. ODX generates a detailed quality report covering reprojection error, overlap maps, and camera calibration statistics. If you tag checkpoints in your GCP file, the report adds a separate Checkpoints table listing each checkpoint’s X, Y, and Z error, so you can check accuracy independently. That’s the paper trail clients and regulators ask for. Pix4D’s report is the long-standing industry reference, but ODX gives you the same core audit documentation.

GCP workflow. WebODM takes a GCP file (a coordinate-system header, then one line per observation: the point’s X Y Z, its pixel position, and the image name). It includes a built-in interface for marking points on images, and GCP Editor Pro is available as a commercial option. Points whose names start with CHK- are treated as checkpoints and used only to check accuracy.

Price. WebODM is free (self-hosted) or $24-99/month (Lightning, billed annually). Pix4Dmapper runs $332.50/month or $3,990/year annual subscription (as of 2026-04-22); perpetual licensing is no longer advertised. Metashape Professional is a $3,499 perpetual license. DroneDeploy starts at $349/month (Individual tier, billed annually). The cost difference is significant, especially for small operations or academic users.

Who Should Use WebODM — and Who Shouldn’t

WebODM makes sense for:

• Budget-constrained operators. Startup drone companies, academic researchers, and international NGOs where software licensing is a real barrier.
• Pipeline builders. If you’re automating processing — drone lands, images upload, processing starts, outputs push to a GIS server — NodeODX’s REST API is purpose-built for this. No other platform makes programmatic integration this straightforward.
• Learning the craft. Processing your first few hundred datasets? Use the free tool. Understand what every parameter does. Graduate to commercial software if you outgrow it.
• Linux and server environments. WebODM runs on Linux servers via Docker. If your processing infrastructure is server-based, it fits without the Windows licensing overhead.

WebODM is the wrong choice for:

• High-volume production you haven’t benchmarked. If you’re processing 20 datasets per week and turnaround matters, test a representative dataset on WebODM and on the commercial tool you’re considering before committing either way.
• Operators who don’t want to manage infrastructure. Self-hosted WebODM means managing a machine — an installer on Windows or macOS, Docker on Linux servers — plus storage management and troubleshooting. If that sounds like overhead you don’t want, WebODM Lightning or a fully managed platform like DroneDeploy is more appropriate.

Getting Started: The Practical Path

If you’re new to WebODM, here’s the shortest path to a working installation:

1. Windows or macOS: download the free installer from webodm.org/download and run it.
2. Linux: install Docker, clone the WebODM repository from GitHub, and run ./webodm.sh start. Then open a browser to localhost:8000.

Either route gives you WebODM, NodeODX, and ODX on one machine.

For your first test, use a small dataset — 40 to 100 images. Default processing settings. See what the outputs look like. Then start adjusting parameters: resolution, feature quality, mesh settings. The documentation at docs.webodm.org covers every parameter.

If self-hosting isn’t your thing, WebODM Lightning lets you start processing immediately with 150 free credits — no installation required.

WebODM and OpenDroneMap are now two separate projects, each with its own stack. Whichever you land on, the architecture is layered the same way: the engine (ODX or ODM) processes images, the API layer (NodeODX or NodeODM) manages tasks, the load balancer (ClusterODX or ClusterODM) distributes load across nodes, and a web interface sits on top — WebODM on one side, OpenDroneMap’s WebODM forks on the other.

The ecosystem is free, open-source, and genuinely capable. Either fork produces accurate orthomosaics, point clouds, and elevation models when fed well-executed flights with proper ground control. For operators who need a capable processing pipeline without a $300–350/month subscription, this is the most credible open-source option available.

Know the components. Pick the stack that matches your install (WebODM installers, webodm.sh, or webodm/* images → WebODM stack; opendronemap/* Docker images → OpenDroneMap stack). And stop calling everything “ODM” — now you know the difference.

References

Research and standards cited in this article.

• Mora-Félix, Z. D., et al. (2024). Performance and precision analysis of 3D surface modeling through UAVs: Validation and comparison of different photogrammetric data processing software. Physica Scripta, 99(3), 035017. doi:10.1088/1402-4896/ad23ab
• Pell, T., Li, J. Y. Q., & Joyce, K. E. (2022). Demystifying the differences between structure-from-motion software packages for pre-processing drone data. Drones, 6(1), 24. doi:10.3390/drones6010024