What changes when UMH Core runs at the edge of a production line?

A workshop wants to see whether three cutting machines are running. Before it can put a status screen in the office, someone has to secure permission to read from the PLC network, decide where to process the signals and work out how another application will consume them. That is quite a bit of infrastructure for a first experiment. UMH Core offers a narrower starting point: deploy an industrial data hub as one Docker container on a machine near the production network.

This is not another discussion of the Unified Namespace data model or which industrial connectors are available. The question here is operational. What does a single-container edge gateway simplify, and what work remains after it starts? A container count is a deployment detail, not a measure of data quality or production readiness.

The point of a local boundary

Consider a hypothetical sheet metal line whose PLC network is separated from the office network. Operators know which machine is working because they can see it. Planning gets a spreadsheet updated at the end of the shift. Giving every reporting tool a direct route to every controller might make the first dashboard easier, but it also increases the number of connections the OT team must review and maintain. A gateway at the boundary can read from approved sources and publish data through a more deliberate interface.

In UMH Core that gateway is an industrial data hub. According to the project’s documentation, its container includes embedded Redpanda for Kafka-compatible messaging, Benthos-UMH for stream processing, an agent responsible for configuration and health, and S6 for supervising processes. The image may start as one Docker container, but the services inside it are distinct. If a pipeline stops while the container remains up, the response must be to inspect the relevant component rather than trusting the container’s running state.

There is a useful contrast with the older UMH Classic architecture, which uses a Kubernetes Helm deployment. Core lets a team prepare a Docker host and test one line without introducing an orchestration cluster for the pilot. That removes a layer from the first installation, not the need for ownership. Someone must still maintain the host, plan storage, keep track of versions and be able to restore service after an interruption.

Start with one signal, not the whole plant

For a pilot, choose one machine and one clearly defined state. Suppose the PLC exposes running. Does that mean the control is powered, the spindle is moving, or a good part is being made? The people operating the machine have to settle the meaning before an engineer builds a chart. The gateway can transport a bit reliably while its interpretation remains wrong. It is better to find that mismatch in one shift than after the same field has been copied into several reports.

Agree on a safe polling rate and the permitted access path with the people who own the controller. Industrial equipment is not a general-purpose test server. A new data collection process should be observed for its effect on the source as well as its usefulness to the consumer. Keep control functions and safety systems outside this experiment. UMH’s own security documentation warns that Core is not a safety-rated system.

Where the gateway runs also matters. UMH’s deployment guidance describes placing it at the OT and IT boundary in a segmented network, with firewalls defining permitted traffic. Installing the container on any host that can see both networks without documenting its routes would bypass the very review the gateway is meant to simplify. Record which system initiates each connection, which port it needs and who can alter the rules. The first pilot should be easier to audit than the collection of point-to-point links it replaces.

Edge is not the same as offline

The word “edge” sometimes suggests that the unit needs no external connection. That is not a safe assumption here. The current UMH security documentation says Core requires outbound HTTPS access to its Management Console for configuration synchronization and is not designed for fully air-gapped environments. A plant that prohibits this route has to resolve that requirement before selecting the product, not after ordering hardware. The authentication token for the instance needs controlled storage and rotation; copying it into a shared runbook is not an operational shortcut.

Sizing needs the same discipline. The getting-started documentation lists minimum compute, memory and disk requirements, but a minimum is not a capacity plan for a particular message rate and retention policy. Before placing a gateway on an existing edge PC, measure what else runs there and what happens when the disk is full. If the host is rebooted by someone outside the data team, which production records could be delayed or lost? Those questions cannot be answered from the Docker command alone.

A persistent volume is essential for the data the service needs to retain. The project’s Docker Compose example mounts /data, keeping container data separate from the image lifecycle. Yet a volume is not a backup. Record where it lives, how its contents are copied, and how the copy is restored on another host. Test the restoration with a versioned image and a known configuration; a backup that has never been used is only a claim about recoverability.

Test a failure before scaling

The broker inside the container can buffer messages, but buffering does not by itself promise unlimited retention or delivery all the way to the target application. A source might stop sending during an outage; a consumer might reject a replayed message; a machine state may be reported twice after reconnection. The team should test those cases on one line. Interrupt a connection under controlled conditions, restore it, then compare the machine’s expected transitions with records at the destination. A healthy gateway dashboard is not proof that the intended record reached its consumer.

Also rehearse an upgrade and rollback. Pin the image version, save the working configuration, note how much data is pending and decide how to return to the previous version if the new one fails. Make the steps legible to the person on duty when the original installer is away. A reliable pilot demonstrates not just a successful startup, but a recoverable interruption handled by someone other than its author.

UMH Core’s single-container packaging makes an initial edge deployment less cumbersome. It does not remove the need for a correct signal definition, a carefully controlled network boundary or an observable recovery path. Those are the criteria worth checking before expanding the pilot to the rest of the workshop.

Sources: Luke van Enkhuizen’s overview of open-source manufacturing software, UMH Core introduction, getting started and security and deployment guidance. The workshop scenario is illustrative.