# ThingLinks: a multi-tenant IoT platform with a rule engine on Spring Cloud

> ThingLinks is an IoT platform that puts device connectivity, a rule engine, a visual dashboard and time-series storage behind a multi-tenant SaaS architecture, built on Spring Cloud microservices with a BifroMQ broker. It ships a commercial licence alongside the source, and its deployment assumes a fleet of backing services.

**mqttsnet/thinglinks** — Enterprise-grade IoT platform powered by ThingLinks Engine.  Supports MQTT / HTTP / CoAP / TCP / Modbus, rule engine,  Visual display screen & multi-tenancy. Millions of connections per node.

- Repository: https://github.com/mqttsnet/thinglinks
- Website: https://mqttsnet.com
- Stars: 1,082 · Forks: 230
- Language: PLpgSQL
- License: NOASSERTION
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/mqttsnet-thinglinks

## What the platform is, and who builds it

ThingLinks is described in the README as an enterprise-grade multi-tenant SaaS cloud IoT platform built on Spring Cloud microservices architecture, delivering high-performance, high-throughput and highly-scalable device connectivity, supporting millions of concurrent connections on a single node with plugin-based extensibility and multi-protocol adaptation.

The vendor is mqttsnet, whose site is mqttsnet.com, and the README is available in English, Simplified Chinese, Japanese and Korean. The primary language of the repository is listed as PLpgSQL, which reflects the weight of the SQL side of the tree rather than the application layer, which is Java.

The scope is a complete IoT stack rather than a component. The feature table covers multi-tenant SaaS with complete tenant isolation, million-level connections on a single node, multi-protocol support across MQTT, WebSocket, TCP, UDP, CoAP, HTTP and Modbus, a unified product model with device lifecycle, device shadow and firmware OTA, a rule engine with chained rules and event orchestration, an alarm centre with multi-channel notification, SCADA and visualisation with asset maps and large-screen displays, a TDengine time-series database, a plugin system, a message bus, protocol SDKs in Java, C and Python, IoT SIM card management, video streaming with a media server, a planned AI data platform, and ecosystem integrations with Huawei IoT, Alibaba IoT and Apache BifroMQ.

That last group is telling. The BifroMQ integration is the one that connects to the project's origin, since the repository has a bifromq-plugin/ directory and the thinglinks-broker/ service is described as MQTT Broker Integration (BifroMQ). The message bus, the rule engine and the device management all sit on top of a broker rather than replacing it.

The audience is an integrator or a platform team with real device fleets, where connectivity, rules, dashboards and tenant separation all have to be delivered together, and where a hosted protocol abstraction saves writing one per device vendor.

## The microservice decomposition, read from the directory names

The project structure section of the README lists the backend services, and the names describe the platform's decomposition more clearly than any prose would.

thinglinks-gateway is the API Gateway. thinglinks-oauth handles authentication and authorization, which in a multi-tenant platform is not an optional extra. thinglinks-link is the IoT Device Connectivity Core, which is the piece that speaks the protocols. thinglinks-broker is the MQTT Broker Integration with BifroMQ. thinglinks-rule is the rule engine. thinglinks-mqs is the Message Queue Service. thinglinks-card is IoT Card Management, which is the SIM card channel and lifecycle work. thinglinks-mobile is the Mobile API. thinglinks-support is for monitor and admin services, and thinglinks-sop-admin is DevOps management. thinglinks-generator is a code generator, thinglinks-openapi is the Open API service, thinglinks-public is a public service, thinglinks-base is the base platform service, and thinglinks-sdk holds the SDK.

Two of those deserve comment. A separate Open API service next to a gateway means the platform distinguishes its public, partner-facing surface from its internal one, which is a normal consequence of multi-tenancy and of wanting to expose device APIs without exposing the whole service mesh. And a code generator in the microservice tree is a signal about how much of the platform is scaffolded, which for a platform with this many services is the difference between a maintainable system and a set of copy-pasted modules.

The rest of the tree adds the pieces around the services. There is thinglinks-web/ for the admin console, thinglinks-web-visualize/ for the visualisation dashboard, thinglinks-job/ for the job services, a bifromq-plugin/ directory, a docs/ directory with the SQL scripts the quick start refers to, a licenses/ directory, a changelogs/ directory, and scripts/.

The stack behind all of this is also in the README as a badge list: Java 17+, Spring Boot 3.x, Spring Cloud 2025, Netty 4.x, Vue 3, TDengine 3.0+, Nacos 3.x, Sentinel 1.x, Seata 2.x, Redis 7.x, MySQL 8.0, Kafka supported, and Docker supported.

