ThingsBoard

Last reviewed Aug 26, 2026 · 877 words

Your first device in ThingsBoard takes about 10 minutes: one container, one access token, one MQTT publish to v1/devices/me/telemetry, and the value appears on a dashboard. Your first useful rule chain takes a weekend. That ratio is the whole character of the platform. It is the open-source answer to AWS IoT Core, built for hundreds of devices across multiple tenants, and it costs 2 GB of RAM before a single sensor connects. For a smart home it is the wrong tool. For a fleet of sensors you built yourself, it is the best self-hosted one there is.

Home Assistant is for a house; ThingsBoard is for a fleet

Home Assistant is about integrating products you bought: lights, thermostats, a doorbell. ThingsBoard has no integrations in that sense. It expects devices to speak to it directly over MQTT, CoAP, or HTTP, using a token it issued, and in return it gives you device provisioning, per-device attributes, telemetry history, alarms, customer-facing dashboards, and multi-tenancy. The person it fits is running 40 ESP32 boards on a farm, a building's worth of energy meters, or a small product with paying customers who need their own login. If your devices have a Zigbee logo on them, stop here and go to the home automation category; Home Assistant will make you happier by lunchtime.

One container, 4 ports, 2 GB

The community image bundles PostgreSQL, which is the right choice for anything under a few thousand devices:

services:
  thingsboard:
    image: thingsboard/tb-postgres
    ports:
      - "8080:9090"
      - "1883:1883"
      - "7070:7070"
      - "5683-5688:5683-5688/udp"
    environment:
      TB_QUEUE_TYPE: in-memory
    volumes:
      - ./tb-data:/data
      - ./tb-logs:/var/log/thingsboard
    restart: unless-stopped

The web UI is on 8080 (the container listens on 9090 internally), MQTT on 1883, CoAP on the UDP range, and 7070 is the edge RPC port you can drop if you're not using ThingsBoard Edge. The two volume directories must be owned by UID 799 before the first start (chown -R 799:799 tb-data tb-logs) or the container exits with a permissions error, which is the most common first-run failure. Give it 2 GB of RAM and a minute to boot; it's a Java application and behaves like one. The catalogue's "Hard" rating is earned by the concepts, not the install.

Three accounts exist out of the box: [email protected], [email protected], and [email protected], each with the part before the @ as the password. Change all three before the container is reachable from anything but your own machine.

The first device is a token and one publish

Log in as the tenant, add a device, copy its access token. The token is the MQTT username, with no password:

mosquitto_pub -h tb.example.com -p 1883 -u "$ACCESS_TOKEN" \
  -t v1/devices/me/telemetry -m '{"temperature":21.4,"humidity":48}'

The keys become telemetry series on the device immediately, and the "latest telemetry" tab shows them. Drop a time-series chart widget on a dashboard, bind it to the device and the temperature key, and you're done with the part that impresses people. If you already run an MQTT broker and don't want devices talking to ThingsBoard directly, an EMQX or Mosquitto bridge republishing into ThingsBoard's topics keeps your existing topology.

Rule chains are where the weekend goes

Everything a device sends passes through the tenant's root rule chain, a node graph where you filter, transform, enrich, raise alarms, and forward. Want an alert when a freezer stays above -15 °C for 10 minutes, and a Telegram message, and a copy of the raw telemetry into InfluxDB? That is 6 or 7 nodes, and getting them to fire in the right order with the right metadata is the part where the documentation is thorough and the UI is unforgiving. If you've built flows in Node-RED the model is familiar; the difference is that rule chains are per-tenant, versioned, and run inside the platform rather than beside it. Budget the weekend and keep a scratch device that publishes fake data while you learn.

Community edition covers the fleet; PE covers the business

The Apache-2.0 community edition includes devices, assets, dashboards, rule chains, alarms, and multi-tenancy. The paid Professional Edition adds white-labelling, a scheduler, and the platform integrations (LoRaWAN network servers, cloud IoT hubs, and so on) that let you ingest from things you don't control. For a homelab or a small deployment the community edition is complete; the integration layer is the feature you'd miss first if you outgrew it.

What I'd do

Only if I had devices I built or programmed myself, and more than a dozen of them. Then: the tb-postgres image on a box with 4 GB free, default passwords changed in the first 5 minutes, one dashboard per device type, and the rule chain built incrementally with a fake device feeding it. For everything else, Home Assistant plus a plain MQTT broker gives you 80% of the outcome for a quarter of the RAM and none of the tenancy concepts you don't need.