# JetLinks Community: a reactive Java IoT platform you can run with Java 17, Redis and TimescaleDB

> JetLinks Community is an Apache-2.0, Spring Boot 3 and WebFlux based IoT platform that unifies device access across MQTT, TCP, UDP, CoAP and HTTP. It is aimed at Java teams that want the platform source in hand, and it expects you to bring PostgreSQL, Redis and a time-series store.

**jetlinks/jetlinks-community** — JetLinks  基于Java,Spring Boot ,WebFlux,Netty,Vert.x,Reactor等开发, 是一个全响应式的企业级物联网平台。支持统一物模型管理,多种设备,多种厂家,统一管理。统一设备连接管理,多协议适配(TCP,MQTT,UDP,CoAP,HTTP等),屏蔽网络编程复杂性,灵活接入不同厂家不同协议等设备。实时数据处理,设备告警,消息通知,数据转发。地理位置,数据可视化等。能帮助你快速建立物联网相关业务系统。

- Repository: https://github.com/jetlinks/jetlinks-community
- Website: https://www.jetlinks.cn/
- Stars: 6,647 · Forks: 1,945
- Language: Java
- License: Apache-2.0
- Published: 2026-09-22 · Updated: 2026-09-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/jetlinks-jetlinks-community

## What JetLinks Community solves, and for whom

Building an IoT backend from scratch means writing the same layers repeatedly: a connection manager that keeps thousands of sockets alive, a decoder per vendor protocol, a model that describes what a device is, storage for the time-series it emits, and something that fires an alarm when a reading crosses a threshold. JetLinks Community packages those layers as one Java application. The README describes it as an enterprise IoT base platform that is ready to use and open to secondary development, covering unified thing model management, multi-vendor and multi-protocol device access, real-time data processing, device alarms, notifications and data forwarding.

The audience is narrow and specific. The README states version 2.1x is built on Java 17, Spring Boot 3.x, WebFlux, Netty, Vert.x and Reactor, and the repository is almost entirely Java. If your team does not write Java, the value proposition shrinks to a running product you cannot extend. For Java teams, the source is the point: the README lists full source availability, front-end and back-end separation, and fully open interfaces as core characteristics. The topics list confirms the same stack: r2dbc, reactive-streams, reactor, netty, webflux, mqtt, rule-engine.

## How the reactive pipeline and module split fit together

JetLinks is built as a reactive application end to end, not a servlet app with reactive patches. Spring WebFlux handles HTTP, R2DBC is the database driver, and Project Reactor supplies the programming model. Netty and Vert.x sit underneath the network layer. That matters because device access is long-lived connections and streams of messages, which is the workload reactive backpressure was designed for; a thread-per-request model would spend most of its threads blocked on sockets.

The repository layout shows how the pieces are separated. jetlinks-components holds shared building blocks with one directory per concern: network-component for MQTT, TCP, CoAP and UDP; gateway-component for message gateways and device access; protocol-component for protocol handling; rule-engine-component for the rule engine; things-component for the thing model; timeseries-component, tdengine-component and elasticsearch-component for storage; notify-component for SMS and other notifications. jetlinks-manager holds the business-facing modules: device-manager, network-manager, rule-engine-manager, notify-manager, visualization-manager, logging-manager and authentication-manager. jetlinks-standalone is the startup module, and simulator is a device simulator.

The data flow implied by that split is: a device connects through a network component, a protocol component decodes its payload, the gateway routes the message to the device manager, decoded properties are written to a time-series store, and the rule engine evaluates them for alarms, scene linkage and forwarding. The README states that device alarms and scene linkage are both managed by the unified rule engine rather than by separate subsystems, and that data permission control is non-intrusive and can be applied at menu, button and row level.

## Running JetLinks Community with Docker and a first device

The README points at the docker directory as the entry point. Two subdirectories are named in the module listing: docker/dev-env, described as starting the development environment, and docker/run-all, described as starting everything, with the system reachable at http://localhost:8848. The repository also ships run.sh, mvnw, mvnw.cmd and build-and-push-docker.sh at the top level.

The README shows the module tree in a fenced block rather than a set of shell commands, so the layout is the documented artifact:

```bash
--jetlinks-community
------|----docker
------|------|----dev-env       # 启动开发环境
------|------|----run-all       # 启动全部,通过http://localhost:8848 访问系统.
------|----jetlinks-components  # 公共组件模块
------|----jetlinks-manager     # 业务管理模块
------|----jetlinks-standalone  # 服务启动模块
------|----simulator            # 设备模拟器
```

According to the README, the platform is then available at http://localhost:8848 when run-all is started. The README does not spell out the compose file names or the exact command, so read the contents of docker/run-all before starting it.

The README states the minimum runtime is Java 17, Redis and TimescaleDB, and that no large set of middleware is required. PostgreSQL is listed in the technology stack as the store for business data, and TimescaleDB is listed as optional time-series storage. The README does not document which of those the docker/run-all environment actually provisions, so inspect the compose files rather than assuming.

A device simulator is included in the simulator directory. The README does not document its command line, so treat it as a module to read rather than a documented tool.

## Where JetLinks Community is the wrong tool

