Documentation

Appearance

Dataplicity vs IoT application platforms: device operations vs dashboards and digital twins #

Choose an application-centric IoT platform when telemetry ingestion, dashboards, digital twins, rule processing, and custom visualization are the center of the product. Choose Dataplicity when the harder problem is operating and supporting a real Linux installed base, while still giving downstream customers a product application around those devices.

This category is broad. This page uses ThingsBoard as a concrete reference rather than pretending every IoT application platform looks the same.

ThingsBoard's current docs include multi-tenancy, customers, users and roles, dashboards, widgets and controls, rule engines, alarms, white-label capabilities, integrations, and device management. It would be wrong to claim these platforms cannot provide customer portals, rules, or device controls.

Reviewed against public ThingsBoard documentation on 7 September 2026.

Why these get compared #

Both can sit between connected devices and downstream users. Both can display telemetry, expose controls, separate customers, and put application logic around equipment.

The difference is where the platform starts.

Application-centric IoT platforms generally start from:

text
device data -> entity/digital twin -> rules -> dashboard/application

Dataplicity starts from:

text
Linux device -> support/fleet operations -> product contract -> customer application

Those paths overlap. They optimize for different first problems.

ThingsBoard: IoT data, entities, dashboards, and rules #

ThingsBoard 4.3, released in January 2026, documents substantial functionality including:

  • telemetry and attribute ingestion
  • device and entity models with relations, plus calculated fields
  • dashboards and widgets
  • alarms, including Alarm Rules 2.0
  • rule-engine processing, with rule nodes for AI model calls
  • multi-tenancy and customer hierarchies
  • users and roles
  • white-labeling in commercial editions
  • integrations, API keys, MQTT 5, and protocol and connectivity options
  • device RPC commands, shared and client attributes, and firmware and software OTA packages with rollout pacing, checksums, and update-state history

Editions matter when you compare. Community Edition is Apache 2.0 and covers core multi-tenancy, the rule engine, dashboards, devices, and core protocols. Professional Edition and ThingsBoard Cloud add customizable RBAC, entity groups, platform integrations, white-labeling, and reporting, and Professional Edition 4.3 introduced a new licensing model with modular add-ons. ThingsBoard Edge and Trendz are add-ons. Confirm which capabilities your intended edition and plan actually include.

For a product whose primary value is collecting data, processing it, and building rich dashboards or SCADA-like applications, that can be an excellent fit.

Dataplicity: the Linux device stays operationally first-class #

Dataplicity is designed around the fact that the remote endpoint is a general Linux computer running a real product application that engineers must support for years.

The operating layer includes:

  • Remote Shell
  • logs and diagnostics
  • fleet jobs
  • process, package, and software evidence
  • Device Class Pulse and drift and outlier analysis
  • bounded software operations
  • managed RAUC image delivery on a qualified image
  • device identity and fleet inventory
  • support workflows behind customer networks

Then Device Classes, streams, settings and actions, Customer Portal, and Product Applications add the customer-product layer.

That sequence matters for products where fixing the Linux box is as important as drawing the chart.

Choose an IoT application platform when... #

An application-centric platform such as ThingsBoard is likely the stronger fit when:

  • telemetry ingestion and visualization are the primary product
  • you need highly configurable dashboards and widgets
  • digital-twin and entity relationships are central to the application model
  • a broad rule engine over device and business data is a core requirement
  • SCADA-like screens or bespoke visualization dominate the UX
  • your device operating and support layer is already solved elsewhere
  • the endpoint may not be Linux at all, or Linux-specific support tooling is not important
  • you need broad industrial protocol coverage such as Modbus, OPC-UA, BACnet, CAN, or BLE

If the buying question is "how do we build a sophisticated IoT dashboard and rules application?", ThingsBoard is closer to that problem than Dataplicity is.

Choose Dataplicity when... #

Dataplicity is the stronger fit when:

  • the endpoint is a Linux product your engineers remain responsible for after shipment
  • remote support, logs, shell access, fleet jobs, software and version evidence, and device drift matter across every device, not only a gateway
  • you have brownfield Linux devices that should not be rebuilt to join an IoT application platform
  • the customer application can be expressed around product-specific state, controls, sites, and bounded workflows rather than a general dashboard construction environment
  • you want one platform to bridge OEM engineering operations and downstream customer use without exposing engineering surfaces to the customer

