ThingsPanel: a plugin-driven IoT platform for device access, dashboards and rules

What ThingsPanel is: a platform assembled from plugins

ThingsPanel is a lightweight, componentized open-source IoT application support platform, designed to reduce development efforts and accelerate IoT project construction through reusable plugins.

The componentisation is the whole idea, and the key plugins section lists what the pieces are. Device Function Templates integrate physical models with charts. Device Configuration Templates combine the function templates with protocol plugins. Protocol Access Plugins address various protocol access issues, and Service Access Plugins allow device access through third-party platforms. Dashboard Cards extend dashboard display capabilities, Visualization Plugins expand functionality for large-screen visualisation, and Dependency Plugins are described as building blocks for industry solutions.

The claim that using these plugins repeatedly can greatly improve R&D efficiency is the pitch, and it is a claim about composition rather than about any single feature. A team that needs humidity sensors over MQTT, a Modbus RTU gateway and a wall display has three different concerns, and the platform's contribution is that each arrives as a plugin with a defined interface rather than as custom code inside your application.

The application scope is broader than a collector. The repository description calls it a plug-in IoT platform with high performance, low entry and easy expansion, supporting MQTT, Modbus and other multi-protocol device access, visualisation, automation, alarms and a rule engine. The applications section names unified device management, IoT middleware, and a device vendor's management backend, and the Problems Solved section breaks the audience down into hobbyists, system integrators, solution providers, device manufacturers and end customers.

The primary language is Go, and the licence is Apache-2.0.

The stack in the go.mod, and what it tells you about the design

The dependency list is unusually informative for a project of this kind, because it shows the shape of the backend rather than just its intentions.

The web layer is gin, with go-playground/validator for request validation, gorilla/websocket for real-time connections and golang-jwt for tokens. The data layer is GORM with the Postgres driver, plus gorm.io/gen for code generation and the dbresolver plugin for read and write splitting, and gorm.io/datatypes for JSON columns. That is a relational backend with a generated data layer, not a document store, and it explains the migrations/ directory at the repository root.

The authorisation model is Casbin, both casbin/casbin/v2 and the casbin/gorm-adapter, which the feature overview describes as a Casbin scheme with page permission control, project permission control and multiple role definitions.

The protocol side is paho.mqtt.golang, the Eclipse MQTT client, and there is a dedicated mqtt/ directory in the tree. Other pieces of the stack are viper for configuration, logrus for logging, prometheus/client_golang for metrics, robfig/cron for scheduled work, which lines up with the timer triggers in the feature list, gomail for email notifications, excelize for spreadsheet output, and swaggo/swag for API documentation generation.

Go 1.23 is the language version with a go1.23.8 toolchain. The module path is simply project, which is unusual, and the internal/ and pkg/ directories, along with router/, initialize/ and migrations/, are the usual layout for a Go web application of some size.

Installing it: the all-in-one installer and the port you then visit

The Quick Installation section points at an all-in-one installer page, and says the installer checks the environment, deploys ThingsPanel, and starts the services automatically.

On Linux and macOS the install is a single command:

curl -fsSL https://install.thingspanel.io/install.sh | sh

On Windows, run the equivalent in PowerShell:

irm https://install.thingspanel.io/install.ps1 | iex

Windows and macOS users can also download a graphical installer from the same installer page.

After installation you open http://server-ip:8080, or http://localhost:8080 for a local installation, and initialise the super administrator account before signing in. The readme points to the ThingsPanel Quick Start guide for system requirements, alternative installation methods and troubleshooting.

A couple of things are worth noting. First, the web interface is on port 8080, which is not the port the Docker image exposes. The Dockerfile builds a Go binary with a version stamped in through ldflags, using GOPROXY pointing at goproxy.cn, and the runtime image is alpine with the binary exposed on 9999. So a container deployment and the all-in-one installer are not the same thing, and the port you visit depends on which route you took. Second, there is a published demo at demo.thingspanel.cn with the credentials [email protected] and 123456, which is worth looking at before you install anything, since it shows the dashboards, the telemetry views and the mobile interface without a local setup.

The feature set: from device access to a data gateway

The feature overview is long, and grouping it shows the layers of the product.

Device access is the foundation: creating and editing projects, managing devices by groups, viewing device push status, access via plugins, gateway and sub-device access, Modbus RTU/TCP protocol access, TCP protocol access, GB28181 security camera access, and custom protocol plugin access.

