SimpleOTA
All posts
6 min read

ArduinoOTA vs managed ESP32 fleet OTA: when local Wi-Fi updates no longer reach the boards in the field

ArduinoOTA updates ESP32 boards over your local Wi-Fi, while managed fleet OTA adds HTTPS delivery, build tracking, and canary rollouts for devices that have left that network.

ArduinoOTA (the ArduinoOTA.h library in the ESP32 Arduino core) updates a board over local Wi-Fi, usually finding it with mDNS, which means your computer and the device have to sit on the same LAN. That works well in a lab or for one board on your desk, but it does not deliver firmware over the internet, track the build each field device is running, or stage a fleet rollout. With managed fleet OTA, as provided by SimpleOTA, devices pull updates over HTTPS from wherever they have network access, and they start by sending their current build number to a check endpoint. If the device is eligible, that endpoint returns a short-lived pre-signed download URL, the board installs the update into the inactive OTA partition, and it reports the result. ArduinoOTA is the one to keep while you are still iterating on the bench, and managed OTA fits once devices leave your network or you need version history and canary rollouts. It also fits when a laptop with the right development environment is no longer a workable way to ship a release.

Side-by-side comparison

Both tools install firmware on an ESP32, and the real difference is where that update can happen and what you can still see after it lands.

ArduinoOTA (local) Managed fleet OTA (SimpleOTA)
Network scope Same LAN (usually found via mDNS) Anywhere the device has HTTPS access
Push vs pull Push from a computer on the LAN Device pulls: check → decide → download
Version tracking No fleet build inventory Monotonic build numbers and device check-ins
Canary / audit No staged exposure or deployment history Deployments with percentage cohorts, pause, and outcome counters
Signing Not a managed signing workflow Optional signed mode with on-device verification
Rollback Dual OTA partitions exist; no managed trial/confirm reporting Trial install with confirm timeout; outcomes visible on the deployment

ArduinoOTA stays a good fit when you want a quick update at your desk, and managed OTA is what you reach for once the same update has to leave the workshop.

What ArduinoOTA is good at

ArduinoOTA works well when you and the board share a network and you want to iterate quickly. You flash once over USB, leave the board powered on the bench, and push later sketches without reconnecting the cable. Workshops, classroom kits, and early prototypes benefit from that local workflow, since there is no account to create, no token to embed, and no external service while you change pin maps and sensor drivers. For one unit on your desk, that may be all you need, because you know which binary you sent, you can watch Serial as it boots, and reflash from the IDE if it goes wrong. Because the library is part of the ESP32 Arduino core, setup stays simple and the feedback stays quick.

What breaks in the field

The same-LAN requirement becomes a problem when a board leaves the lab, because a device at a customer site, inside a sealed enclosure, or on another VLAN cannot receive a push from your laptop. mDNS discovery does not work across the internet, and ArduinoOTA provides no shared inventory of the builds running on your devices. Answering whether every pilot site is on last Tuesday’s release may mean visiting each site or asking an operator to check Serial. ArduinoOTA also has no way to offer a build to five percent of a fleet, watch the confirmations, and then widen the rollout. Without deployment history there is no audit trail showing which devices received an update or whether installation succeeded. ArduinoOTA remains useful for the desk, and the task has changed once you are releasing firmware to devices you cannot reach directly.

How managed pull OTA works

With managed pull OTA, devices initiate contact, and each ESP32 periodically sends its current build number to a check endpoint so the control plane can decide whether that device is eligible for a newer artifact. The control plane checks eligibility from compatibility, audience, and rollout cohort, and if the device qualifies, the endpoint returns a short-lived pre-signed URL that points at the artifact in object storage. The device then downloads the binary over HTTPS, writes it to the inactive OTA partition, reboots, and reports the result. SimpleOTA decides eligibility and provides the URL, and the firmware bytes go directly from object storage to the device.

On Arduino, SimpleOTAClient handles polling, downloading, verification, rebooting, and trial-install rollback in a few lines of sketch code. A deployment assigns an uploaded artifact to device groups or release channels at a rollout percentage you choose. You can start with a canary, watch the offered, confirmed, failed, and rolled-back counts, and then raise that percentage without reshuffling the devices that were already included. For the full path from a first USB flash to an HTTPS update, follow the Arduino blog guide and the wiki’s first deployment walkthrough.

A short note on Arduino Cloud OTA

Arduino Cloud OTA is a separate product from ArduinoOTA.h, and it delivers firmware over the internet through object storage. You compile and upload through the Arduino Cloud editor, and you enroll devices as connected Things. You cannot upload a binary that was built with PlatformIO, ESP-IDF, or an arbitrary CI pipeline. SimpleOTA works with those build systems, so you compile with PlatformIO, ESP-IDF, the Arduino IDE, or CI, then upload the .bin and deploy it. SimpleOTA does not require an IoT variable system, and the product stays focused on firmware delivery rather than a cloud sketch environment. Arduino Cloud may suit teams that already use it for their full workflow, and if you want to keep your existing toolchain and add fleet OTA, SimpleOTA accepts binaries built with that toolchain.

When to keep both

You can keep both, with ArduinoOTA in lab and development sketches where a same-LAN push is how you try a change, and SimpleOTAClient on production images so field devices check in over HTTPS. The lab path stays local while you are debugging, and the production path picks up build ordering, canary rollouts, and a deployment audit trail once the boards leave the building. That choice follows your release process and where those devices actually run, including whether you can still reach them from the same Wi-Fi network.

Next steps

If you are still on the bench and you only need same-LAN updates, ArduinoOTA remains a good fit for that work. When you are ready for managed pull OTA, start with the complete Arduino guide, install the client from the Arduino wiki guide, and follow the first deployment walkthrough. That walkthrough is where you can see check-ins, rollout percentages, and outcome counts show up in practice. The deployments concept page explains how deployments, audiences, and rollout cohorts fit together, and the product overview and FAQ live on simpleota.com.