Architecture

IronFlock is a distributed system with two layers: autonomous edge devices that run applications at the point of operation, and central services that provide fleet-wide data storage, dashboarding, AI, and coordination. A real-time message broker connects everything.

This is not a pure edge platform and not a pure cloud platform. It is both — and the architecture is designed so that each layer does what it does best.

How the System Fits Together

┌─────────────────────────────────────────────────────────┐  ┌──────────┐
│                    Central Services                     │  │ Virtual  │
│                                                         │  │ Device   │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌────────┐   │  │┌────────┐│
│  │ FleetDB  │  │ Backend  │  │    AI    │  │  Web   │   │  ││ Custom ││
│  │ Cluster  │  │ Service  │  │ Service  │  │  UI    │   │  ││ Service││
│  │(Timescale│  │          │  │          │  │        │   │  │└────────┘│
│  │   DB)    │  │          │  │          │  │        │   │  │  Agent   │
│  └────┬─────┘  └────┬─────┘  └────┬─────┘  └───┬────┘   │  └────┬─────┘
│       │             │             │            │        │       │
│       └─────────────┴──────┬──────┴────────────┘        │       │
│                            │                            │       │
│                    ┌───────┴───────┐                    │       │
│                    │  WAMP Message ├────────────────────────────┘
│                    │    Broker     │                    │
│                    └───────┬───────┘                    │
│                            │                            │
└────────────────────────────┼────────────────────────────┘
                             │
              ┌──────────────┼─────────────┐
              │              │             │
      ┌───────┴──┐   ┌───────┴──┐   ┌──────┴───┐
      │  Edge    │   │  Edge    │   │  Edge    │
      │ Device 1 │   │ Device 2 │   │ Device 3 │
      │┌────────┐│   │┌────────┐│   │┌────────┐│
      ││  Apps  ││   ││  Apps  ││   ││  Apps  ││
      ││(Docker)││   ││(Docker)││   ││(Docker)││
      │└────────┘│   │└────────┘│   │└────────┘│
      │  Agent   │   │  Agent   │   │  Agent   │
      └──────────┘   └──────────┘   └──────────┘

The Three Layers

1. Edge Devices — Autonomous Application Runners

Edge devices are the core execution nodes in IronFlock. Each device runs a lightweight agent and one or more containerized applications (Docker). Devices are autonomous: they continue operating even when disconnected from the central services, and they reconnect automatically when the network is restored.

Edge devices can be any Linux-capable hardware — Raspberry Pi, industrial PCs, NVIDIA Jetson, x86 gateways, or custom ARM boards.

What runs on edge devices:

• The IronFlock agent — manages the device lifecycle, handles OTA updates, runs containers, and maintains the connection to the message broker
• Your applications — deployed as Docker containers in any programming language. These apps collect data from PLCs and sensors, run control logic, serve local HMIs, execute AI models, or do anything else a Linux application can do Edge devices initiate all connections outbound by default — no inbound ports need to be opened. However, device ports can be selectively opened when needed, for example to expose a local HMI or API endpoint. See Edge Devices & Agent for details.

2. Central Services — Fleet-Wide Data, UI, and Intelligence

The central layer provides capabilities that require a fleet-wide view or persistent infrastructure. Each central service is independently scalable — services can be scaled horizontally to handle growing fleets without affecting each other:

• FleetDB — A cluster of PostgreSQL/TimescaleDB databases that stores all telemetry data collected from devices. Each project gets its own isolated database instance with dedicated tables and credentials. The cluster architecture enables horizontal scaling across projects. FleetDB handles time-series storage, scheduled aggregations, and serves as the data backend for dashboards and AI queries.
• Backend Service — Manages devices, projects, apps, user accounts, releases, and all fleet-level operations. Exposes the web API and handles the business logic layer. Scales horizontally to handle increasing API load and device registrations.
• FleetDB Service — Processes incoming data streams from devices, handles data transformations, serves real-time dashboard data to the frontend, and manages alarm evaluation. Scales independently to match data ingestion volume.
• AI Service — Orchestrates AI-agent conversations, dynamically adding and removing specialized agents as the conversation evolves. Routes natural language queries, invokes device-side functions via the message broker, and generates charts and analysis in real time. Scales to support concurrent AI conversations across projects.
• Web UI — The browser-based control plane where operators manage their fleet, view dashboards, configure alarms, develop apps, and interact with the AI assistant.
• Container Registry — Stores Docker images for all apps, enabling OTA deployment to any device in the fleet. Scales storage and throughput independently as your app catalog grows.

Central services can run in the IronFlock cloud (managed by IronFlock) or on your own infrastructure for on-premises deployments. See Central Services for details.

3. Virtual Devices — Custom Central Compute Nodes

In addition to physical edge devices, IronFlock lets you provision virtual devices — cloud-hosted compute nodes that join your project alongside your physical fleet. A virtual device runs the same IronFlock agent as a physical device, participates in the same message routing, and can run any containerized application.

Common uses for virtual devices:

• Run central fleet services like Grafana, Node-RED, Netdata, or Jupyter that need a fleet-wide perspective
• Host data processing pipelines that aggregate data from multiple physical devices
• Run AI inference services that are too compute-intensive for edge hardware
• Act as protocol bridges connecting external systems (SAP, ERP, cloud APIs) to your IronFlock project

Virtual devices are not a separate feature — they are full participants in your project. They appear in the device list, receive OTA updates, and their apps communicate with edge device apps through the same message broker.

See Virtual Devices for details.

The Message Broker — The Glue

All components in IronFlock communicate through a central WAMP (Web Application Messaging Protocol) message broker. The broker provides:

• Real-time pub/sub messaging — Devices publish telemetry, dashboards subscribe to live data, apps communicate bidirectionally
• RPC (Remote Procedure Calls) — The AI service calls device-side functions, the backend triggers container operations on devices, operators send commands
• Project isolation — Each project-app combination gets its own cryptographically isolated messaging realm. Devices in one project cannot see messages from another
• Authentication — Every connection to the broker requires valid credentials

The message broker is what makes IronFlock a distributed system rather than a collection of disconnected parts. An AI agent running in the central cloud can invoke a function on a physical device at a factory floor — and get the result back in real time — because both are connected to the same broker.

See Message Broker (WAMP) for details.

Scalability & Zero-Downtime Updates

Every component in the IronFlock architecture is designed for horizontal scalability. The backend, FleetDB, AI service, message broker, and container registry can each be scaled independently to handle growing fleets, increasing data volumes, and more concurrent users — without affecting other parts of the system.

Most system components already support zero-downtime updates — they can be upgraded to new versions without interrupting active connections or data flows. The remaining components are on a roadmap to achieve the same, with the goal of making the entire platform updatable without any service interruption.

Architecture vs. Traditional SCADA

Traditional SCADA platforms (Ignition, WinCC, Wonderware) follow a gateway-centric model: one central server does everything — tag collection, history storage, screen serving, alarm processing, and scripting. The “edge” is just PLCs feeding data to that central server.

IronFlock inverts this. The edge devices are autonomous application runners with full compute capability. The central services handle what needs a fleet-wide view: persistent data storage, dashboarding, AI orchestration, and fleet management. Neither layer is subordinate to the other — they are complementary.

Deployment Options

IronFlock’s central services can run in different configurations:

See On-Premises Deployment for air-gapped and private infrastructure setups.