Skip to main content
Processing & Software

Why Move WebODM to the Cloud? (And When Not To)

WebODM cloud vs local: AWS spot costs (~$2-5/job), egress surprises, decision framework for when cloud wins vs when your workstation is better.

Eric By — M.S. Geography (GIS spec.), FAA Part 107
Updated October 24, 2026
Why Move WebODM to the Cloud? (And When Not To)

Updated October 2026: This article has been corrected. WebODM is a separate project from OpenDroneMap and runs its own engine, ODX, whether you host it on a workstation or on AWS; NodeODX is WebODM’s fork of NodeODM, not a rename of it. We also replaced an unsourced GPU speedup claim with what ODX actually documents: NVIDIA CUDA support.

You get the AWS bill. Compute: $4.12. Storage: $0.87. Data transfer: $14.60.

Wait — the transfer costs more than the processing? Yes. And that’s the first thing every guide gets wrong about running WebODM in the cloud. They talk about instance types and Docker configurations. They never mention that downloading your own orthomosaic is the most expensive part of the job.

WebODM runs equally well on a $600 refurbished workstation and on a fleet of AWS spot instances. Both work. Neither is universally better. The decision comes down to dataset size, team structure, and how often data actually gets processed.

Here’s the decision framework.

Local workstation vs cloud server: split-screen comparison showing hardware costs, egress fees, and data flow between local and AWS processing


The Real Cost of Local Processing

Local processing means a dedicated workstation sitting under your desk or in a closet. For WebODM to handle serious datasets — 1,000 to 5,000 images at 20 megapixels — you need real hardware.

Minimum specs for production work:

Component500 images1,000 images5,000 images
RAM32 GB64 GB128–256 GB
CPU8 cores16 cores20+ cores
Storage500 GB SSD1 TB NVMe2+ TB NVMe
Processing time1–2 hours3–6 hours12–48 hours

A workstation that handles 1,000-image datasets costs $2,500 to $4,000. One that reliably processes 5,000 images without crashing or swapping to disk runs $5,000 to $8,000. Add a CUDA-compatible GPU and you’re looking at another $500 to $2,000 — ODX, WebODM’s engine, supports NVIDIA CUDA acceleration (./webodm.sh start --gpu or the webodm/odx:gpu image on Linux; Windows builds include it by default). Nobody publishes how much time it saves on which stages, so benchmark it on your own data before you budget for it.

That sounds expensive. It is — upfront. But the machine sits there, amortizing. Process 200 jobs over three years and your per-job cost drops below $20. No internet upload required. No egress fees. No waiting for a spot instance to become available.

The catch: your workstation is a single point of failure. It processes one job at a time. If you’re running a 5,000-image dataset, that machine is unavailable for 12 to 48 hours. Your team can’t process anything else while it’s grinding.


The Real Cost of Cloud Processing

Cloud processing on AWS means spinning up an EC2 instance, running WebODM or NodeODX (WebODM’s fork of NodeODM, which continues separately under OpenDroneMap) in Docker, processing your dataset, downloading the results, and terminating the instance. You pay only for the hours the machine runs.

Here’s what that actually costs using spot instances in us-east-2 (Ohio — typically the cheapest region). Spot prices were checked October 23, 2026, and they move:

Spot instance pricing for photogrammetry workloads:

Dataset sizeInstance typeRAMSpot price/hrProcessing timeCompute cost
500 imagesm5.xlarge16 GB~$0.0381–2 hours$0.04–$0.08
1,000 imagesm5.2xlarge32 GB~$0.0742–4 hours$0.15–$0.30
2,500 imagesr5.2xlarge64 GB~$0.1284–8 hours$0.51–$1.02
5,000 imagesr5.4xlarge128 GB~$0.2828–16 hours$2.26–$4.51

ClusterODX — the WebODM reverse-proxy/load-balancer fork targeting NodeODX (ClusterODM continues separately under OpenDroneMap for NodeODM users) — automates this. It selects the least powerful instance that can handle your image count, spins it up as a spot instance, processes the job, and terminates it. The configuration maps image counts to instance types automatically.

The RAM sizes in that table follow the sample imageSizeMapping in ClusterODX’s AWS docs. WebODM’s own installation docs are more conservative — about double: 32 GB for 500 images, 128 GB for 2,500, 256 GB for 5,000 (RAM or RAM + swap). If a job runs out of memory, step up an instance size or use ClusterODX’s addSwap option.

Compute is cheap. A 1,000-image job costs $0.15 to $0.30 in spot compute. Round it up to a dollar with overhead. That’s less than a cup of coffee.

Now add the costs nobody talks about.


Where the Money Actually Goes

