Skip to Content
ArchitectureEdge Devices & Agent

Edge Devices & Agent

Edge devices are the primary execution nodes in IronFlock. Each device is a Linux-capable machine — an industrial PC, Raspberry Pi, NVIDIA Jetson, gateway, or any hardware with a Linux kernel — that runs the IronFlock agent and one or more Docker-containerized applications.

The IronFlock Agent

The agent is a lightweight Go binary that runs on the device and handles:

  • Container management — Starts, stops, and monitors Docker containers for all installed apps
  • WAMP connectivity — Maintains a persistent, encrypted WebSocket connection to the central message broker
  • OTA updates — Receives and applies updates for the agent itself, the host OS, and installed applications
  • Tunneling — Provides secure remote access to device services (HTTP, SSH, VNC, TCP, UDP) through reverse proxy tunnels — no open ports required
  • Network management — Configures Wi-Fi, LAN, and LTE connections on the device

The agent is the only IronFlock component that runs directly on the host OS. Everything else runs inside Docker containers.

Autonomous Operation

Edge devices are designed to operate independently of the central services. If the network connection drops:

  • Apps continue running — All containerized applications keep operating normally
  • Apps can buffer data — Telemetry is queued locally and forwarded to FleetDB when connectivity is restored

This autonomy is a fundamental design choice. In industrial environments, network reliability cannot be guaranteed, and edge applications must not depend on a cloud connection for their core operation.

What Runs on the Device

┌─────────────────────────────────────────┐ │ Linux Host OS │ │ │ │ ┌─────────────────────────────────┐ │ │ │ IronFlock Agent │ │ │ │ (connectivity, OTA, tunneling) │ │ │ └────────────┬────────────────────┘ │ │ │ │ │ ┌────────────┴────────────────────┐ │ │ │ Docker Runtime │ │ │ │ │ │ │ │ ┌─────────┐ ┌─────────┐ │ │ │ │ │ App A │ │ App B │ ... │ │ │ │ │ (OPC UA │ │ (Custom │ │ │ │ │ │ reader) │ │ logic) │ │ │ │ │ └─────────┘ └─────────┘ │ │ │ └─────────────────────────────────┘ │ └─────────────────────────────────────────┘ │ (outbound WSS only) WAMP Message Broker

Each app runs in its own container with its own dependencies. Apps can be written in any programming language — Python, Go, Rust, Node.js, C++, or anything that runs in a Docker container.

Supported Hardware

IronFlock supports any Linux-capable device with Docker support:

PlatformArchitectureExamples
Industrial PCsx86_64Beckhoff, Advantech, Kontron, Dell Edge
Single-board computersARM64, ARMv7Raspberry Pi 4/5, BeagleBone
AI acceleratorsARM64NVIDIA Jetson Nano, Orin, Xavier
GatewaysARM64, x86_64Teltonika, Moxa, Advantech
Custom hardwareARM (v5, v6, v7), ARM64, x86_64Any Linux device with Docker

Device Provisioning

Devices can be added to IronFlock in several ways:

  1. Flash with FlockFlasher — Use the FlockFlasher desktop app to write IronFlock OS to the device’s storage. The device boots with the agent pre-configured and connects automatically.
  2. Install the agent — On an existing Linux system, install the agent binary and provide a configuration file (.flock file) with device credentials.
  3. OEM pre-registration — Register device serial numbers in advance. When the device is powered on and connects, it’s automatically assigned to the correct project.

Communication Model

By default, edge devices only make outbound connections. The agent connects to the WAMP message broker over an encrypted WebSocket (WSS) and does not need to listen on any port. This means:

  • No inbound firewall rules are required on the device or its network by default
  • The device is not discoverable or addressable from the internet
  • Remote access is provided through reverse tunnels — initiated by the device, not by the operator

However, device ports can be selectively opened when needed — for example to expose a local HMI, REST API, or other service running on the device. Port access is configured and managed through the IronFlock UI.

See Security for the full security architecture.

Last updated on