Connect OPC UA to Docker
| Product | Docker |
|---|---|
| Category | Deployment |
| OPC UA role | Client and server |
Containerising an OPC UA client or server works well, with one trap that catches almost everyone: the application instance certificate lives in the PKI directory, so a non-persistent volume regenerates your identity on every restart and stales every peer's trust list on every deploy.
Before you start
- A persistent volume for the PKI directory. This is the whole lesson of this page.
- A decision about the container's hostname and ApplicationUri, because neither resolves the way it does on a laptop.
- Network reachability from the container to port 4840 on the servers, including any host firewall on the container host itself.
Setting it up
- Mount the PKI directory on a named volumeWhatever your stack calls it - ./pki, the security configuration store paths, or the certificate manager root folder - mount it. The container's identity is in there and it must survive a restart.
- Set the ApplicationUri explicitlyDo not let it default to something derived from a random container hostname. Set it in configuration and make sure the same value appears as a URI entry in the certificate's SAN.
- Put every reachable name in the certificate SANThe container's service name, the host's DNS name and any address a peer will actually dial. A client comparing the URL it dialled against the SAN does not care what the container thinks its name is.
- Handle timeContainers inherit the host clock. A skewed host clock produces certificate-time failures on perfectly valid certificates, so NTP on the host is a security control.
- Prove the restart case before you shipStart the container, establish a secure session, restart the container, and confirm the session re-establishes without an administrator touching a trust list. If it does not, your volume is not mounted where you think it is.
- Expose the right port for a serverA containerised OPC UA server needs 4840 published, and the endpoint URL it advertises must be one clients can actually reach - not its internal container address.
What the address space looks like
Containerisation does not change the address space. What it changes is identity and reachability: the certificate, the ApplicationUri and the advertised endpoint URL. Those three are the entire difference between a working deployment and a confusing one.
The traps
- A non-persistent PKI volume is the single most common containerised OPC UA failure. The symptom is maddening: it works, then fails after every deploy, with a certificate error that looks like a server-side change.
- A containerised server that advertises its internal container hostname in its endpoint description gives clients a URL they cannot resolve. Configure the advertised hostname explicitly.
- Host clock skew produces certificate-time failures that look like certificate-content problems. Check the clock before rebuilding a certificate.
- Scratch and intermediate files inside the container are fine, but anything you need to keep - certificates, nodeset exports, configuration - needs a volume.
- If the container restarts frequently under an orchestrator, each restart is a fresh connection to every server. Stagger startup or you build your own connect storm.
Getting OEE data out of it
Nothing directly - this is deployment plumbing. It matters for OEE only in the sense that a collector that loses trust on every deploy produces gaps in your availability data, and a gap in collection is indistinguishable from downtime unless you record collector health separately. Publish a collector-online signal alongside the machine data.
Last verified 7 September 2026 against OPC UA 1.05.07. OPC UA Connect is an educational resource and is not affiliated with the OPC Foundation.