Storage (S3): Your raw images need to live somewhere during processing. A 1,000-image dataset at 20 megapixels runs about 15 to 20 GB. S3 Standard storage costs $0.023 per GB per month. Storing 20 GB for a week costs roughly $0.10. Negligible.

But your outputs — orthomosaics, point clouds, DSMs, 3D models — add up. A full processing run can produce 30 to 50 GB of outputs. Store 10 projects and you’re at 300 to 500 GB, costing $7 to $12 per month. Leave old projects sitting in S3 Standard for a year and you’ve spent about $83 to $138 on storage alone.

Data transfer (egress): This is the line item that surprises people. AWS charges $0.09 per GB for data leaving their network. Download a 40 GB orthomosaic and point cloud from a single job: $3.60. Process 10 jobs a month and download everything: 400 GB. The first 100 GB per month is free across all AWS services, which helps, but you still pay for the other 300 GB — $27 in transfer fees alone. If you’re doing serious production work, you blow through the free allowance fast.

Upload costs: Free. AWS never charges for ingress. Uploading 20 GB of drone images costs nothing except your time and bandwidth.

The real per-job cost breakdown for a 1,000-image dataset:

Cost componentAmount
Compute (spot)$0.15–$0.30
Storage (temporary)~$0.10
Egress (downloading results)$2.00–$4.00
Total per job$2.25–$4.40

These per-job figures leave out AWS’s 100 GB monthly free egress allowance, so a light month costs less. Storage dominates over time. Egress dominates per job. Compute — the thing everyone optimizes for — is the cheapest part.

Cost breakdown chart: compute is cheap at $0.15–$0.30, storage is about a dime, but egress at $2–$4 dominates the per-job cost for cloud photogrammetry


When Cloud Wins

Large datasets you process occasionally. If you run a 5,000-image job once a month, the cloud saves you from buying a $7,000 workstation that sits idle 29 days out of 30. Spot compute for that job runs about $2.25 to $4.50; with egress on the bigger outputs, call it $5 to $20 a job. You’d need to process 350 to 1,400 jobs to break even on the hardware. That’s 29 to 117 years of monthly processing.

No workstation available. You’re a solo operator running WebODM on a laptop with 16 GB of RAM. WebODM’s docs put 16 GB at about 250 images, so bigger jobs run out of memory. Spinning up an r5.2xlarge with 64 GB for two hours costs about $0.26 in spot compute and processes 1,000 images without breaking a sweat.

Team access. Three operators need to submit jobs simultaneously. A single workstation queues them serially — person two waits for person one to finish. ClusterODX on AWS spins up parallel nodes. Three jobs run at once. Total wall-clock time drops by two-thirds.

Burst capacity. End-of-quarter rush. You have 15 datasets to process in three days. Your workstation handles one at a time, 4 hours each — that’s 60 hours, almost three straight days with no interruptions. ClusterODX processes all 15 in parallel. Total time: 4 hours. Spot compute: under $10 (15 × 4 hours × $0.128 for r5.2xlarge is $7.68), plus egress for the results.


When Cloud Doesn’t Win

Small, frequent jobs. If you process 200 to 500 images twice a week, a $3,000 workstation doesn’t win on cost — at about 100 jobs a year it takes seven to thirteen years to reach the 700-to-1,300-job break-even point. It wins on turnaround: it eliminates the upload-download cycle entirely. Processing locally takes 1 to 2 hours. Uploading 10 GB, processing, and downloading 20 GB of results takes longer and costs more per job when you factor in your time.

Upload bandwidth is the bottleneck. Rural office with 10 Mbps upload? Pushing 20 GB of raw images to AWS takes 4.5 hours. The cloud instance processes the job in 2 hours. You spent more time uploading than processing. That math never works.

Data sovereignty requirements. Government contracts, ITAR-controlled imagery, or clients who contractually require data to stay on-premises. AWS GovCloud exists for ITAR compliance, but it’s more expensive and more complex to configure. If your client says “our data doesn’t leave our network,” the conversation is over. Process locally.

Latency-sensitive workflows. You need to QC the orthomosaic, adjust parameters, and reprocess — iterating three or four times on the same dataset. Each iteration means another upload-download cycle. Local processing gives you instant access to intermediate results. Cloud processing adds 30 to 60 minutes of transfer overhead per iteration.

You already own the hardware. If you have a workstation with 128 GB of RAM sitting under your desk, the marginal cost of processing another job is electricity. Roughly $0.30 to $1.00 for a 6-hour run, depending on how much power the machine draws. No cloud service beats that.

