Over-the-Air Updates for ESP32 — Doing It Right in Production

Over-the-air (OTA) firmware updates are one of the most practically valuable features you can add to an IoT deployment. Once devices are distributed — installed in homes, deployed in fields, or inside machinery — physical access for firmware updates is expensive or impossible. OTA removes that constraint: push a new firmware from your laptop or a CI pipeline, and all your devices update automatically.

The ESP32 makes OTA reasonably straightforward. The Arduino framework includes an ArduinoOTA library for simple cases; the ESP-IDF provides a more complete OTA API for production use. But "reasonably straightforward" hides real complexity: OTA done wrong can brick deployed devices in ways that are very hard to recover from.

The partition scheme

OTA on the ESP32 works via a dual-partition scheme. The flash memory is divided into (at minimum) two application partitions (ota_0 and ota_1) and an OTA data partition that tracks which application partition is active.

When an OTA update is received, the new firmware is written to the inactive partition. Once writing and verification are complete, the OTA data partition is updated to mark the new partition as active, and the device reboots. On the next boot, the bootloader reads the OTA data partition and boots from the newly active application.

If anything goes wrong during the update (power loss, download interruption), the original partition is still intact and the device boots from it. This is the key safety property: OTA writes to a separate partition, not over the running code.

The rollback requirement

The dual-partition scheme protects against interrupted downloads. It does not protect against a new firmware that boots successfully but has a bug that prevents the device from functioning correctly (connects to WiFi but then crashes, can't reach the update server, etc.).

For production, implement application-verified rollback:

After each OTA update, the new firmware must actively mark itself as valid. In ESP-IDF: esp_ota_mark_app_valid_cancel_rollback(). If the new firmware doesn't call this (because it crashed or couldn't complete its startup), the bootloader will automatically roll back to the previous firmware on the next boot.

In Arduino: the Update.apply() approach doesn't have this built-in, but you can implement it by storing a "validated" flag in NVS (non-volatile storage) after successful startup, and reverting the partition if the flag isn't set.

Without rollback: a bad firmware update can leave all your deployed devices non-functional and non-recoverable over OTA. With rollback: a bad update auto-reverts and devices come back online.

Transport security

Never serve firmware updates over plain HTTP. Anyone who can intercept the download can replace your firmware with arbitrary code. Use HTTPS, or at minimum, verify the firmware image signature before applying.

The ESP-IDF secure boot and flash encryption features provide hardware-backed security for sensitive deployments. These add complexity but are appropriate if the device has access to sensitive infrastructure.

For simpler deployments: HTTPS download from a server you control, with a checksum or signature verification before applying, is a reasonable minimum.

Update server infrastructure

For a few devices: a simple HTTPS endpoint that serves the firmware binary and a version JSON file works fine. The device checks the version endpoint periodically, compares to its current version, and downloads if newer.

For larger deployments: consider a proper IoT management platform that handles fleet OTA with rollout control (canary releases, staged rollout), rollback management, and update status tracking. AWS IoT Jobs, Azure IoT Hub, or self-hosted solutions like Mender.io are options.

The version comparison and rollout strategy matter at scale. Don't push a new firmware to all devices simultaneously — push to a test group first, verify, then expand.