ThingsBoard replaces several IoT services at once
ThingsBoard gives each device an identity, accepts telemetry, stores attributes, and displays current or historical values in dashboards. Operators can model devices, assets, customers, and relations between them. Rule chains transform incoming data, test conditions, raise alarms, send notifications, or call back to devices. That is a useful package when a team would otherwise assemble a broker, API, database, rules service, and customer portal.
The same scope makes it excessive for a few sensors. A small MQTT deployment can route messages with far less state. ThingsBoard becomes attractive when users need permissions, tenant separation, reusable widgets, alarm workflows, or device provisioning alongside transport. Its repository includes separate services for HTTP, MQTT, CoAP, LwM2M, and SNMP in the microservices layout. Each protocol adds ports, certificates, device behavior, and failure cases that the platform owner still has to test.
What happened when we ran it
Our lab did not build the whole Java repository. We entered ui-ngx at commit 5b64385 and ran the frontend workflow in a 3-CPU, 8 GB Debian container. Yarn installed 1,453 packages in 108 seconds and left 963 MB on disk. The Angular production build then completed successfully in 108 seconds.
Tests were skipped because ui-ngx/package.json exposed no test script or target. It has scripts for development serving, production builds, linting, type generation, icon metadata, and dependency patch preparation, but none gave our harness a test command. The result therefore proves that this frontend compiled in our sandbox. It says nothing about browser behavior, Java unit tests, database migrations, device transports, or an end-to-end telemetry flow.
The checkout had 9,685 files, about 871,899 lines of source, and occupied 97 MB. Our scan found 2 CI workflow files, no Dockerfile at the repository root, and no root tests directory. The measured frontend dependency tree is almost 10 times the checkout size on disk. That cost is manageable in CI, but contributors should cache it and avoid treating a successful Angular build as platform verification.
The monolith is the sensible first deployment
ThingsBoard documents on-premises installation and a hosted cloud option. For a self-hosted evaluation, the monolith keeps the number of moving parts lower while a team learns the device model, rule engine, and dashboard editor. A real deployment still needs persistent database storage, backups, TLS, a mail path for notifications, administrator accounts, and exposed ports for whichever device protocols are enabled.
The repository also ships a Docker Compose setup for microservices. Its installer asks operators to choose PostgreSQL alone or a hybrid with PostgreSQL for entities and Cassandra for time-series data. Cache options include one Valkey node, a 6-node cluster, or a sentinel arrangement. The Compose tree then separates core, rule engine, web UI, JavaScript execution, and transport services. That is an operations platform, not a one-container shortcut.
Default credentials make the first login urgent
The microservices Docker guide publishes sysadmin@thingsboard.org with password sysadmin. Loading demo data adds tenant and customer accounts with equally obvious passwords. Those credentials are helpful on localhost and dangerous on any reachable host. Change them before opening device or web ports beyond a trusted network, and do not preserve demo identities in a production database.
Server configuration covers JWT signing, OAuth, TLS certificates, mail, WebSocket limits, API rate limits, database backends, Cassandra credentials, and queue behavior. Some browser defenses need deliberate choices because dashboards may be embedded and custom widgets can load scripts or external resources. The current configuration leaves frame protection and Content Security Policy disabled by default for compatibility. Operators should test stricter settings against their exact widget set instead of assuming the defaults match their threat model.
Release 4.3.1.4 is a security maintenance signal
GitHub showed 22,327 stars, 295 combined issues and pull requests, and a last push on August 29, 2026. Release v4.3.1.4 arrived on August 27. Its security section lists a large set of CVEs fixed across several pull requests, followed by UI corrections for charts, translations, validation, and calculated fields. Recent release and issue activity point to ongoing maintenance.
The size of that security list also changes the buyer's duty. An internet-facing IoT platform handles device credentials, tenant data, dashboards, APIs, and commands to hardware. Patch review cannot wait for an annual maintenance window. Teams should track both the chosen release line and main-branch fixes, rehearse database upgrades, and keep a rollback path. Apache 2.0 licensing permits commercial modification, but the licence does not transfer operating responsibility to the maintainers.
Current issues show where end-to-end tests matter
Issue 16076 reports that two Carto-based map layers began showing an API-key watermark after the upstream basemap service changed access rules. Pull request 15363 addresses dashboard subscriptions that can stop updating after a WebSocket reconnect, particularly around mobile sleep or a server restart. The pull request's manual test checklist was still unchecked when fetched, so it should not be treated as a shipped, verified fix.
Both examples cross component boundaries. A TypeScript build will not detect a changed map provider policy, and a unit test may miss a browser sleep and reconnect sequence. Before adoption, connect a real device, interrupt its network, restart the server, rotate credentials, exercise an alarm, and verify dashboards recover. Our 108-second UI build is a useful contributor baseline, while a production decision needs that full path on the intended database and transport.