Containerization on the Factory Floor: Docker and K3s for Industrial Edge

The IT world adopted containers years ago. The industrial world is catching up — but slowly, and with good reason. Factory floors are not cloud data centers. Power is unreliable, network bandwidth is limited, thermal conditions are harsh, and a container crash that takes down a vision inspection system can mean thousands of defective parts shipped before anyone notices. Containerization at the industrial edge requires a fundamentally different mindset than cloud-native development. This post covers what works, what does not, and the exact architecture patterns we deploy with our clients.

Why Containers at the Edge?

The traditional industrial software deployment model is monolithic: a Windows VM running an HMI application, a historian, and a protocol gateway, all on the same machine. Updating one component risks breaking the others. Scaling means buying another industrial PC. Containers solve this by isolating each application — protocol gateway, data processor, visualization layer — into its own lightweight runtime with explicit resource limits. Updates are atomic (replace the container, not the OS). Rollbacks are instant (keep the previous image). And resource allocation is predictable (CPU and memory limits enforced by the container runtime).

Docker vs. Podman vs. K3s: Choosing the Right Runtime

For single-node industrial edge deployments, Docker or Podman is usually sufficient. Both run containers on a single host with minimal overhead. Podman has the advantage of being daemonless (no root process), which simplifies security hardening. For multi-node deployments — say, 10 edge gateways across a production line — Kubernetes becomes relevant. But full Kubernetes is overkill for most factory floors. K3s (a lightweight Kubernetes distribution by Rancher) is the sweet spot: it runs on a single binary, uses less than 512MB of RAM, and provides the same kubectl API as production Kubernetes. We deploy K3s on industrial fanless PCs with 4GB RAM and an Intel Celeron processor — more than enough to run 5-10 containers.

The Industrial Container Stack

A typical industrial edge container deployment includes a data acquisition container (running an OPC UA client or Modbus poller), a processing container (running signal processing, filtering, or ML inference), a buffering container (local store-and-forward for when the network goes down), and a telemetry container (health metrics and logs shipped to a central monitoring system). Each container has explicit resource limits — 256MB RAM, 0.5 CPU cores — to prevent one runaway process from starving the others. The containers communicate over a local MQTT broker running in its own container, which provides decoupling and local buffering.

Persistent Storage: The Silent Killer

The biggest pitfall in industrial containerization is persistent storage. Containers are ephemeral by design — when they restart, their filesystem is wiped. But industrial applications need to persist configuration, historical data, and alarm logs. The solution is volume mounts: map a host directory into each container for data that must survive restarts. On industrial edge hardware, use an industrial-grade SSD (not a consumer SD card — they fail under write-heavy industrial workloads). Format it with ext4 and mount it at a fixed path. All containers write their persistent data to this volume. This is simple, reliable, and does not require a distributed storage system.

Network Configuration for Industrial Protocols

Industrial containers need access to plant floor networks, which often use different physical interfaces — Ethernet, serial (RS-485/RS-232), or industrial fieldbus. Docker's default bridge networking does not handle serial devices. The solution is host networking (containers share the host's network stack) or macvlan networking (containers get their own IP on the plant network). For serial devices, pass the device through to the container using the --device flag. For OPC UA over Ethernet, host networking is usually the simplest approach. The key rule: never expose the container management port (2376 for Docker, 6443 for Kubernetes) to the plant network. Management traffic stays on a dedicated management VLAN.

Updates and Rollbacks Without Downtime

The killer feature of containers at the edge is atomic updates. Pull a new image, stop the old container, start the new one. If it fails health checks, roll back to the previous image in seconds. With K3s, this is automated using deployments with rolling update strategies. The edge gateway checks a container registry (local or cloud) for new images, pulls them during a maintenance window, and validates them with health probes before switching traffic. If anything goes wrong, the previous image is still on disk. This is vastly safer than the traditional approach of SSHing into an industrial PC and manually copying new executables.

What We Learned the Hard Way

• Always set memory limits — a memory leak in one container should not crash the entire edge gateway.
• Use a local container registry, not Docker Hub — pulling images over a flaky plant network is unreliable.
• Log to stdout/stderr and ship logs to a central system — do not store logs inside the container.
• Test container restart behavior under power failure — simulate a hard power cycle and verify all containers come back cleanly.
• Keep the host OS minimal and immutable — use a container-optimized OS like Flatcar, Bottlerocket, or Ubuntu Core.
• Never run containers as root in production — always use a non-root user with explicit capabilities.

Containerization at the industrial edge is not a trend — it is an engineering evolution. The tools are mature, the patterns are proven, and the benefits (isolation, portability, atomic updates) solve real problems that monolithic deployments cannot. Start small, prove it on one production line, then scale.