Cloud vs local decision matrix: four scenarios where cloud wins (large infrequent datasets, limited local hardware, team access, burst periods) vs four where local wins (small frequent jobs, slow upload, data sovereignty, hardware you already own); self-hosted, both run the same ODX engine, while WebODM Lightning runs LGT


How Cloud Compares to DroneDeploy and Pix4D Cloud

Running your own WebODM on AWS isn’t the only cloud option. DroneDeploy starts at $349 per month — $4,188 per year. Pix4D Cloud starts at $49 per month — $588 per year for the basic tier, $2,988 per year for Advanced.

WebODM on AWS at about $2.25 to $4.40 per job, processing 10 jobs per month, runs about $270 to $530 per year before the 100 GB monthly free egress allowance. Comparable to Pix4D Cloud’s entry tier. Roughly one-eighth to one-sixteenth the cost of DroneDeploy.

The tradeoff: DroneDeploy and Pix4D handle everything — upload, process, host, share. You manage nothing. WebODM on AWS means you manage the infrastructure: Docker, EC2, S3 buckets, security groups, IAM roles. You own the pipeline, but you maintain it.

PlatformAnnual cost (10 jobs/mo)You manageProcessing control
DroneDeploy~$4,188NothingLimited parameters
Pix4D Cloud (Advanced)~$2,988NothingModerate parameters
WebODM on AWS~$270–$530EverythingFull control
WebODM local~$0 (amortized)HardwareFull control

If you want full control over processing parameters — and if you’re reading this, you probably do — the self-hosted options are the only game in town. The question is whether you host on your desk or in someone else’s data center.


The Setup Isn’t Trivial (But It’s Not Hard)

Running WebODM on a single EC2 instance takes about 30 minutes of setup if you know Docker. Launch an Ubuntu instance, install Docker and docker-compose, clone the WebODM repo, run ./webodm.sh start. The WebODM documentation covers this step by step.

ClusterODX for auto-scaling is more involved. You need an S3 bucket, a VPC with proper security groups, an IAM role for EC2 and S3 access, and a configuration file mapping image counts to instance types. Budget 2 to 4 hours for initial setup, including testing. After that, it’s hands-off — submit a job through the WebODM interface and ClusterODX handles the rest.

The real complexity is operational: monitoring spot instance interruptions, managing S3 lifecycle policies so old data doesn’t accumulate, and securing your instance against open-port exposure. Not rocket science, but not click-and-deploy either.

To put it plainly: if you’re comfortable with Docker and basic AWS console navigation, you can do this. If “security group” sounds like a therapy session, consider Pix4D Cloud until you’re ready.


The Decision Framework

Run through these questions in order. The first “yes” gives you your answer.

  1. Is your data subject to sovereignty or ITAR restrictions? Process locally.
  2. Do you already own a workstation with 64+ GB RAM? Process locally unless you need parallel capacity.
  3. Is your upload speed under 50 Mbps? Process locally — transfer overhead kills the cloud advantage.
  4. Do you process more than 1,000 images per job regularly? Cloud wins on cost per job.
  5. Do multiple team members need simultaneous processing? Cloud wins on parallelism.
  6. Do you have burst periods with 10+ jobs in a week? Cloud wins on elasticity.
  7. None of the above? Either works. Local is simpler. Cloud scales better.

Decision flowchart: six questions in order (data sovereignty or ITAR, owning a 64+ GB workstation, upload under 50 Mbps → process locally; 1,000+ images per job, simultaneous team processing, 10+ job bursts → use cloud)


Cloud processing on AWS costs about $2.25 to $4.40 per job for typical 1,000-image datasets when you use spot instances. Most of that cost is egress — downloading your own results — not compute. A $3,000 workstation breaks even against cloud at roughly 700 to 1,300 jobs, depending on dataset size.

The cloud wins for large infrequent jobs, team access, and burst capacity. Local wins for small frequent jobs, slow internet, and data sovereignty. Both produce identical outputs — it’s the same ODX engine either way. (WebODM Lightning, UAV4GEO’s hosted service, is a different case: it runs its own engine, LGT, which is only available there, so the same-engine point doesn’t apply to it.)

The guides that tell you cloud is always cheaper are wrong. The guides that tell you local is always better are also wrong. The answer depends on your dataset size, your processing frequency, your upload speed, and your tolerance for managing AWS infrastructure.

Run the numbers for your operation. The math is straightforward. The answer is yours.

Eric

Written by Eric

M.S. Geography (GIS specialization) from St. Cloud State University, FAA Part 107. Pacific Northwest-based; active public-sector Blue UAS operator. Geospatial background covering spatial data, remote sensing, and coordinate systems — applied to drone mapping workflows and deliverables.

About Eric →