Containers on the Plant Floor: What Changes When a Gateway Runs Docker

An industrial gateway that runs containers is a different kind of device from one that runs firmware, and the difference is not mainly technical. A firmware device does one thing for its service life and is replaced when that thing is no longer enough. A container host is infrastructure: it accepts new workloads, it accumulates state, it has an operating system with a patch cadence, and somebody now owns all of that. The capability is genuinely valuable and the ownership is genuinely new, and projects go wrong when the first is bought without the second being staffed.

Start with what actually improves. Deployment stops being a site visit. A protocol adapter, an analytics job and a buffering agent can run on one box without their dependencies fighting, which on a plain Linux gateway they eventually will. Rolling a new version out to four hundred sites becomes an operation rather than an expedition. And the same artefact runs on a developer's laptop and on the cabinet device, which removes the most tedious category of bug — the one that only appears on the target.

Then the parts that become your problem. A container image contains an operating system userland, and every library in it has a vulnerability history. A base image chosen in 2026 and never rebuilt is, three years later, a list of known CVEs sitting in a cabinet on a plant network. Rebuilding images on a schedule is not optional maintenance; it is the cost of having chosen this architecture. So is knowing what is in them, which is the same software-bill-of-materials discipline that product regulation is converging on anyway.

Storage is the failure that surprises people. Containers write logs, and industrial gateways have small flash devices with finite write endurance. A chatty application with default logging can fill a partition in weeks and wear out the flash in a couple of years. Log rotation, size limits and a deliberate decision about what gets written to local storage at all belong in the first deployment, not in the incident review.

Restart behaviour deserves the same care. The default for a container is to be restarted when it exits, which is right for a stateless web service and can be wrong at the edge: a process that crashes because a serial port is missing will crash-loop forever, consuming CPU and filling logs, while the actual problem — a cable — goes unreported. Decide what should happen after the third failure in five minutes, and make sure the answer reaches a human rather than a log file nobody reads.

The network model is the one that catches people who came from the IT side. A container gets a virtual network by default, and a gateway's job is usually to talk to things on a physical one — a fieldbus adapter, a serial converter, a device on a specific VLAN. Getting a container onto the plant network with a predictable address, or giving it access to a device node, is a solved problem but not the default one, and the way you solve it becomes an architectural commitment that is awkward to revisit later.

Time is worth checking too. Containers inherit the host clock, and correlating an event on a gateway with an event in a historian requires both to agree about what time it is. An industrial site with no reliable time source produces logs that cannot be lined up, which turns a two-hour investigation into a two-day one.

Then there is the update path itself, which is the whole reason for the architecture and the part most often left until last. Somebody has to decide how a device learns that a new image exists, what happens when the download is interrupted by a link that drops twice a day, whether a failed update rolls back automatically, and how you find out that ninety-six of four hundred sites are still on the old version. None of that is provided by a container runtime. It comes from a device management layer, and choosing that layer is a bigger decision than choosing the runtime — it is the thing you will still be living with in five years.

A reasonable way to scope a first deployment. Put one workload in a container rather than three, so the operational questions arrive one at a time. Pin base images and set a rebuild schedule before you ship. Cap logs and decide what local storage is for. Name the person who gets told when a container stops. And run the whole thing on ten devices for a full maintenance cycle, including a power cut and a network outage, before it goes to four hundred.

Containers at the edge are the right architecture for most gateway workloads. They are also a commitment to running a small fleet of Linux machines in places with no IT staff, which is a fair trade as long as it is made deliberately.