ThingsBoard v4.4 puts licensing ahead of your first customer dashboard
ThingsBoard's current README identifies v4.4 as source available under BUSL 1.1. The production-use grant caps commercial use without charge at 100 devices on one server, with branding retained and a vendor-issued license key. Noncommercial use has a 1,000-device ceiling. Earlier releases remain Apache-licensed. If your purchasing brief requires unrestricted open-source production use, that distinction can end the evaluation before you connect a sensor.
The engineering commitment deserves similar attention. Our checkout occupied 171.9 MB across 13,347 files before installation. ThingsBoard combines device records with customer dashboards and rules that react to incoming readings. That shared model can save you from writing the surrounding application. Adopting the whole platform for a temperature graph, though, gives you much more software to maintain than the graph requires.
Customer ownership makes this more useful than a charting library
The README's getting-started path connects a device, sends readings, then creates a customer and assigns a dashboard. That last step matters if you run equipment for other organizations. The platform models relationships among devices and assets, while rule chains process events and trigger alarms. A facilities application could associate sensors with a building and expose its dashboard to the relevant customer. That's an example of the documented model.
Customizing this application means navigating roughly 1,164,194 source lines in the measured repository. Built-in widgets and rule chains are therefore worth trying before changing source. I'd choose ThingsBoard when its existing ownership model matches the service I'm delivering. If I already have device identity, customer permissions, and storage working elsewhere, I'd be reluctant to duplicate those responsibilities merely to obtain another dashboard editor.
What happened when we ran it
Our sandbox installed the UI at commit adbf8b2 in 65 seconds, adding 1,510 packages and using 1,037 MB on disk. The build succeeded in 186 seconds. We ran this path on October 14, 2026, in a fresh Debian container with 3 CPUs and 8 GB of RAM, using image lab-node:22 without elevated privileges or secrets. The measured Node/Yarn project lived in ./ui-ngx/.
Tests were skipped because the measured path supplied no test script or target. The scan recorded 3 CI workflow files, no Dockerfile, and no tests directory. The record establishes a successful UI install and build; it contains no server startup result, connected-device exercise, or measured telemetry workload. It provides no passing test result.
The server needs Java and storage beyond the UI build
Release v4.4 migrated the server to Java 25. The current Ubuntu deployment guide also requires PostgreSQL configuration and a choice of message queue. It warns against the default in-memory queue for production and describes Kafka options. Database credentials belong in the server configuration. You own those operating requirements. The README's main documentation links lead into the Professional Edition path, so check the release and edition before following an older tutorial.
Our 8 GB sandbox allocation describes the environment that compiled the UI. It isn't a memory recommendation for a running installation with storage and a queue beside it. Likewise, the 1,037 MB installed footprint excludes any storage growth from device readings. Before choosing a host, decide how long readings must survive and how you'll recover the database. None of those decisions can be priced from a successful browser-code build.
Gateway movement and Edge failures deserve a trial with your devices
Open issue 16290 asks for a relationship that tracks the gateway currently carrying a device's data. The report says the existing creation relationship remains tied to the original gateway when devices move. For roaming equipment, that affects whether the device list answers a basic operational question: which gateway is serving this sensor? The reporter suggests sending gateway information as telemetry or attributes and building the relationship through a rule chain.
Open issue 16280 reports an Edge uplink stall after an attribute update fails server validation, leaving later telemetry behind the rejected batch. That's a user report, not a failure reproduced in our sandbox. Our 186-second UI build doesn't establish anything about that path. If remote sites depend on Edge, I would make malformed attributes and recovery part of the adoption trial before trusting a healthy-looking dashboard.
October activity shows maintenance, with operational reports still open
GitHub recorded the last push on October 16, 2026, with 22,563 stars and 332 open issues and PRs. The latest release, v4.4, shipped September 29. The gateway request was updated October 13 and the Edge report October 12. Together, the push date and recent issue activity support an actively maintained project. The combined queue is not a bug count. A recent push doesn't establish that either report is resolved.
The documentation gives you concrete deployment choices, and the release notes describe changes to both server and interface. Still, the 3 CI workflow files recorded by our scan cannot substitute for a result on the behavior you intend to customize. With no test target exercised in our UI run, I'd ask how a proposed dashboard or rule change will be checked before agreeing to maintain a fork.
Node-RED suits event wiring; Grafana suits an existing data store
Node-RED is the alternative I'd evaluate when the work is chiefly routing events and calling services. Grafana makes more sense when readings already reach a database and visualization is the missing piece. Neither choice supplies the same complete device-and-customer application. That's acceptable when your existing stack already handles those jobs, and it avoids introducing a second place to manage ownership.
ThingsBoard earned a successful frontend build in our run, with 1,510 packages installed along the way. I'd shortlist it for a customer-facing equipment service whose device model fits, provided the license fits too. Make the next trial follow a reading through to the correct customer's dashboard, then interrupt the path and recover it. A fleet operator needs to know where a missing reading went, especially when the browser still looks fine.