What is Docker?

Docker is an open-source container platform that lets you package an application with all its libraries, runtime and configuration into an image and run it as an isolated container on a shared Linux kernel. Docker was introduced in March 2013 by dotCloud (later Docker, Inc.) and within a few years made containerisation the norm in IT. Within OT and Industrial Automation, Docker mainly runs on edge gateways and industrial PCs: MQTT brokers, OPC UA gateways, historians, dashboards and even Soft PLC runtimes. That makes Docker a concrete building block of IT OT Convergence, bringing new opportunities and new risks.


🧠 How does Docker work?

Unlike classic virtualisation, Docker virtualises neither hardware nor a full operating system. A container is an ordinary Linux process that the kernel isolates using two mechanisms:

  • Namespaces - give each container its own view of processes, network, file system, hostname and users
  • cgroups (control groups) - limit how much CPU, memory and IO a container may use

The architecture is layered. The docker CLI talks through an API to the dockerd daemon. The daemon hands work to containerd (which manages images and the container lifecycle) and runc (which starts the container process according to the OCI specification). Since the Open Container Initiative was set up in June 2015, the image format and runtime have been open standards, so an image built with Docker also runs on Podman, containerd or Kubernetes. Docker Engine itself is open source under the Apache 2.0 licence (the Moby project).

Because containers share the host kernel, Linux containers on Windows and macOS run inside a lightweight virtual machine (with Docker Desktop via WSL 2 or a hypervisor). Native Windows containers also exist, but they are rare in industry.

Component Function
Dockerfile Text file with the build steps of an image
Image Read-only template made of stacked layers
Container Running instance of an image with its own writable layer
Registry Storage and distribution of images (Docker Hub, GitHub Container Registry or private)
Volume Persistent storage outside the container lifecycle
Network Virtual networks (bridge, host, macvlan) between containers and the outside world
Docker Compose YAML description for starting several containers together on one host

Images consist of layers (base OS, runtime, application, configuration). Shared layers are stored and cached once, which keeps downloads to edge devices small when you update.


🔄 What is the difference between a container and a virtual machine?

Property Docker container Virtual machine
What is virtualised Process on a shared kernel Full hardware with its own OS
Start-up time Typically seconds or less Typically tens of seconds to minutes
Overhead Low, near-native performance Higher, own kernel and memory per VM
Size Tens to hundreds of MB Several GB
Isolation Kernel boundary, exposed to kernel and runtime flaws Hardware-level via the hypervisor, stronger
Different OS possible No, same kernel as the host Yes (e.g. a Windows HMI next to Linux)
Typical OT use Edge apps, gateways, analytics, testing Legacy SCADA servers, engineering workstations

In practice you combine both: a VM platform for older Windows applications, and Linux hosts with containers inside or alongside it. Lower overhead makes containers faster and leaner, but not automatically deterministic (see real-time below).


🏭 What is Docker used for in OT?

Docker is widely used on edge devices, because a single gateway can then run several independent services that you update separately. Typical workloads:

Workload Suitable for containers? Notes
MQTT broker (Mosquitto) Yes Standard image, small footprint
OPC UA gateway / protocol converter Yes Translates Modbus TCP or S7 to OPC UA or MQTT
Historian / InfluxDB Yes With a volume for persistent data
Dashboards (Grafana) Yes Visualisation, OEE
Flows (Node-RED) Yes Data integration and light logic
AI inferencing / Vision Yes Often with GPU pass-through
SCADA components (Ignition Edge) Partly Depends on vendor and licensing
Soft PLC Limited Only with a real-time kernel and tuning

Vendors build entire platforms on it. Apps for Siemens Industrial Edge are Docker images described by a docker-compose.yml file and rolled out through Industrial Edge Management. CODESYS Virtual Control SL delivers a virtual PLC as a container for Docker or Podman on Linux (x86-64 and ARM), with several PLC instances per device.

In a Unified Namespace architecture, each part (broker, Sparkplug gateway, historian, analytics, dashboard) often runs as a separate container. Examples by sector: OEE dashboards and protocol gateways in manufacturing, predictive maintenance and telemetry in energy supply, HVAC analytics in building automation and edge buffering of measurement data in the water sector. Containers communicate over MQTT, OPC UA, HTTP, HTTPS and REST APIs.


⏱️ Is Docker suitable for real-time applications?

Not by default. A container uses the host scheduler, so jitter comes from the kernel and from other processes. Real-time tasks need:

  • A real-time kernel - PREEMPT_RT has been part of the mainline kernel since Linux 6.12 (late 2024)
  • CPU isolation and pinning - dedicated cores for the real-time container (--cpuset-cpus)
  • Real-time scheduling - only the capability required (such as CAP_SYS_NICE) and an rtprio limit instead of --privileged
  • Host or macvlan networking - avoids the latency of NAT and overlay networks; for deterministic network traffic possibly TSN

This brings soft PLCs with cycle times in the millisecond range within reach. For high-speed motion control and safety functions, dedicated controllers often remain the norm. Other bottlenecks are storage IO, CPU contention with too many containers per host and orchestration overhead.


🔄 When do you use Docker Compose, Swarm or Kubernetes?

  • Docker Compose - describes a stack (e.g. broker, historian, Grafana, OPC UA gateway) in one YAML file on one host; ideal for a single edge gateway or test set-up
  • Docker Swarm - simple clustering built into Docker, rarely chosen for new projects
  • Kubernetes and distributions such as the lightweight K3s or the enterprise platform OpenShift - orchestration across many nodes with self-healing and GitOps-based roll-out

