Category: IoT
Managed IoT platform with MQTT: broker, flows, time series and dashboards
An MQTT broker, flows that transform the data, a time series database and dashboards: open components that we manage as a single platform in your account.
- Where it runs
- In your account, in your name
- Backups
- With tested restores
- Updates
- Planned and documented
- Licence
- Open source (Mosquitto, Node-RED, InfluxDB 3 Core, Grafana); EMQX 5.9 or later, BSL 1.1
In short
A tailored IoT platform brings together open source components: an MQTT broker (Mosquitto or EMQX) that receives messages from the devices, Node-RED to transform and move them, TimescaleDB or InfluxDB to store the time series and Grafana for dashboards and alerts. We set it up in your account with TLS and per-device permissions, and we answer for the backups, monitoring and upgrades of the whole stack.
What do we take care of?
An IoT stack built from open components usually starts as a test on a server and ends up in production without anyone having prepared it for that. The risk is not in each component but in the joins: a Node-RED flow that stops, a broker that discards messages or a disk that fills up with telemetry.
MQTT broker
Mosquitto or EMQX with TLS, per-device authentication and per-topic ACLs.
Node-RED
Flows in a repository, a protected editor and encrypted credentials.
Time series
TimescaleDB or InfluxDB with retention and compression based on usage.
Grafana
Per-site dashboards and alerts on values and on silent sensors.
Ingestion
Messages per second, connected clients and discarded messages in the broker.
Upgrades
Pinned versions for each component, tested together and upgraded in order.
What architecture do we recommend?
Devices publish to the broker over MQTT with TLS. Node-RED subscribes to the topics, validates and transforms the messages and writes them to the time series database; Grafana reads from it for dashboards and alerts. Each component in its own container, the configuration in the repository and the database backed up off the server.
| Situation | What we set up | Why |
|---|---|---|
| Hundreds or a few thousand devices | Mosquitto, Node-RED, TimescaleDB and Grafana on one server | Simple, cheap and easy to recover |
| Many connections or no tolerance for outages | EMQX cluster with its licence, or several Mosquitto instances by device group | More connections and no single point of failure |
| Measurements for dashboards only | InfluxDB instead of TimescaleDB | Very straightforward writing and querying of metrics |
The unencrypted MQTT port is not opened to the internet. Since Mosquitto 2.0, without explicit configuration it only listens locally and does not accept anonymous connections, and we leave it that way: every listener declared, with its own authentication.
Who is it for?
- Industrial companies with machines or sensors on the shop floor: they want to see consumption, temperatures or stoppages on their own dashboards, without paying for a platform per device.
- Product teams adding telemetry: their application needs to receive data from equipment in the field and they prefer standard components they know.
- Anyone who already has the stack built by hand: it runs on a server, but with no backups, no TLS or nobody to upgrade it.
What problems do we come across most often?
- MQTT without TLS and with a shared user: every device uses the same password and can publish to any topic.
- Node-RED flows only on the server: with no repository or backup, an editing mistake cannot be undone.
- Telemetry with no retention: the database grows until it fills the disk and ingestion stops.
- Silent sensors nobody notices: the dashboard shows the last value and everything seems fine.
- Images tagged latest: a restart changes version without anyone having tested it.
- Everything on the same disk: the database, the backups and the logs share a volume.
How do we handle backups and upgrades?
We back up the time series database off the server: TimescaleDB with continuous archiving and point-in-time recovery, as in managed PostgreSQL, and InfluxDB with its own backups. The Node-RED flows, the broker configuration and ACLs, and the Grafana dashboards live in the repository. We regularly restore into a test environment and check that a test message makes it from the broker to the dashboard.
We pin the version of each component, read the notes before changing it and test the whole stack in a separate environment. We upgrade one component at a time, starting with the stateless ones, and check that ingestion does not drop after the change.
What does day-to-day support look like?
Metrics from the broker, Node-RED and the database go to Prometheus and Grafana, as we describe in monitoring with Grafana and Prometheus, with alerts on disconnected clients, discarded messages, sensors that stop reporting and disk. If the messages then need to flow on to other systems in large volumes, we send them through Kafka. Automatic monitoring is continuous; human response is the 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 over TLS
- Mosquitto or EMQXBroker with per-topic ACLs
- Node-REDTransforms and routes
- TimescaleDB or InfluxDBTime series
- GrafanaDashboards 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 servers with the components in Docker or Kubernetes, on a private network, and backups in Hetzner Object Storage. | Very economical for telemetry; we operate the broker and the database ourselves. |
| AWS | The components on EC2 or EKS, with TimescaleDB on your own PostgreSQL. AWS IoT Core can act as the broker if it suits you. | AWS IoT Core charges per message and connection: we compare it with your own broker at your volume. |
| Google Cloud | The components on Compute Engine or GKE, with backups in Cloud Storage. | |
| Azure | The components on virtual machines or AKS, with backups in Blob Storage. | Event Grid supports MQTT; we consider it if the rest of your platform is already on Azure. |
| DigitalOcean | The components on Droplets or DOKS, with Spaces as object storage. | |
| OVH | The components on Public Cloud instances or Managed Kubernetes, with S3-compatible Object Storage. | |
| Own server | The platform on a server at the plant or in the office, close to the devices. | If the internet connection drops, data keeps being stored locally; the backups go off site. |
What is included
- MQTT broker with Mosquitto, or EMQX when you need many connections, with TLS and per-device users or certificates.
- Per-topic permissions (ACLs): each device publishes only to its own topics and each application reads only what it needs.
- Node-RED with the editor protected by a password or by your single sign-on, and the flows stored in a repository.
- TimescaleDB or InfluxDB for telemetry, with defined retention, compression or downsampling of old data.
- Grafana with per-site dashboards and alerts for out-of-range values or sensors that stop reporting.
- Backups of the database, the flows and the broker configuration, with a test restore.
- Metrics for the broker, Node-RED and the database, with alerts on dropped connections, discarded messages and disk.
- Upgrades of each component rehearsed together in a separate environment, with the platform described as code.
Frequently asked questions
Mosquitto or EMQX?
Mosquitto is lightweight, very stable and enough for most installations with hundreds or a few thousand devices, but its open source version does not cluster. EMQX scales to many more connections and comes with a dashboard, rules and clustering, but since version 5.9 it has a BSL 1.1 licence: a single node can be used free of charge in production and a cluster needs a commercial licence. The Open Source versions up to 5.8 remain under Apache 2.0, although with no new releases.
TimescaleDB or InfluxDB for telemetry?
TimescaleDB is a PostgreSQL extension: SQL queries, joins with your other tables and the same backups as any PostgreSQL. InfluxDB is a database dedicated to time series, very convenient for writing and querying metrics. If you already use PostgreSQL or want to combine telemetry with business data, TimescaleDB; if you only store measurements and look at them in Grafana, either will do.
Is Node-RED fit for production?
Yes, if it is treated as code: a protected editor, flows in a repository with change review, encrypted credentials and a test environment before touching production. What you should avoid is editing flows live on the production server without a backup.
Why your own stack rather than a complete IoT platform?
Your own stack is lighter, has no per-device licences and every component can be swapped for another. In exchange, device management, dashboards for your customers and per-user permissions have to be built. If you need that ready-made, a platform such as ThingsBoard may be a better fit; we will tell you once we have seen your case.
What happens to messages if the broker goes down?
Properly configured devices reconnect on their own and, with QoS 1 or 2 and persistent sessions, the broker delivers pending messages to subscribers when it comes back. Whatever the device does not store while there is no connection is lost, which is why we also review the client configuration, not just the broker's.
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