ESP OTA Updates: Ship Once, Update Forever

The day you ship a product without OTA updates is the day you commit to never fixing bugs or adding features without physically retrieving every device. That's fine for a breadboard. It's a business problem at any scale. Here's how OTA works on ESP, from the simplest version to what production systems need.

How OTA Works Under the Hood

The ESP's flash is divided into partitions defined by a CSV file. For OTA, you need at least two app partitions: ota_0 and ota_1. Your current running firmware resides in one of them. During an OTA update, the new firmware writes to the other, the inactive one. When writing is complete and the SHA256 hash verifies, the bootloader checks it on reboot, and the device restarts into the new firmware.**

If the new firmware fails to boot correctly, for example if it crashes repeatedly or never calls esp_ota_mark_app_valid_cancel_rollback(), the bootloader automatically marks the update as invalid and reverts to the previous working firmware on the next power cycle. This rollback mechanism prevents bricks and is a critical production safety net.

Three OTA Methods, Pick Your Level

ArduinoOTA, for development

Install the library, add four lines to setup(), and your board appears in the Arduino IDE port list over the network. Upload new firmware exactly like USB over Wi-Fi. No authentication by default, so add a password at minimum. Not for production, but for rapid development iteration it is extremely convenient.

HTTP OTA, the production standard

Your device polls an HTTPS endpoint every N hours, or on command from the server. The endpoint returns either a 304 Not Modified response, meaning nothing to update, or a new firmware binary. The device downloads it to the inactive partition, verifies integrity, optionally checks signature, then reboots. ESP-IDF's esp_https_ota() handles most of this in a few lines of code.