On top of that sit the operational features. There is multitenancy, described as super admin management, tenant account management systems, and tenant users who manage devices and view data. There is a monitoring dashboard with multiple dashboards that can be set as a menu or the homepage. Device function templates define physical models, Web and App charts, and can be exported to JSON, while device configuration templates associate devices, attributes and functions with protocol configurations, data processing, automation, alerts and device settings.

Automation covers scene linkage, scene logs, timer triggers and device triggers, and the alarm section shows alarms by project and group with time period filtering. Notifications go out by SMS, email, phone and webhook.

The rule engine is described as forwarding data to third parties, receiving device data and converting it, accessing various protocols, and doing real-time data calculations. The data gateway exposes an OpenAPI, a database SQL-to-HTTP facility, interfacing with third-party systems, IP and data range restrictions, and authorized reading, which is the part that lets the platform sit between devices and the systems that consume their data.

There is also a product management area with bulk management, QR code data, manual activation and pre-registration, a firmware upgrade area with upgrade tasks and reports, a device map for filtering by project, group and device type, and a visualization section that supports SCADA, large screens, 3D and Three.js.

And a mobile application built with Uniapp, for scanning to add devices, viewing monitoring values, switching projects and device groups.

Where ThingsPanel is the wrong choice

There are three situations where this platform is a poor fit, and the reasons are structural rather than fixable.

The first is a small deployment with one protocol and a few devices. A platform with multi-tenancy, a plugin market, a rule engine and a data gateway is an operating system for IoT, and operating systems have a floor. If the requirement is a handful of sensors posting to a database, the plugin architecture and the tenancy model are both cost without benefit, and a collector plus a time series database is less to run.

The second is a team that needs to own its own device model. The plugin design means the shape of your devices, your attributes and your dashboards is shaped by the plugin interfaces and the templates ThingsPanel provides. A team with a domain-specific device model, a regulated data model or a customer-specific tenancy scheme will find itself extending the platform rather than using it, and the readme's own description of the plugin generator and the app market is a sign of how that extension path is expected to work.

The third is a data-exfiltration or compliance-sensitive deployment. The data gateway with SQL-to-HTTP and authorized reading is a useful feature and also a large surface, and the readme does not describe the audit model for who read which device value through it. The system logs cover IP access paths and device operation records, which is a start, but for a platform that brokers access to industrial devices the security documentation is what you would want, and the visible readme does not point to one beyond the SECURITY.md file in the repository.

The licence is Apache-2.0, which is permissive and fine for an internal deployment, and a company shipping a modified ThingsPanel as a product would want to read the licence text rather than assume the implications.

Project state: a 1.x line shipping every few weeks

The maintenance facts are straightforward and recent. The repository is not archived, the last push was on 2026-10-20, and the recent releases are v1.2.12.1 on 2026-10-14, v1.2.12 on 2026-09-24 and v1.2.11 on 2026-09-03. So the 1.2.x line is moving at roughly a release a fortnight, which is the pace you would expect from a project with an active user base rather than a periodic release.

The version numbering is worth a note. v1.2.12.1 has a fourth component, which in Go convention usually means a patch on a specific earlier release rather than a normal tag, and it is the newest release. A release line with a four-part version is a sign that the maintainers are shipping fixes against specific prior builds for users who cannot move immediately, which is a considerate thing to do and also a sign that version pinning matters here.

The repository layout supports the picture of an application in active development rather than a library. There is a Dockerfile, a Makefile-adjacent build, configs/ for configuration, initialize/ for setup routines, migrations/ for database schema changes, router/ for HTTP routes, pkg/ and internal/ for the code, mqtt/ for the protocol side, sql/ for queries, static/ for assets, third_party/ for vendored code, test/ for tests, plus a system_architecture.md at the root and a docs/ directory. A .deepsource.toml and a .cursor/ directory are also present, and the readme carries a DeepSource badge for active issues.

The docs are split by audience, with a Chinese and an English readme in the repository and a separate quick start guide hosted at docs.thingspanel.cn, so the operational documentation lives on the site rather than in the repository.

Editorial conclusion

ThingsPanel fits a system integrator or device vendor who needs a ready multi-tenant IoT backend with protocol plugins, dashboards and alerting rather than a few custom collectors. It does not fit a team that wants a small, focused agent or that has to own its own tenancy and device model. Before deploying, run the installer and read the quick start guide for system requirements and alternative methods, and decide early whether you will extend the platform through the plugin interfaces or work inside it, because the plugin boundary is where this design either pays off or gets in the way.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. ThingsPanel/thingspanel-backend-community on GitHub