We tested this setup as part of the Tailscale + Mendix private beta, together with Mendix and Tailscale.

Tailscale is a networking product that lets a group of devices, servers, containers, laptops or edge hardware act as if they are on the same private network, no matter where they run. It is widely used in cloud infrastructure and over the past year it has started showing up in industrial contexts as well.

Lost between Cloud, OT, and security

Industrial Mendix projects rarely stall on the software. The dashboard is built in weeks, the logic works, the demo lands well. Then comes the moment the application has to go to production and actually talk to a PLC on the shop floor. IT requires a firewall exception filed and risk-assessed. OT wants nothing on the production network to change. Lets not even get started on the security part.

We’ve seen this at multiple manufacturing customers. The idea that makes working with IT/OT integration way easier: a VPN that puts the Mendix app and the edge device directly on the same private network. The app reads directly from the device. No data sending and no data duplication for cloud connectivity is needed.

What we built

We needed a Mendix application in the cloud to talk directly to a Siemens Industrial Edge device. Which sits on the shop floor, connected to the PLC, running an MQTT broker internally. In this case it is the single point on the OT network we needed the app to reach. To do this we use Tailscale, it’s built on WireGuard VPN technology, makes it possible. Both the cloud app and the edge device connect to Tailscale, which sets up an encrypted tunnel between them.

What this changes

The standard approach to getting factory data into a cloud application is to push it upward: the edge device or a SCADA system collects data from the PLC, then replicates it to a cloud database or an IoT platform like AWS IoT or Azure IoT Hub. The cloud application reads from that copy. It works, but it means maintaining a data pipeline for ingestion, transformation, storage, and synchronisation before the Mendix app can show a single value. Every layer adds latency, cost, and another place where the data in the cloud can drift out of sync with what the device actually has.

Our setup removes that pipeline entirely. The Mendix app queries the edge device directly over an encrypted tunnel, as if both were on the same local network. The network architecture stays untouched because both sides connect.

Why not a traditional VPN

The obvious question is: doesn’t a VPN already solve this? Technically yes, but the VPNs that are normally used are exactly what makes this kind of integration more difficult. 

A classic site-to-site VPN (IPsec, OpenVPN, a vendor appliance) works by terminating a tunnel on a router or firewall at the edge of the factory network. To make that tunnel reachable from the outside, somebody must open an inbound port on the OT firewall and publish a route from the internet into the production network.

Tailscale is shaped differently. Every node for example the edge device and the Mendix app makes an outbound connection to Tailscale’s coordination service and then sets up a direct, encrypted peer-to-peer tunnel with the other nodes it is allowed to reach.

Access is governed by policy within the tailscale service, not by the network topology. Which node can reach which node is defined in the Tailscale ACL, (access control) separate from the underlying network. This is how Mendix app would connect to the the edge device.

The architecture

Two active components and one connection layer:

1. A Siemens Industrial Edge Device on the shop floor, running a small Tailscale container alongside whatever industrial apps are already on the device.
2. A Mendix application in the Mendix cloud, For example — dashboards, OEE, alerts.
3. A Tailscale module inside the Mendix cloud environment, deployed next to the Mendix app.

The Industrial Edge Device

The Tailscale gateway on the IED is a single Docker service. We package it as a normal Industrial Edge app and ship it through Industrial Edge Management. (IEM)

Three design choices are worth calling out:

Host network mode.
Running the container with `network_mode: host` lets Tailscale share the IED’s host directly, so anything already running on the device — Services, MQTT, HTTP from other Industrial Edge apps — is reachable on the tailnet as `http://<edge-hostname>:<port>` or `https://<edge-hostname>/<service>`.

Persistent state on a named volume.
The Tailscale node’s identity lives in `/var/lib/tailscale`. We mount a named Docker volume (`tailscale-state`) there, so a container restart, an app update, or a device reboot doesn’t re-key the node. The IED keeps the same tailnet identity across its lifetime, while the app exists on the device.

Configuration
the auth key, the hostname, optional extra arguments are delivered through IEM’s secure configuration mechanism: a `.env` file uploaded into the device’s `data` slot at install time. The container’s entrypoint sources it before launching `containerboot`. so secrets will stay out of the default image.

*Installation of the Tailscale App with the required configuration. So that each application has his own Keys setup.

The Mendix cloud node

The other end of the tunnel runs inside the Mendix cloud environment, as a cloud module next to the Mendix application. It is the same Tailscale service just deployed alongside the app rather than the factory hardware.

Mendix puts the VPN clientinside the Mendix cloud as a service, means that the service and maintenance is done by Mendix.

Dedicated networks
Mendix creates unique, fully isolated networks for each customer within the Tailscale account. Each network has its own encryption keys and Public Key Infrastructure (PKI).

Smart connections
Mendix applications will then connect directly (peer-to-peer) to these approved resources whenever possible. If a direct connection isn’t feasible, traffic is securely routed through Tailscale’s global relay (DERP) network, which is “encrypt-then-forward” only – meaning Tailscale never sees your data. This global network also ensures high availability and low latency by automatically selecting the best path.

Other options

This is a client-to-client setup: the Mendix app reaches the edge devices on the tailnet. Other machines on the PLC’s network such as the PLC itself, HMIs and engineering stations are not exposed. If you need to reach something beyond the edge device, it must go through the edge device.

Connecting the network behind the device would be possible but it would be needed to add a extra route. Only the devices you explicitly join to the tailnet are reachable; the rest of the OT network stays invisible to the VPN.

If you do need client-to-site — the Mendix app reaching the PLC, an HMI, or another device behind the IED — Tailscale supports it through subnet routing. The device its env node adds the OT subnet with `–advertise-routes=168.168.0/24`, and an admin approves the route in the Tailscale console, and the Mendix node can then reach IPs on that subnet through the IED.

What it looks like, finished

Production data flowing into a Mendix application. A Docker container on the IED, one next to the Mendix app in the cloud, one Tailscale network inbetween them.

The interesting work is the application — the dashboard, the OEE model, the alerts that wake somebody up when a line goes down for example. The network underneath should be the part nobody has to think about, and with this pattern, it largely is!

If your industrial Mendix project is currently sitting in the queue between IT and OT, we have probably been here before. We are happy to walk through the architecture with your team.

*Directly connecting to the Device data (MQTT) Layer