Cloud Architecture

ThingsBoard Cloud is a fully managed IoT platform running the same Professional Edition codebase, deployed as a microservices cluster. Two independent regional instances provide complete data isolation and geographic proximity for your devices.

ThingsBoard Cloud operates two independent regions. Each region is a fully self-contained deployment — its own Kubernetes cluster, databases, message queues, and caches. The regions share no data with each other.

	North America (NA)	Europe (EU)
URL	thingsboard.cloud	eu.thingsboard.cloud
Cloud provider	AWS	AWS
Data isolation	Complete — no data shared with EU	Complete — no data shared with NA

Regional independence means a failure or maintenance event in one region does not affect the other.

Each region runs on AWS Elastic Kubernetes Service (EKS) spanning multiple Availability Zones (AZs). If an entire AZ goes down, services continue running in the remaining AZs without manual intervention.

All ThingsBoard services are stateless Kubernetes pods. Kubernetes handles:

• Auto-restart — failed pods are restarted automatically
• Rescheduling — pods from unhealthy nodes move to healthy ones
• Scaling — pod replicas scale based on CPU, memory, and connection metrics

ThingsBoard Cloud runs as independent microservices, each scaling separately based on load:

Service	Responsibility
MQTT Transport	Accepts device connections over MQTT, authenticates credentials, pushes messages to the rule engine
HTTP Transport	Accepts device data over HTTP/HTTPS
CoAP Transport	Accepts device data over CoAP
LwM2M Transport	Manages LwM2M device registration, observation, and firmware updates
SNMP Transport	Polls SNMP-enabled devices for telemetry
ThingsBoard Node	Core service — REST API, WebSocket subscriptions, Rule Engine, entity management, device connectivity state
JS Executor	Executes user-defined JavaScript and TBEL scripts from rule engine nodes in isolated sandboxes
Integration Executor	Runs platform integrations (OPC-UA, SigFox, TheThingsNetwork, etc.), pulling data from external systems into ThingsBoard
Web UI	Serves the Angular-based dashboard application, proxies REST/WebSocket requests to ThingsBoard Node

Each transport protocol runs as its own set of pods — MQTT can scale independently from HTTP or CoAP based on your device fleet composition. See the individual API references for protocol details: MQTT API, HTTP API, CoAP API, LwM2M API.

When a device sends data, it follows this path:

1. Connect — Device opens a connection to a Transport pod (MQTT, HTTP, CoAP, or LwM2M).
2. Authenticate — Transport validates device credentials against the Core service. Valid credentials are cached to avoid a database query on every message.
3. Push to Rule Engine — Transport converts the protocol-specific payload into a unified message and forwards it to the Rule Engine via the message queue (Kafka).
4. Execute Rule Chains — The Rule Engine processes the message through your configured rule chains — filtering, enriching, transforming, and triggering actions.
5. Persist — Action nodes save telemetry, attributes, or alarms to the database.
6. Notify — Core pushes real-time updates to WebSocket subscribers (dashboards).

ThingsBoard Cloud uses purpose-built databases for each workload:

Database	What it stores	Replication
PostgreSQL (main)	Entities, attributes, relations, alarms, system data	Multi-AZ replication
Cassandra	Time-series telemetry	Replication factor 3 across AZs
PostgreSQL (events)	Debug events, audit logs, lifecycle events	Multi-AZ replication

The events database is separate from the main PostgreSQL instance. This isolation prevents debug event spikes — such as enabling debug mode on a busy rule chain — from affecting entity query latency.

Every data store replicates across multiple Availability Zones:

Component	Replication strategy
PostgreSQL	Multi-AZ replication with automatic failover
Cassandra	Replication factor 3 across AZs
Apache Kafka	Topic replication factor 3 across AZs
Redis / Valkey	Cluster mode with AZ-aware failover

Automated daily backups with point-in-time recovery are configured for all databases.

ThingsBoard Cloud scales horizontally at every layer:

• Transport pods scale based on active device connections and message throughput
• ThingsBoard Node pods scale based on REST API load, WebSocket subscriptions, and rule engine processing
• JS Executor pods scale based on script evaluation queue depth
• Kafka partitions distribute rule engine load evenly across ThingsBoard Node pods
• Cassandra nodes scale linearly — adding nodes increases both storage capacity and write throughput

The architecture eliminates single points of failure:

• Multiple pod replicas run across AZs for every service
• Kubernetes auto-restarts failed pods and reschedules them to healthy nodes
• Kafka rebalances partitions when a consumer pod fails — other pods pick up the load
• Load balancers distribute device connections and API requests across healthy pods
• Regional independence — an incident in one region does not affect the other

ThingsBoard Cloud handles all infrastructure operations:

Responsibility	Self-hosted	Cloud
Kubernetes cluster provisioning and upgrades	You	ThingsBoard
PostgreSQL administration and replication	You	ThingsBoard
Cassandra cluster management and tuning	You	ThingsBoard
Kafka cluster operations	You	ThingsBoard
Redis / Valkey cache management	You	ThingsBoard
Operating system patching	You	ThingsBoard
Database backups and recovery	You	ThingsBoard
Infrastructure monitoring and alerting	You	ThingsBoard
SSL/TLS certificate management	You	ThingsBoard
Platform version upgrades	You	ThingsBoard
Load balancer configuration	You	ThingsBoard

You focus on building your IoT solution — devices, rule chains, dashboards, and integrations. ThingsBoard manages everything else.