Edge gateways for industrial data

It bridges a gap that exists on purpose. Controllers and meters sit on a plant network that nothing on the internet can reach, and that is the design rather than an oversight. The analysis runs somewhere that is on the internet. So a machine inside the site has to read the equipment and carry the readings out, without opening a way back in.

That machine does four jobs, and each one fails in its own way.

• It reads. Protocol drivers talk to each device in the language it already speaks, on a schedule or by subscription.
• It holds. Readings land in a local buffer first, so a dropped uplink costs a delay rather than a gap, for as long as the buffer has room.
• It sends. Batches of readings go upstream over connections the gateway opens, so the site firewall never has to accept one.
• It answers to the cloud. It pulls configuration and software updates and reports its health, all over connections it opens, which is how a small team runs gateways at sites it rarely visits.

The term covers a wide range. Some gateways only translate one protocol into another, and some run analysis on site. This guide is about the common case for asset performance work: a Linux machine running collection software, with the analysis in the cloud. The hardware and placement advice applies to any gateway of that kind. The firewall rules and everything after them are specific to Fleetera.

Less processor than you might expect, and more disk than you might think. The software runs on a dual-core machine. The disk is where the real sizing decision sits, because the buffer that carries a site through an outage lives there.

The minimum runs the software. The recommended column is what we would put on a production site, and most of the memory and disk difference is the buffer. The buffer keeps its fast lane in memory and its durable lane on disk. On a 2 GB machine the fast lane, the operating system and Docker compete for the same memory.

Size the disk from the outage you want to ride out, not from a price list. The buffer's disk size and retention are set per gateway, and the store and forward guide walks through the arithmetic. Leave room beyond it for the operating system, container logs, and a second copy of each software image while an update rolls out. Choose an SSD with an endurance rating suited to steady writes, because during an outage the buffer writes to it continuously.

Two form factors cover almost every site.

• NUC-class mini PCs, such as Intel or ASUS NUC models, suit a server room or a site office with climate control. They are cheap, quiet and easy to swap.
• Fanless DIN-rail industrial PCs suit a control cabinet. They tolerate the cabinet's heat, dust and vibration, mount on the same rail as the rest of the equipment, and often run from the cabinet's 24 V DC supply.

Protect the power either way. Put the gateway on the site's UPS, and set its firmware to power on after an outage so the machine comes back by itself. The Fleetera runtime starts at boot and resumes from its cached configuration, even if the cloud is unreachable at that moment.

On a boundary your OT security design already has a name for. Industrial sites keep operational technology apart from IT for a reason. A controller that runs a process cannot be patched weekly, and it must never be reachable from the internet. The gateway is the one machine that has to talk to both sides. Where you put it is a security decision first and a networking one second.

The usual map for that decision is the Purdue model. It stacks an industrial network in levels, and the rule that matters here is simple. Nothing crosses from the plant to the business without passing a boundary.

IEC 62443, the main security standard for industrial control systems, describes the same idea as zones joined by conduits. Either way the gateway belongs where a boundary already is, never in the middle of the plant network with a cable run to the office.

In practice that leaves two good placements.

• In the OT DMZ, where the site has one. The inner firewall lets the gateway open connections to the specific devices it reads, and the outer firewall lets it out to the internet. This is the textbook answer and the one a security reviewer expects.
• Dual-homed, where the site has no DMZ. The gateway gets two network interfaces, one on the plant network and one on a network that reaches the internet. It reads on the first, sends on the second, and routes nothing between them. The gateway itself becomes the boundary, so it has to be hardened like one.

A dual-homed gateway is a boundary device, and a reviewer will check it as one.

• Nothing routes between the interfaces. Docker switches IP forwarding on for its own containers, so do not rely on that setting alone. Confirm that the host firewall drops traffic crossing from one interface to the other, and test it from a machine on the plant side.
• The routes are specific. The plant interface carries routes to the device subnets it reads and no default gateway. The default route points out of the uplink interface.
• The plant side is offered nothing. The Fleetera runtime publishes its local web interface only on its private network address, and its discovery companion only on the loopback address. Hold anything else installed on the machine, remote login included, to the same rule.

