Building an ARM64 Edge IoT Gateway with a Single Binary

The industrial edge is where OT meets compute: a small, rugged box sitting next to the machines, polling PLCs and CNCs, doing a little work on the data, and shipping it upstream. For a decade the default answer was “throw a Windows PC at it.” That’s changing fast, and ARM64 — Raspberry Pi, industrial gateways, even some ruggedized panel PCs — is the reason. Here’s how to think about building an ARM64 edge IoT gateway, and why a single static binary is the right unit for it.

Why ARM64 at the edge

• Cost. A Pi or a BeagleBone-class industrial gateway is a fraction of the cost of an industrial PC.
• Power and thermals. Lower draw, fanless enclosures, fits in a control cabinet without a climate system.
• Resilience. Solid-state, no spinning disks, tolerates power cycles.
• Enough compute. Modern ARM64 cores handle polling, transforms, and TLS without breaking a sweat for typical machine densities.

The old objection — “ARM can’t run our collector” — is usually about software packaging, not hardware capability. Which brings us to the real question.

The unit of deployment matters more than the CPU

Most edge pain isn’t the ARM chip. It’s the software stack you have to assemble on it:

• A runtime (Node.js, Python, Java…).
• A broker (Mosquitto, NATS).
• A transform layer (custom scripts, Node-RED).
• A scheduler / supervisor.
• Drivers and OS packages.

On x86 you can muscle through that sprawl. On ARM64 every one of those is a cross-compilation, an ARM package hunt, or an architecture-mismatch bug at 2am. The fewer moving parts on the device, the better. (This is a general principle: prefer one binary over a constellation of processes and a broker wherever you can.)

The single-binary edge gateway

The cleanest ARM64 gateway runs one statically-linked binary that does all of it — poll, normalize, transform, deliver, retain, observe — with the UI embedded. No runtime to install, no broker to operate, no driver chain to maintain. You copy one file to the device and run it under systemd.

OpexFlow is built exactly this way: a single musl static binary that cross-compiles to aarch64-unknown-linux-musl. The same artifact runs on a Raspberry Pi, an industrial gateway, and a rack server. The React canvas UI is embedded in the binary, so you configure flows in a browser pointed at the gateway — no separate frontend to deploy.

What goes on the gateway

A minimal, robust ARM64 gateway with OpexFlow:

1. The binary. One file under systemd.
2. A config file. Sources (Modbus/OPC-UA/MQTT/MTConnect), transforms, sinks.
3. That’s it. Optionally SQLite retention is local on the device.

# /etc/systemd/system/opex-flow.service
[Unit]
Description=OpexFlow
After=network.target

[Service]
Environment=OPEXMX_HMAC_SECRET=change-me
ExecStart=/usr/local/bin/opex-flow /etc/opexmx/config.yaml
Restart=on-failure
User=opexmx

[Install]
WantedBy=multi-user.target

Because everything’s in one process, there’s no inter-process brokering to break and no extra services to supervise. The deployment guide covers systemd and edge cross-compilation.

What a good gateway does for you at the edge

An edge gateway isn’t just a protocol translator — it earns its place by doing useful work locally:

• Normalize at the source. Turn raw Modbus registers and OPC-UA nodes into one CanonicalMachineData shape before anything leaves the device. (See OPC-UA vs Modbus.)
• Transform in flight. Filter noise, compute derived fields, drop offline machines — with the native DSL (no interpreter, fast) or sandboxed JS. The AI generator writes it for you.
• Survive gaps. HMAC-signed HTTP push with SQLite retention means if the upstream link drops, data is buffered locally and backfilled — no holes when connectivity returns.
• Observe itself. Prometheus /metrics, OTel traces, and sink-stall alerting so you know the gateway is healthy from afar.

ARM64 caveats worth stating

One real constraint: native Windows-only libraries don’t run on ARM. Fanuc FOCAS loads fwlib30.dll, which is Windows/x86 — so on an ARM gateway, use MTConnect for Fanuc CNCs instead. A good adapter makes this explicit: OpexFlow’s FOCAS adapter self-disables with a clear status on Linux/ARM rather than failing opaquely. (More in FOCAS vs MTConnect.)

Everything else OpexFlow ships — Modbus, OPC-UA, MQTT, NATS, ClickHouse/Postgres sinks, the transform engines, the canvas — is cross-platform and runs unchanged on ARM64.

From Pi to rack, unchanged

The payoff of single-binary packaging: the gateway on the floor and the aggregator in the data center run the same artifact. You develop against the binary on a laptop, deploy it to a Pi in a cabinet, and scale it onto a rack server for a high-density line — no code changes, no recompilation choices, no architecture forks. One binary, from edge to server.

The bottom line

ARM64 is now plenty of machine for the industrial edge. The thing that makes an edge gateway painful isn’t the CPU — it’s the software sprawl you pile on top of it. A single static binary that polls, normalizes, transforms, delivers, and observes — with the UI embedded — turns a fragile stack into a file you copy and run. That’s the OpexFlow edge story.

See how it works, read the deployment docs, or request a license.

Related: OpexFlow as a Node-RED alternative and Modbus to ClickHouse.