The documentation is the first limitation. The README is written in Chinese, and the service support table lists free basic question answering through QQ groups, with paid product documentation and teaching as separate offerings. There is no English quickstart in the README, and the README does not document rollback, backup or upgrade procedures. A team that needs English onboarding material or a documented operational runbook will be doing that work itself.

The second limitation is operational weight. The README calls the minimal runtime Java 17, Redis and TimescaleDB, which is smaller than a full middleware estate but still three moving parts, plus PostgreSQL for business data. If you want a single binary with an embedded store, this is not that. If you want a hosted service where someone else runs the database, this is not that either.

The third is scope. JetLinks is a platform, not a library. The module list shows a rule engine, a dashboard, a notification subsystem, data permission control and a visualization manager. If you only need an MQTT broker with a webhook, adopting a full platform means carrying modules you will never configure, and the reactive stack means debugging requires comfort with Reactor operators and R2DBC rather than JDBC. The README does not publish a benchmark, a device-count limit or a throughput figure, so sizing must come from your own load testing, not from the project's claims.

## How it differs from ThingsBoard and from rolling your own

The obvious comparison in this category is ThingsBoard, another open source IoT platform with device management, rule chains and dashboards. The difference that matters here is the runtime: ThingsBoard is a Java and Spring application with a conventional blocking data path, while JetLinks is built on WebFlux, R2DBC, Reactor, Netty and Vert.x from the ground up, and its README makes that reactive stack the headline. If your team already thinks in Reactor and wants the device pipeline to share that model, JetLinks is the more natural fit; if your team is comfortable with Spring MVC and JDBC, ThingsBoard's model will be less foreign.

The second alternative is writing the ingestion layer yourself. If your requirement is one protocol and one storage target, a Netty or Vert.x service plus a time-series database is a few hundred lines and no platform to learn. JetLinks earns its weight when you have several protocols, several vendors and a need for a shared thing model, alarms and forwarding rules. Below that threshold, the module list in this repository is overhead.

The third alternative is the vendor's own cloud. That trades source access and self-hosting for someone else running the databases. The README's emphasis on full source and open interfaces is a direct argument against that trade, and it is the reason the project exists in this form.

## Maintenance, licensing and what an upgrade costs

The repository is not archived, and the last push was on 2026-09-18, so the codebase is being touched. The release history is uneven: 2.2.0 on 2024-09-27, 2.3.0 on 2025-04-27, and 2.10.0 on 2025-10-27, while the default branch is 2.11. The jump from 2.3.0 to 2.10.0 in the release list, with no intermediate tags shown, suggests releases are not cut on a fixed cadence. Plan upgrades around reading the source diff rather than around a predictable release train.

The upgrade cost is tied to the stack. The README pins Java 17 and Spring Boot 3.x, and the components span Netty, Vert.x, Reactor and R2DBC. A Spring Boot major or minor bump ripples through every component module, and the reactive chain means a changed operator signature surfaces at compile time across many files. Because the platform is meant for secondary development, any local modifications to jetlinks-components or jetlinks-manager become merge work on every upgrade. Keeping custom code in separate modules reduces that cost.

Licensing is Apache-2.0, per the LICENSE file at the repository root. That permits commercial use and modification, and it includes a patent grant; it also means you must preserve notices and state changes. The repository carries a licenses/ directory alongside the root LICENSE, which indicates bundled third-party components with their own terms. Read both before shipping, and treat the licenses/ contents as the authoritative list of what else applies. This is a description of the files, not legal advice.

## Conclusion

Adopt JetLinks Community if your team already writes Java and Spring Boot and you want protocol adapters, a unified thing model and a rule engine in one codebase you can modify. Do not adopt it if you need a managed cloud service, cannot operate PostgreSQL, Redis and TimescaleDB, or expect English documentation to match the Chinese README. Before committing, verify the docker/run-all environment starts on your machine, confirm which optional stores your workload needs, and read the Apache-2.0 LICENSE and the licenses/ directory for the bundled dependencies.

## FAQ

### What is JetLinks Community and who is it for?

It is an open source, Apache-2.0 enterprise IoT base platform built on Java 17, Spring Boot 3.x, WebFlux, Netty, Vert.x and Reactor. It targets Java teams that want unified device access across MQTT, TCP, UDP, CoAP and HTTP, a unified thing model, a rule engine and data forwarding, with source available for secondary development.

### What do I need to run JetLinks Community?

The README states the minimal runtime is Java 17, Redis and TimescaleDB, plus PostgreSQL for business data as listed in the technology stack. The docker directory provides a dev-env setup and a run-all setup that exposes the system at http://localhost:8848.

### Which protocols does JetLinks Community support for device access?

The README lists TCP, UDP, MQTT, HTTP, TLS and DTLS under unified device access, and the repository has a network-component covering MQTT, TCP, CoAP and UDP plus a protocol-component for protocol handling.

## Sources

- [jetlinks/jetlinks-community on GitHub](https://github.com/jetlinks/jetlinks-community)
- [License: Apache-2.0](https://github.com/jetlinks/jetlinks-community/blob/2.11/LICENSE)
- [Project website](https://www.jetlinks.cn/)
- [README](https://github.com/jetlinks/jetlinks-community/blob/2.11/README.md)
- [Releases](https://github.com/jetlinks/jetlinks-community/releases)

---

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