That list is a design summary in itself. Netty is the network layer for the protocol connectors, Nacos is the service registry and configuration centre, Sentinel is the flow control and circuit breaking, Seata is the distributed transaction coordinator, Kafka carries the message bus, and TDengine holds the time-series data. MySQL holds the relational metadata, Redis the cache, and Vue 3 the two front ends.

## Getting it running, and the six services you have to stand up first

The requirements table is short and it is the reason this platform is a heavy choice. You need JDK 17+, Node.js 18+, MySQL 8.0+, Redis 7.x, TDengine 3.x and Nacos 3.x.

The backend sequence in the README is:

```bash
# 1. Clone the repository
git clone https://github.com/mqttsnet/thinglinks.git

# 2. Import SQL scripts (see docs/sql/)

# 3. Configure Nacos, MySQL, Redis, TDengine connection info

# 4. Build
cd thinglinks/thinglinks-cloud
mvn clean install -DskipTests

# 5. Start services (gateway, oauth, link, etc.)
```

Two details in that list deserve a second look. The SQL import is not optional and the schema is not in the repository's top level, it is in docs/sql/, so a deployment starts with a data load rather than a build. And the build skips tests, which is what you want for a first run of a service set this size, and is also a reminder that the test suite is not part of the happy path.

The front end is two separate applications, each with its own dependency install:

```bash
# Admin Console
cd thinglinks-web
pnpm install
pnpm run dev

# Visualization Dashboard
cd thinglinks-web-visualize
pnpm install
pnpm run dev
```

And there is a Docker path for a one-click deployment:

```bash
# One-click deployment
docker compose -f thinglinks-cloud/docker/docker-compose.yml up -d
```

The README points at mqttsnet.com for the detailed deployment guide. That pointer is worth heeding, because the compose file in the cloud directory is described as a deployment artefact for the whole service set, and six backing services with Nacos configuration, Seata transaction coordination and Sentinel flow control are not the kind of thing you want to debug from a compose file alone.

## The rule engine, the device shadow and the message bus

Three of the feature table entries are the parts worth understanding in detail, because they are what a platform user actually configures.

The rule engine is described as supporting chained rules, event orchestration and scene linkage with property, action and timer triggers. Chained rules mean one rule's output can be the next rule's input, so a device event can trigger an action that itself emits an event. Property triggers are state changes on a device or product, action triggers are commands, and timer triggers are time-based. The scene linkage term covers the case where a group of devices is treated as one object with a shared state, which is how a lighting or HVAC scenario is expressed.

The device management row lists a unified product model, device lifecycle, device shadow and firmware OTA. The device shadow is the interesting part: a server-side representation of a device's state that persists independently of the physical device and of its connection. That solves a real problem in IoT, where a device that is offline still has a known state, and a command sent to it can be recorded and applied when it reconnects. The unified product model is the corresponding piece on the catalogue side, so that devices of the same type share a definition.

The message bus is described in one line as message governance: formatting, routing, filtering, queueing, security. That is a deliberate separation of concerns. Device protocols are messy and each one has its own message shapes, so a bus that normalises formatting, decides what routes where, filters what is allowed through, queues what cannot be handled immediately, and applies the security policy in one place, is what allows the rule engine and the dashboards to work with the same model regardless of protocol.

The time-series storage is TDengine, with a specific schema: one table per device, one super-table per device type. That is the standard TDengine model, and the reason for it is that the query pattern in IoT is almost always time-series-per-device with aggregation across devices of a type, and the super-table gives you that aggregation without a join.

Behind the rule engine sit the protocol SDKs, in Java, C and Python, and the plugin system for custom protocol work, and the bifromq-plugin/ directory is where the broker integration lives.

## The licence split, which is the part to read before anything else

The repository listing contains both a LICENSE file and a LICENSE-COMMERCIAL file, and there is a licenses/ directory as well as a SUPPORT.md. The README's badge says Apache 2.0. The repository's own metadata lists the licence as a custom one that GitHub cannot classify, with the LICENSE file to consult.

Those facts do not fit together without reading the files, and the presence of a separate commercial licence file is the reason to read them carefully. The pattern this shape usually takes is a core of the platform under a permissive licence with the commercially valuable parts, typically the hosted or managed offering, under separate terms. This is not a defect and it is not unusual for a platform that also sells a commercial product, but it means the README's Apache 2.0 badge is not a complete statement of what you may do with the code.

Nothing in the visible documentation explains the split, so the correct thing to do is read LICENSE, LICENSE-COMMERCIAL, the licenses/ directory and SUPPORT.md, and have whoever owns the licence question in your organisation look at them. This article cannot tell you whether a permissive core licence is what you need or whether the platform as a whole requires a commercial agreement, and it would be wrong to guess from a badge.