Very little, and nothing inbound. Every connection starts at the gateway and goes out. Nothing on the internet ever opens a connection to the site, so the firewall needs no inbound rule and no port forwarding.

No row in that table is inbound. The install guide on docs.fleetera.ai lists the exact hostname behind each destination. The install script probes the API, the registry and the configuration storage before it installs Docker, and the VPN coordinator as soon as registration tells it the address. A missing rule stops the install early, with the hostname in the error.

Two details catch firewall teams out. During installation, and only if they are missing, the script downloads Docker and the VPN client from their publishers, so either preinstall both or allow those downloads for the install window. And the UDP rule is optional. Without it the private network still connects, relayed through a server on 443/TCP rather than sent directly, and allowing the rule only gives it the shorter path.

Each organization gets its own private network, built on WireGuard and coordinated by a Headscale server that Fleetera runs. The coordinator hands out keys and tells each machine how to reach the others. WireGuard encrypts the traffic between them.

A gateway joins once, during installation.

1. 1Creating the gateway in the app mints a key for it. The key works once, expires 24 hours after it is minted, and carries your organization's tag.
2. 2The install script spends the key to join the gateway to your organization's network, under the alias you gave the gateway.
3. 3From then on the gateway holds a stable private address, which the app shows on the gateway's page.

Organizations are kept apart by the coordinator's access rules. A tagged gateway may reach the Fleetera cloud and the other gateways of its own organization, and nothing that belongs to anyone else.

Traffic flows from the cloud to the gateway only because the gateway built the tunnel first, from the inside out. That is why the firewall table above has no inbound row, even though diagnostics and commands travel inward.

The gateway advertises no routes into the private network. The platform reaches the gateway and nothing behind it. Your controllers never become addresses on this network, and the runtime is the only software that talks to them. The runtime's own web interface listens on port 8080 on the private network address only, so it is not reachable from the plant or office interfaces.

The software a Fleetera gateway runs. It is one process, shipped as a Docker image, holding everything a gateway needs in one place: the protocol drivers, the buffer, the uplink, and the loops that keep it in step with the cloud. Two small companions normally run beside it, one for OPC UA discovery and one that applies updates.

The gateway pulls its configuration on its own schedule, so the cloud never reaches into the site to change it. A change made in the app arrives at the next check, within about half a minute, and the app shows when the gateway reports it applied.

When the uplink drops, the drivers keep reading, new readings go to the buffer's disk lane, and the backlog goes out when the link returns. The buffer has limits. An outage longer than they allow discards the oldest undelivered readings, and the runtime counts and reports every one. The store and forward guide covers exactly where that boundary sits.

From the app, with one command on the gateway. With the firewall rules in place, a new site is a short sitting.

1. 1Open the site in the app, go to Gateways and choose Add gateway. Name it, pick x86_64 or ARM64, and optionally limit it to part of the site's asset tree or change its buffer sizes.
2. 2The app mints a single-use install token and the private network key, both valid for 24 hours, and shows one install command.
3. 3Run the command on the gateway as root. The script checks the operating system family and the processor architecture, then probes the outbound destinations before it installs Docker.
4. 4It installs Docker and the VPN client if they are missing, registers the gateway with the platform, and joins it to your organization's private network.
5. 5It writes the gateway's files to their own install directory, starts the runtime, and installs a system service so the runtime comes back after every reboot.
6. 6The gateway's page in the app shows each step as the script reports it, and the gateway turns Online at its first heartbeat.

Then the work moves back into the app. Connectors define which equipment the gateway reads and how. Discovery browses an OPC UA server's address space from the gateway itself. Binding maps each raw signal to a named variable on a real asset. None of it needs another visit, because every change reaches the gateway as configuration.

Each check below takes minutes at a desk, and each one is far more expensive to discover on the day of the site visit.

Then watch the first hour. The heartbeat carries each driver's status and the buffer's fill level, so a device refusing connections or a buffer that keeps growing shows on the gateway's page long before it shows as a gap in a chart. A gateway that sends no heartbeat for five minutes turns Offline.