ESP RainMaker Neo changes an important part of Espressif’s IoT platform story: the cloud backend is now open source, not only the device and application layers. For teams building connected ESP products, that means the complete device-to-cloud-to-app stack can be inspected, customized and deployed in the team’s own AWS account.
Espressif announced the open-source release on August 5, 2026. The Neo backend is released under the Apache License 2.0 and is a new implementation rather than a drop-in update for ESP RainMaker Classic.
What is actually open source?
According to Espressif, RainMaker Neo makes the complete implementation available across the cloud backend, device firmware, mobile application stack and dashboard. The cloud specifications describe an AWS serverless architecture using services including AWS IoT Core, Lambda, DynamoDB, Cognito and related AWS infrastructure.
This matters because a product team can audit the backend behavior, deploy it into its own AWS account, integrate company systems, modify platform behavior and operate the infrastructure without depending on a closed RainMaker backend implementation.
Neo is not RainMaker Classic with a new name
This distinction is critical. Espressif states that RainMaker Neo is a new implementation with a different cloud architecture. Existing RainMaker Classic deployments cannot be directly migrated to Neo and the platforms are not deployment-compatible.
For a new product, Neo is the platform Espressif recommends evaluating. Existing Classic products can remain on Classic, which Espressif says continues to be supported. Do not plan a production migration on the assumption that an existing Classic deployment can simply point to a Neo backend.
Why Espressif rebuilt the cloud architecture
Neo relies more directly on native AWS IoT capabilities. Espressif specifically describes use of services such as Device Shadow, Thing Groups and AWS IoT OTA, with IAM-level access control for user and device permissions.
The engineering benefit is not merely “open source.” A more AWS-native architecture can reduce the amount of RainMaker-specific infrastructure a team must understand and maintain. The trade-off is that operating Neo still requires real cloud engineering knowledge: IAM, AWS costs, observability, deployment, backups, quotas and security remain your responsibility when you self-host.
What the device side looks like
The RainMaker Neo Firmware SDK provides the libraries required for a device to operate as a Neo node. Espressif documents the boot and initialization flow, configuration and state payloads, MQTT topics, cloud events, services, OTA and error recovery.
The current Neo documentation specifies ESP-IDF support and also provides a POSIX host target for testing. That host target is useful for CI and automated testing because some protocol and application behavior can be exercised without physical hardware.
MQTT, REST and device state
Devices connect through AWS IoT using MQTT, while applications and backend components can use REST and MQTT interfaces. Neo’s cloud specifications document identity, node association, groups, time-series data, notifications and other contracts.
For example, the time-series design uses MQTT as the device data ingress, then AWS services process and store raw and aggregated measurements. This is the kind of implementation detail that becomes auditable when the backend and its specifications are available.
If you are still deciding how your own ESP32 application should communicate with a backend, read our MQTT vs HTTP vs WebSockets on ESP32 comparison.
Matter support
Espressif positions RainMaker Neo as a platform with Matter support across device, mobile app and cloud. ESP-Matter handles Matter-enabled device development, while RainMaker mobile components support commissioning and control. Neo also provides cloud-side Matter Fabric capabilities for remote interaction with devices on the RainMaker Matter Fabric.
That can be useful for connected-home products that need both local Matter interoperability and remote cloud features, but teams should validate the exact Matter features and certification requirements for their product rather than treating “Matter support” as a substitute for a certification plan.
What open source does not remove
- AWS cost: the software being open source does not make the underlying cloud services free.
- Operations: someone still owns monitoring, incident response, backups, quotas and deployment changes.
- Security: IAM policies, device credentials, user identity and update security require careful configuration.
- Migration work: Classic and Neo are not directly deployment-compatible.
- Product testing: modifying the backend creates a responsibility to validate compatibility across firmware, apps and APIs.
When RainMaker Neo is worth evaluating
Neo is particularly relevant when you are building a commercial ESP-based connected product and want control over the cloud implementation and data while avoiding a completely greenfield IoT backend. It is also attractive when AWS is already part of your infrastructure and your team can operate serverless AWS services.
A smaller prototype that only sends a few measurements to an existing API may not need a complete IoT platform. Architecture should follow the product requirements, not the number of features available in the platform.
A sensible evaluation plan
- Build one supported device example and verify provisioning and control.
- Deploy a test Neo backend in a non-production AWS account.
- Inspect device identity, credentials and user-device association.
- Test telemetry, commands, offline recovery and OTA behavior.
- Measure AWS resource usage with realistic device traffic.
- Review IAM policies and credential lifecycle with your security requirements.
- Test the mobile application flow you actually intend to ship.
- Document which upstream components you will customize and how you will maintain those changes.
Related reliability work
A cloud platform cannot compensate for firmware that fails whenever connectivity disappears. For the device side, use an offline-first ESP32 cloud architecture and test ESP32 Wi-Fi recovery before treating the product as production-ready.
Primary references
- Espressif: Open Sourcing ESP RainMaker Neo
- ESP RainMaker Neo Cloud Specifications
- ESP RainMaker Neo Firmware Programming Guide
Bottom line
RainMaker Neo gives ESP product teams something materially different from Classic: an open-source cloud backend plus the surrounding device and application stack, deployable in the team’s own AWS account. That increases control and auditability, but it also makes cloud operations and security explicitly your responsibility. For new commercial ESP IoT products, it is worth evaluating as a platform—not treating as a zero-effort cloud service.