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.

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.

Which one you want comes down to whether you need your own region, data residency, upgrade schedule and limits.

Two ways to deploy​

Cloud Installer. Espressif publishes each Neo release as versioned, region-agnostic CloudFormation templates. You install one small stack — the installer — and then use its web dashboard to pick a version, pick modules, fill in parameters, and deploy. No local toolchain, no CDK, no Go build. This is the route most customers take. See Deploy With Installer.

From source. You clone the backend repository and deploy with AWS CDK: make setup once to bootstrap CDK for the account and region, then make deploy for each build. Choose this if you intend to modify the backend, or want the deployment under your own CI. See Deploy from Source.

Both routes produce the same stacks. The difference is who synthesises the templates and how operator inputs arrive: a source deploy resolves them from environment variables and rmng-inputs.json at synth time, while a published template exposes them as CloudFormation stack parameters you fill in at deploy time. The mechanics are in the deploy and publish spec.

What gets created​

Stacks are grouped, and the groups deploy in dependency order — espuser first, then rmng, then the optional alexa group.

GroupStacksProvides
espuserespuser-base, espuser-coreIdentity and accounts
rmngrmng-base, rmng-core, rmng-admin-dashboardThe IoT cloud and its dashboard
alexarmng-alexa-coreAlexa skill endpoints (optional)

espuser is a standalone identity system with two Cognito user pools: one for end users, one for admins. It deploys first because the rmng group reads its pool IDs.

Within the rmng group, the split is by lifecycle rather than by feature:

  • rmng-base holds the stateful resources — DynamoDB tables, S3 buckets, the AWS IoT Core policies and role aliases nodes authenticate against, the Cognito identity pool that issues temporary AWS credentials, and the API Gateway REST API. Physical names are prefixed rmng-.
  • rmng-core holds the compute — Go Lambda functions (ARM64, provided.al2023), the API Gateway methods that route to them, the AWS IoT Core topic rules, SQS queues with dead-letter queues, an ECS Fargate task for bulk node registration, and an HTTP API for Model Context Protocol access.
  • rmng-admin-dashboard holds the built dashboard in an S3 bucket behind CloudFront. Its FrontendUrl output is the URL you sign in to.
Alexa and Enterprise modules

The alexa group is region-constrained — its stack deploys into us-east-1, eu-west-1 and us-west-2, because that is where Alexa accepts skill endpoints, regardless of which region the rest of your deployment lives in. Separately, the Bridge and Support SLA modules belong to a paid Enterprise package and are not part of the open-source rainmaker-neo package; talk to your Espressif contact 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; replacing it on first sign-in is on you. See Post-deployment configuration.
  • 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.
  • Backups — covered, and honestly scoped, in Operations.

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.

Every deployed resource carries the tags RMNGVersion and AppRegion, which is enough to isolate Neo spend in AWS Cost Explorer. The repository contains no cost model or pricing estimate, so build your own from current AWS pricing against your expected device count and message rate.