3 Aug 2026 · 4 min read
United Manufacturing Hub, explained for the person who has to maintain it
uns · mqtt · architecture · scada · automation · open-source
The pitch is one Docker container. Point it at your PLCs, get a Unified Namespace, done.
That is the second version. The first one needed a Kubernetes cluster, and the reason they tore it out is the most useful thing about the project — because it reads like a list of everything that goes wrong when a data-centre pattern meets a plant floor.
What it actually is
United Manufacturing Hub is an open-source platform for getting data off machines and onto a common bus.
WHO IS BEHIND IT
three founders, Germany
January 2026, led by KOMPAS VC
not a lab project
their code; the broker is not — see below
The current product, UMH Core, is a single container with four processes in it.
ONE BOUNDARY, FOUR PROCESSES
Only two of those four are UMH's own code. The broker is Redpanda and the supervisor is S6, both borrowed. That is the right instinct at this layer: an integration platform that writes its own message bus is asking a plant to bet uptime on the least-tested component in the building.
The complaint it was founded on
Their own documentation is blunter than most vendor writing, and it is worth quoting because it explains the shape of everything else:
very often these solutions do not target the actual pains of an engineer: implementation and maintenance
That is the whole thesis. Not connectivity — connectivity was solved by OPC UA and MQTT years ago. The claim is that IIoT platforms are sold on what they can do in a demo and priced on what they cost to keep running, and that nobody optimises for the second number.
Whether they deliver on it is a separate question. But it is an unusual thing to found a company on, and it is the correct complaint.
The Kubernetes they threw away
UMH Classic was a Helm chart. You got Kafka, HiveMQ, Node-RED, TimescaleDB and Grafana, orchestrated on Kubernetes, and on paper it was the modern answer.
Then it met actual factories. Their own list of what broke:
CLASSIC → CORE
Read the third one twice, because it is the one that costs you a night. A
Kubernetes pod reports Running when the process has started, not when the
thing is working. So a data flow can be silently dead while every dashboard is
green, and finding out means correlating pod logs, kubectl events and a load
balancer. Anyone who has chased a stuck OPC UA subscription through three
layers of abstraction knows exactly what that evening looks like.
The fix was to stop distributing the problem. One container, one process supervisor, one config file, one place to look. Kubernetes became — their phrase — an optional scheduler, not a hard dependency. You can still run it on k8s. You no longer have to explain k8s to the person covering your holiday.
I want to be fair about the trade: they gave up real things. Per-component scaling, rolling upgrades of one piece, the whole k8s operational toolbox. Their argument is that a plant deploys per production line anyway, so you scale by adding containers rather than pods, and a container manager restarts a crash in 30–60 seconds. For one line in one building, that is enough.
What you actually get
Every message lands at an address, and the address is the model.
ONE ADDRESS, SIX PARTS
I ran this against a live estate: 86 assets and 1,014 tags, Modbus and MQTT in one hierarchy, not a line of it declared anywhere. One substring query crosses both protocols. The full write-up is here, including where it fell over.
The _contract segment is the part most UNS deployments never build. It states
what kind of thing the message is, and it can enforce a model — a station
either publishes the fields its contract requires or the message is rejected.
That is the whole difference between a designed namespace and a topic tree
somebody typed into a broker, which is what most of them are.
What it deliberately isn't
Core does not store anything. Classic bundled TimescaleDB and Grafana; Core pushes both out to a separate package, and their reasoning is sound — plants already run their own Grafana, and an auto-upgrade that breaks somebody's dashboards at 2 a.m. is a bad trade for convenience.
The upshot is that UMH Core is a data plane, not a system. You still need somewhere to put the data and something to draw it. UMH's own advice, which I would repeat:
CORE STORES NOTHING — SO WHAT DO YOU NEED
You want to move data and build a namespace. Core does that and nothing else.
TimescaleDB and Grafana in one install, and you can live with Kubernetes.
A broker and a historian already cover you. A namespace layer buys tidiness you will pay to maintain.
One licensing detail, because it gets repeated carelessly. UMH's code is Apache-2. The broker at the centre of Core is Redpanda, which is BSL 1.1 — source-available, converting to Apache-2 four years after each merge, and barred from resale as a streaming service. Free to run on your own plant, and not the same thing as an open-source stack. If your procurement asks, that distinction matters.
Who should look at it
If you have one line, one SCADA and no plans, you do not need this. A broker and a historian cover you, and adding a namespace layer buys tidiness you will pay to maintain.
It earns its place when you have several sites naming the same asset three different ways, something downstream genuinely waiting for the data, and nobody who wants to hand-write another integration. That is the same test I would apply to any product at this layer — the difference is that this one costs nothing to try and runs on a spare industrial PC.
The reason I would look at it before the commercial options is not the price. It is that a team who publicly ripped out their own architecture because it was too hard to maintain in a factory has demonstrated the one thing you cannot get from a datasheet: they have been on a plant floor at three in the morning, and they took the lesson.
Keep reading
Newsletter
New essays, by email.
SCADA, cloud, AI, and the plant floor — a short email when something new is published. No noise, unsubscribe anytime.