Why ThingsBoard Edge?

ThingsBoard Edge runs the full ThingsBoard platform on-site: at a factory, remote installation, vehicle, or field site. It is designed for deployments where local data processing, local operator access, or reliable offline operation is required.

Edge is designed for deployments where one or more of the following conditions are true.

The problem: The site has no guaranteed internet connection, or the connection is periodically unavailable.

Edge continues operating during connectivity loss. Telemetry is stored locally and synchronized when the connection is restored. Dashboards and alarms remain available to on-site operators regardless of cloud connection status.

Typical deployments:

• Oil rigs with satellite uplinks
• Remote substations
• Ships and other moving assets
• Mining sites
• Agricultural installations in low-coverage areas

The problem: The operation requires deterministic sub-second response times. Any delay causes failures or safety risks.

Edge runs the full Rule Engine on-site. Telemetry processing, threshold evaluation, and RPC commands to devices do not leave the local network.

Typical deployments:

• Factory automation with safety interlocks
• Industrial equipment requiring immediate shutdowns
• Smart building systems with occupancy-driven controls

The problem: High-frequency sensors, vibration monitors, and similar instrumentation generate data volumes that make continuous cloud ingestion expensive or technically impractical.

Edge processes data locally. You define what gets forwarded upstream: aggregated values, anomalies, alarm events, or sampled data. Raw readings that serve no purpose at the cloud level stay on-site.

Typical deployments:

• Industrial facilities with high-frequency sensors
• Vibration and acoustic monitoring
• Dense environmental sensor networks

The problem: Regulatory requirements, contractual obligations, or organizational policy prohibit raw telemetry from leaving the local network or a specific jurisdiction.

Edge stores raw telemetry locally and forwards only what is explicitly configured: aggregated data, anonymized values, or alarm events. This can support compliance with GDPR, HIPAA, and similar frameworks. Compliance obligations are determined by your legal and compliance team, not by the platform.

Typical deployments:

• Healthcare facility infrastructure monitoring
• Government and defense installations
• Financial institutions with data sovereignty requirements

The problem: The system consists of many geographically distributed sites, each requiring local autonomy — local processing, local operator dashboards, local alarms — with centralized visibility across all sites.

Each Edge instance operates independently. A connectivity loss at one site does not affect others. The central ThingsBoard server receives aggregated data from all sites and provides fleet-wide visibility and management.

Typical deployments:

• Utility companies with distributed substations
• Industrial groups with multiple factory sites
• Retail chains monitoring equipment across locations
• Smart city infrastructure

Edge introduces operational overhead. Each instance is a service that must be deployed, monitored, updated, and maintained at its site. That overhead is justified by the conditions above.

Edge is not the right choice if:

• Devices have stable internet with acceptable and consistent latency for all required operations
• Data volumes are within practical cloud ingestion limits and bandwidth cost is not a constraint
• No regulatory or policy requirement prevents cloud storage of raw data
• The deployment is a single location with reliable connectivity and no offline-operation requirement

In these cases, connecting devices directly to ThingsBoard Cloud or a self-hosted ThingsBoard server is architecturally simpler and operationally lighter.

ThingsBoard Edge does not operate in isolation. It is part of a broader architecture that includes a ThingsBoard server and, optionally, an IoT Gateway.

Every Edge instance is bound to a ThingsBoard Cloud or self-hosted server. It provisions the Edge instance, pushes configurations (e.g., device profiles, or firmware updates), and receives synchronized data. Edge always operates in conjunction with a ThingsBoard server.

ThingsBoard IoT Gateway is a separate component for connecting devices that use protocols ThingsBoard does not natively support: Modbus, OPC-UA, and others. It translates those protocols into ThingsBoard’s data model and forwards data upstream.

Gateway has no local Rule Engine, no local dashboards, and no local alarm processing. It is not designed for offline-first operation.

ThingsBoard Edge and IoT Gateway are complementary. A common deployment pattern is: IoT Gateway bridges legacy devices into Edge → Edge processes data locally → Edge syncs to the cloud.

Gateway is not required for an Edge deployment. It is relevant when the site includes devices that Edge cannot connect to directly.

ThingsBoard Edge PE brings the capabilities of ThingsBoard Professional Edition to the edge. It includes everything in the Community Edition, plus enterprise features for access control, integrations, and branding.

Some highlights include:

• Connectivity: MQTT, CoAP, HTTP, LwM2M, and SNMP.
• Rule Engine: Local data processing, filtering, and enrichment.
• Dashboards: Real-time dashboards for on-site operators.
• Alarms: Local alarm processing and notifications.
• Storage: PostgreSQL for local data.
• Message queue: In-Memory (development/PoC only), Kafka (recommended for production), or a hybrid setup for high-scale deployments (1M+ devices or 5,000+ msg/sec).
• Remote control: RPC commands to devices.
• Sync: Bidirectional synchronization with the ThingsBoard server.

Edge PE also includes:

• RBAC: Role-based access control for teams and customers.
• Entity groups: Organize devices, assets, and users into groups.
• Integrations: Advanced integrations with external systems.
• White-labeling: Custom branding for the UI.
• Scheduler: Time-based rule chain triggers.