What can be said is what the repository structure implies. A SUPPORT.md next to the licences, a CHANGELOG.md, a CODE_OF_CONDUCT.md, a CONTRIBUTING.md, four translated READMEs and a docs/ directory with the SQL scripts and the deployment guide together describe a project that is being run as a product rather than released as an occasional open source drop. That is neither good nor bad on its own, but it does change the questions you ask before adopting. You are evaluating a platform with a commercial dimension, not a library with a permissive licence, and the commercial dimension is where the relationship with the vendor lives.

## Where ThingLinks is the wrong tool

There are three limits, and the first one is about scale in both directions.

The first is that this is a platform, and platforms have a floor. Six backing services, a service registry, a distributed transaction coordinator and a flow control component are the minimum to run the thing, and a single-tenant deployment or a handful of devices cannot justify that. If what you need is to read MQTT messages and act on them, a broker with a rule plugin or a small consumer service is a much better fit, and the multi-tenant SaaS architecture of ThingLinks is overhead rather than value. The same argument applies at the other end: the platform's features are aimed at large fleets and multi-tenant operation, so a deployment with ten devices will use a fraction of what is here.

The second is that the protocols you need may not be there. The README lists MQTT, WebSocket, TCP, UDP, CoAP, HTTP and Modbus as supported, and the extensibility path is the plugin system plus the Java, C and Python protocol SDKs. But the ecosystem row shows integrations with Huawei IoT, Alibaba IoT and Apache BifroMQ, and the plugin work is real engineering: a protocol adapter has to handle the framing, the authentication, the heartbeat and the reconnection semantics of the device family it targets. The README does not enumerate the full list of available protocol plugins, so the check you need to make is whether your specific device protocol is covered today rather than whether the platform could support it in principle.

The third is the data model constraint. TDengine with one table per device and one super-table per device type is a good fit for telemetry, and it is a poor fit for a fleet with a very large number of short-lived devices, because a table per device is a lot of tables. And the time-series store is one component of the data story, not the whole of it, since MySQL holds the relational metadata, the device catalogue and the tenancy model, and a deployment inherits the consistency boundary between the two.

There is also the operational one that comes with the vendor relationship. The release line has moved recently, with 1.2.0.RELEASE from 2024-08-08, 1.3.0 from 2026-03-27 and 1.4.0 from 2026-07-22, and the last push was on 2026-08-13. So the project is being worked on, but the release numbering skips and the version scheme changes between 1.2 and 1.3, which is a signal that you should read the changelogs/ directory before planning an upgrade.

## Conclusion

Adopt ThingLinks if you are an integrator building device connectivity and rule automation on top of a broker, you want the rule engine, dashboard and tenant isolation in one platform, and you are prepared to run Nacos, MySQL, Redis and TDengine alongside it. Do not adopt it if you need a lightweight broker or a standalone rules service, since this is a full platform with a large operational surface. Verify first that your licence path is the one you intend, because the repository carries both a LICENSE file and a LICENSE-COMMERCIAL file, and that the protocol you need, whether Modbus, CoAP or a custom one, is available as a plugin rather than something you have to build.

## FAQ

### What is ThingLinks and what architecture is it built on?

ThingLinks is an enterprise-grade multi-tenant SaaS cloud IoT platform built on Spring Cloud microservices. It supports MQTT, WebSocket, TCP, UDP, CoAP, HTTP and Modbus, with a rule engine, a device shadow, a TDengine time-series store, a Vue 3 admin console and a separate visualisation dashboard.

### What do I need to run ThingLinks?

The requirements table lists JDK 17+, Node.js 18+, MySQL 8.0+, Redis 7.x, TDengine 3.x and Nacos 3.x. The README's quick start also has you import the SQL scripts from docs/sql/ and configure the Nacos, MySQL, Redis and TDengine connection info before building with Maven.

### How is the device time-series data stored?

The README describes the time-series database as TDengine, with one table per device and one super-table per device type. That schema is what supports per-device time-series queries and aggregation across a class of devices.

### How do I add a protocol that ThingLinks does not support?

The platform has a plugin system for custom protocol and feature extensions, along with Java-SDK, C-SDK and Python-SDK for protocol extensions, and the repository contains a bifromq-plugin directory for the broker integration.

## Sources

- [Issues](https://github.com/mqttsnet/thinglinks/issues)
- [mqttsnet/thinglinks on GitHub](https://github.com/mqttsnet/thinglinks)
- [Project website](https://mqttsnet.com)
- [README](https://github.com/mqttsnet/thinglinks/blob/main/README.md)
- [Releases](https://github.com/mqttsnet/thinglinks/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/mqttsnet-thinglinks