Category: IoT
Managed ThingsBoard in your account: telemetry, queues and upgrades kept current
Your ThingsBoard platform in your cloud account or on your servers, with queues that do not get stuck, telemetry that does not fill the disk and planned upgrades.
- Where it runs
- In your account, in your name
- Backups
- With tested restores
- Updates
- Planned and documented
- Licence
- BUSL 1.1 since 4.4 (free with limits or commercial); 4.3 LTS, Apache 2.0
In short
ThingsBoard is an IoT platform for connecting devices, collecting their telemetry, processing it with rule chains and showing it on dashboards. We install it on your provider, on a single server or as microservices with high availability, with well-sized Kafka and PostgreSQL. We monitor the queues and ingestion, take backups that we restore in tests and apply upgrades following the official guide.
What do we take care of?
ThingsBoard works well as long as device messages enter and leave the queues at the same pace. When a rule chain gets stuck, the database grows without limit or an upgrade is postponed for too long, the dashboards stop showing recent data. Our job is to find out before you do.
Transports
MQTT, HTTP, CoAP and LwM2M with TLS, connection limits and per-device credentials.
Queues
Kafka with partitions and retention set to the load, and the lag of each queue monitored.
Rule engine
Failed and timed-out messages per rule chain, with alerts when they rise.
Database
PostgreSQL, or Cassandra for telemetry, with retention defined and tested backups.
Ingestion
Messages per second, connected devices and a warning when a group stops sending.
Upgrades
ThingsBoard and its dependencies kept up to date, with the migration rehearsed.
What architecture do we recommend?
For a few hundred devices, ThingsBoard on a single server with PostgreSQL and off-site backups is usually enough, if some downtime is acceptable. When it cannot stop or the volume grows, we split it into microservices: transports, core and rule engine in several replicas behind a load balancer, with Kafka between them and replicated PostgreSQL. The in-memory queue it ships with by default is only good for testing: in production, Kafka.
| Situation | What we set up | Why |
|---|---|---|
| Pilot or few devices | One server with ThingsBoard, PostgreSQL and off-site backups | Simple and cheap, with tested recovery |
| Production that cannot stop | Microservices on Kubernetes, Kafka with three brokers and PostgreSQL with a replica | Losing a node does not cut off ingestion |
| A lot of telemetry or long retention | The above, with Cassandra for telemetry | Massive writes without bloating PostgreSQL |
High availability is optional: we propose it when losing a few minutes of data or leaving the dashboards without updates has a real cost for you.
Who is it for?
- Manufacturers of connected equipment: they sell machines or sensors with telemetry and want to offer dashboards to their customers without building a platform of their own.
- Maintenance or service companies: they monitor scattered installations, such as pumps, tanks or cold rooms, and need reliable alarms.
- Teams already trying ThingsBoard: they have a pilot on one server and want to take it to production with backups, alerts and upgrades from someone who answers for them.
What problems do we come across most often?
- In-memory queue in production: if the process restarts, the messages in flight are lost.
- Telemetry with no retention: the database grows every day until it fills the disk.
- Rule chains with slow nodes: a slow external call blocks the queue and data arrives late.
- One credential for all devices: you cannot remove one without touching the rest.
- MQTT without TLS open to the internet: anyone can try to connect or read the traffic.
- An old version with no patches: the upgrade keeps being postponed because nobody has tested the migration.
How do we handle backups and upgrades?
We back up PostgreSQL with continuous archiving so it can be taken back to a specific point in time, as we explain in managed PostgreSQL, and if there is Cassandra, its snapshots. Rule chains, device profiles and dashboards are also exported to a repository, with ThingsBoard’s version control or as JSON, so they can be recreated without relying on the database. We regularly restore into a test environment and check that the test devices connect and their data appears.
Every upgrade migrates the database schema. Beforehand we read the release notes, take a backup, rehearse the migration with a real copy in a separate environment and then upgrade in an announced window; with microservices, one service at a time when the version allows it. Kafka retains the messages that arrive during the interruption, so no telemetry is lost.
What is day-to-day support like?
ThingsBoard, Kafka and database metrics go to Prometheus and Grafana, as we describe in monitoring with Grafana and Prometheus, with alerts for queue lag, failed rule messages, drops in ingestion and disk. We run Kafka with the same care as in managed Kafka. Automated monitoring is continuous; human response is next business day during business hours, as part of SRE as a service. Every month you receive a report with versions, incidents, telemetry growth and changes made.
- Devices and gatewaysMQTT, HTTP, CoAP or LwM2M
- ThingsBoard transportsTLS and per-device credentials
- KafkaQueues with monitored lag
- Core and rule engineSeveral replicas for high availability
- PostgreSQLEntities and telemetry, or Cassandra
- PrometheusMetrics and alerts
Where do we set it up?
In your account, with the provider you already use or the one that fits best. If the data has to stay in the EU, Hetzner and OVHcloud are the European options.
Providers we set it up on
- Hetzner
- AWS
- Google Cloud
- Azure
- DigitalOcean
- OVH
- Own server
| Provider | How we set it up | Things to bear in mind |
|---|---|---|
| Hetzner | Cloud or dedicated servers with ThingsBoard on Docker or Kubernetes, and PostgreSQL and Kafka set up by us on a private network. | Hetzner has no managed database or Kafka: we provide the high availability and backups ourselves. |
| AWS | ThingsBoard on EKS or EC2, with RDS for PostgreSQL and Amazon MSK if they fit, or with self-run Kafka. | We review the cost of cross-zone traffic, which adds up with a lot of telemetry. |
| Google Cloud | ThingsBoard on GKE, with Cloud SQL for PostgreSQL and managed or self-run Kafka. | |
| Azure | ThingsBoard on AKS, with Azure Database for PostgreSQL and self-run Kafka in the cluster. | |
| DigitalOcean | ThingsBoard on Droplets or DOKS, with DigitalOcean managed PostgreSQL and Kafka. | A simple option for small and medium installations. |
| OVH | ThingsBoard on Public Cloud or Managed Kubernetes, with OVHcloud managed databases. | |
| Own server | ThingsBoard on your servers or virtual machines, next to the devices' network. | If the devices are on the factory floor, we consider leaving ThingsBoard Edge on site and the main server in the cloud. |
What is included
- ThingsBoard in your cloud account or on your server, as a monolith or as microservices depending on the number of devices, with the installation described as code.
- Kafka as the message queue in production, with topics, partitions and retention tuned to the real load.
- PostgreSQL for entities and telemetry, or Cassandra for telemetry when the volume calls for it, with retention (TTL) defined.
- MQTT, HTTP, CoAP or LwM2M transports with TLS, and per-device credentials instead of a shared one.
- ThingsBoard metrics in Prometheus: queue lag, failed or timed-out rule messages, connected devices and disk.
- PostgreSQL backups with point-in-time recovery and export of rule chains and dashboards, with a test restore.
- Version upgrades with the database migration rehearsed first in a separate environment.
- Trendz Analytics installed and connected to ThingsBoard when you use it, with its own licence.
Frequently asked questions
What changes with the ThingsBoard 4.4 licence?
Since version 4.4, Community and Professional are a single product under the BUSL 1.1 licence: the code is still public, the free licence for commercial use has limits on devices and servers, and above them a commercial licence is needed. 4.3 LTS stays on Apache 2.0 and receives security patches until July 2027. If you already run Community, we review the Community Grant programme together and when it makes sense for you to move to 4.4.
Who pays for the ThingsBoard licence?
You do, directly with ThingsBoard, when your case needs one. We do not resell licences: we charge for running the platform. That way the licence is in your name and does not depend on us.
Do we need Cassandra to store telemetry?
Usually not. PostgreSQL stores the telemetry of many installations well if retention is defined and the disk is monitored. Cassandra makes sense when the write volume is very high or retention is long, at the cost of running one more cluster. We decide based on your load data, not out of habit.
Is ThingsBoard Cloud or ThingsBoard in our own account better for us?
ThingsBoard Cloud takes maintenance off your hands, and it is usually enough to get started. ThingsBoard in your account makes sense when the data must stay with your provider or on your servers, when you need to integrate it with your private network or when the number of devices makes it cheaper for you to run it yourselves, or for someone to run it for you.
Is Trendz Analytics installed separately?
Yes. Trendz Analytics is a ThingsBoard add-on for analytics and predictions on telemetry, with its own licence, which you also take out yourselves. We install it alongside ThingsBoard, connect it and include it in backups and upgrades; first we check that the Trendz version is compatible with your ThingsBoard version.
Tell us about your case
In a free 20-minute call we look at where you are and where to start. No commitment.
Official documentation consulted
The technical details on this page are based on:
Reviewed on