Kubernetes removed its Docker Engine integration (dockershim) in version 1.24 (May 2022) and has since used containerd or CRI-O. Images built with Docker keep working there, because they are OCI images. Docker remains above all the tool for building images and testing them locally, including in OTAP pipelines and simulation labs.


🔐 What security risks does Docker bring to OT?

The risks lie less in container technology itself than in configuration and the origin of images. For OT cybersecurity, these are the most important:

Risk Example Impact
Open daemon API dockerd on TCP port 2375 without TLS Full control of the host
Docker socket in a container /var/run/docker.sock mounted into an app Container can take over other containers and the host
Privileged containers --privileged or host namespaces Isolation virtually gone
Container breakout runc flaws CVE-2019-5736 and CVE-2024-21626 (“Leaky Vessels”, fixed in runc 1.1.12) Code execution on the host
Untrusted images Random Docker Hub images, latest tags Malware, cryptominers, supply-chain attack
Outdated images Base image with known CVEs Vulnerabilities linger for years
Shadow containers Stacks started by vendors or engineers themselves Invisible to operations and security monitoring

Access to the Docker daemon is equivalent to root on the host. Anyone in the docker group or holding the client certificates is effectively an administrator.


🛡️ How do you secure Docker in an OT environment step by step?

  1. Inventory - record per host which containers, images (by digest) and versions are running; include them in your asset register and configuration management.
  2. Segment - place container hosts in the right zone according to IEC 62443 and the Purdue Model; edge gateways that send data to IT or the cloud often belong in or next to the DMZ, shielded by an industrial firewall and network segmentation.
  3. Lock down the daemon - no TCP port 2375; remote management only via SSH or TLS on port 2376, and restrict the docker group following least privilege.
  4. Harden the containers - non-root users, rootless mode where possible, read-only file systems, no --privileged, minimal capabilities and resource limits. The CIS Docker Benchmark and other CIS Benchmarks provide concrete checks (hardening).
  5. Control the supply chain - use a private registry, minimal and signed images, fixed versions or digests instead of latest, vulnerability scanning in the build pipeline and an SBOM per image.
  6. Monitor and log - send container and daemon logs to central logging, use RBAC and MFA on the registry and management platform, and consider application whitelisting on the host.
  7. Patch through the OTAP pipeline - test new images first, roll out with a fallback option, and include host OS, runtime and images in patch management and lifecycle management.

NIST SP 800-190 (Application Container Security Guide, September 2017) is a widely used guide to container security and fits with NIST SP 800-82, ISO 27001 and the NIST CSF. Vendors that place containerised software on the EU market fall under the Cyber Resilience Act: they must actively handle vulnerabilities in their images, including open-source layers. Reporting of actively exploited vulnerabilities applies from 11 September 2026, the full obligations from 11 December 2027.


🧱 What should you watch for in operations and licensing?

  • Persistent data - a container’s writable layer disappears as soon as the container is removed or replaced, for example during an update. Historians, alarms, audit logs and trends therefore belong in volumes, with backups.
  • Versioning - keep Dockerfiles and Compose files in version control, so every installation is reproducible.
  • Licensing - Docker Engine is free, but Docker Desktop requires a paid subscription for organisations with 250 or more employees or annual revenue of 10 million US dollars or more. On Linux servers and edge devices you therefore usually run only the Engine.
  • Docker Hub limits - anonymous pulls are capped per time window; edge devices that fetch images themselves run into them. Your own registry or mirror avoids this and is advisable in OT anyway.
  • Offline operation - many OT networks have no internet access. Make sure images are already in a local registry, so a restart never depends on an external download.

❓ Frequently asked questions

Is Docker free to use in industry?

Docker Engine is open source under the Apache 2.0 licence and free to use on Linux servers, industrial PCs and edge gateways. Only Docker Desktop, the development environment for Windows and macOS, requires a paid subscription for organisations with 250 or more employees or annual revenue of 10 million US dollars or more.

Can a PLC run in a Docker container?

A soft PLC can run in a Docker container, for example CODESYS Virtual Control SL on a Linux host. Predictable cycle times require a real-time kernel (PREEMPT_RT), dedicated CPU cores and suitable networking. For fast motion control and safety functions, hardware PLCs and safety controllers remain the usual choice.

Is Docker secure enough for OT networks?

Docker can be used securely in OT if the daemon is not exposed on the network, containers run without root privileges and images come from a controlled registry. Containers isolate less strongly than virtual machines, so network segmentation according to IEC 62443 remains necessary. Useful guides are NIST SP 800-190 and the CIS Docker Benchmark.

What is the difference between Docker and Kubernetes?

Docker builds and runs containers on a single host, whereas Kubernetes distributes, monitors and automatically restarts containers across a cluster of machines. Since version 1.24, Kubernetes no longer uses Docker Engine as its runtime, but it still runs images built with Docker through containerd or CRI-O.

Does Docker run on Windows?

Docker runs on Windows through Docker Desktop, which executes Linux containers in a lightweight virtual machine based on WSL 2. Native Windows containers also exist for Windows applications. In industrial edge environments, Docker almost always runs directly on Linux.

Why are containers so common on edge gateways?

Containers let you run several independent services, such as an MQTT broker, an OPC UA gateway and a dashboard, on one edge gateway and update each of them separately. An update is a new image that can quickly be rolled back if problems arise. Platforms such as Siemens Industrial Edge are therefore built on Docker.


📌 In summary

Docker packages applications with their dependencies into lightweight, reproducible containers, and has become the standard way to deploy edge and data services in OT. It brings speed, scalability and easy updates to IIoT architectures, but demands a locked-down daemon, controlled images, persistent volumes, real-time tuning where needed and a place in the IEC 62443 zones. With compliance and security built in from the start, Docker becomes a reliable building block between IT and OT, on-premises or at the edge.