Dataplicity is opinionated here: it does not try to out-dashboard a general-purpose IoT dashboard builder. It makes the shipped Linux product supportable and operable first, then exposes the right product experience to the customer.

ThingsBoard does have a remote shell. Note where. #

ThingsBoard IoT Gateway now documents a browser-based Remote Shell, along with remote logging, remote configuration, service RPCs, and restart, reboot, and update commands, plus gateway health views. Any claim that these platforms offer no Linux shell access is out of date.

The scope is what differs. Those capabilities apply to hosts running the IoT Gateway. A generic ThingsBoard device gains shell or package operations only if its own firmware or agent implements them, and ThingsBoard's documentation does not describe a general package inventory or declarative package-management subsystem across arbitrary Linux hosts.

Dataplicity's assumption is the opposite: every enrolled device is a Linux computer with shell, logs, jobs, process and package evidence, and drift analysis available as standard.

Customer tenancy is not unique to Dataplicity #

ThingsBoard explicitly documents a multi-tenant model with tenants, customers, users, roles, and customer-isolated devices and assets. Commercial editions add customizable RBAC, entity groups, nested customer controls, white-labeling, and customer-facing dashboards.

Dataplicity's distinction is not "we have customers and they do not." It is how customer tenancy is tied to the same Linux device support and product model the OEM engineering team uses.

Rules and controls aren't unique either #

ThingsBoard's Rule Engine processes telemetry, attributes, lifecycle events, and RPC messages, transforms data, creates alarms, calls external systems, and drives application behaviour. Dashboards can contain controls.

Product Applications should not be presented as if rules and workflows themselves are novel.

What Dataplicity actually offers is narrower:

  • Product Applications are integrated with Device Classes, customer, site and device allocation, device commands, offline datasets, and the OEM/customer boundary
  • they are meant for bounded product workflows, not as a generic visual integration platform
  • the underlying Linux device stays directly diagnosable and operable through the same vendor platform

They can coexist #

A reasonable architecture can use both:

text
Dataplicity
- Linux device support
- fleet operations
- software / drift / diagnostics
- customer-safe device contract

External IoT / analytics platform
- advanced telemetry analytics
- specialist dashboards
- SCADA / digital twins
- broad rule / data processing

If a customer already has a preferred historian, BI, SCADA, or IoT application platform, Dataplicity does not need to replace it to add value at the device and fleet layer.

Decision table #

DecisionThingsBoard / application-centric IoT platformDataplicity
Primary abstractionIoT entities, data, digital twins, applicationsLinux devices, fleets, products, customers
Telemetry ingestionCore strengthProduct streams, with a deliberately narrower app model
Dashboard flexibilityMajor strengthOpinionated product and customer UI, not a general dashboard builder
Rule engineMajor strength, including AI rule nodesBounded rules and processes through Product Applications
Industrial protocol coverageBroad, through IoT GatewayYour application owns protocol work on the device
Multi-tenancy / customersFirst-class in ThingsBoardCustomer, site, and device model
White-label / customer UICommercial editions, gated by planCustomer Portal
Linux remote shellDocumented for IoT Gateway hostsFirst-class for every enrolled device
Logs / device diagnosisGateway logs and configuration; not centred on Linux supportFirst-class OEM workflow
Package and process inventoryNot a documented platform subsystemFirst-class evidence
Fleet jobs / Linux operational actionsNot the primary application-platform abstractionFirst-class
OS image updatesFirmware and software OTA packagesManaged RAUC on a qualified image
Peer process / package / binary driftNot the focusPulse and product-class evidence
Brownfield existing Linux runtimeCan integrate as a device or data sourceFirst-class operating assumption
Best fitData, application, and dashboard-centric IoTLinux product operations plus customer product layer

Where ThingsBoard-style platforms are plainly stronger #

Dataplicity is not the best choice for every telemetry-heavy product.

If you need:

  • arbitrary dashboard composition
  • a large widget ecosystem
  • rich digital-twin and entity graph modelling
  • extensive visual rule processing
  • SCADA-style visualization
  • broad industrial protocol bridging
  • protocol and data-platform work spanning many non-Linux device types

an application-centric IoT platform may go substantially deeper in those areas. An open-source core you can self-host is also a genuine option ThingsBoard offers and Dataplicity does not.

Dataplicity is stronger when the neglected problem is the lifecycle of the Linux product itself.

Sources #

Primary ThingsBoard documentation reviewed:

Dataplicity: