Skip to main content

Deploying ESP RainMaker Neo

ESP RainMaker Neo runs in your own AWS account. This page explains what a deployment consists of, the two ways to create one, and what you own once it exists. It is written for whoever will hold the AWS account.

Deploy With Installer

The no-toolchain route: install one small stack, then pick a version and modules from its dashboard.

Deploy from Source

The AWS CDK route, with its prerequisites — for modifying the backend or running it from your own CI.

Deployment Details

The client-outputs JSON and QR code your app and tooling need, and which values matter.

Post-Deployment Configuration

Sign in as an administrator, then voice assistants, push notifications and optional node capabilities.


Start here instead

If you want a deployment running today, follow Deploy With Installer — it takes you from an empty AWS account to a live deployment, then Deployment Details and Post-Deployment Configuration get it ready to use. Come back to this page when you need the shape of the system rather than the commands.

One deployment model​

A private deployment is a set of CloudFormation stacks in an AWS account you control, in a region you choose. Your devices connect to your AWS IoT Core endpoint, your users live in your Cognito user pools, and your data stays in your DynamoDB tables. This page is about standing one up.

There is also a public ESP RainMaker Neo deployment you can sign up for, intended for evaluation and hobbyist use. If you only want to try the platform, start there instead — see Get Started — and come back here when you need your own region, data residency, upgrade schedule and limits.

What gets created​

The ESP RainMaker Neo package: ESP RainMaker Neo Identity deploys first and hands its pool IDs to ESP RainMaker Neo, with Voice Assistants and the optional Assisted Claiming alongside; the paid Enterprise Plan modules sit below

Everything in the package is installed for you except Assisted Claiming, which you choose to add.

Here every base stack holds Storage (DynamoDB tables, S3 buckets, IoT policies and role aliases, the identity pool, the REST API), every core stack holds the compute (Go Lambdas, API Gateway methods, IoT topic rules, SQS queues, an ECS Fargate task for bulk registration). This decoupling helps you delete the core stacks without losing your data.

Enterprise modules

The Enterprise modules are not part of the open-source package; email us at esp-rainmaker-support@espressif.com if you need them.

What you take on​

Running Neo in your own account means you own:

  • The AWS bill and the account — including quotas, service limits, and any support plan.
  • Admin credentials. The one-time admin password arrives as a CloudFormation output; you can replace it on first sign-in.
  • Upgrades. New Neo releases are published as new template versions; you decide when to move. Downgrades are blocked.
  • Monitoring. CloudWatch log groups exist for every Lambda and for the IoT rule error paths, but no alarms, dashboards or notification topics are created for you.

About cost​

Neo is built almost entirely from per-request AWS services: Lambda, API Gateway, DynamoDB, AWS IoT Core, S3, CloudFront, SQS. There are no always-on instances, so an idle deployment costs little beyond the data it stores. The continuous charges are the inherently continuous things — stored device and time-series data, CloudWatch logs, and the CloudFront distribution. Beyond that, cost tracks device count, message rate, and how much history you keep.