Data Handling & Architecture
IronFlock provides a complete, end-to-end data collection and storage infrastructure designed for scalability, security, and clear data ownership — from the edge to the cloud. Whether routing telemetry from thousands of sensors or building real-time SCADA interfaces, IronFlock’s data architecture ensures secure, isolated, and accessible information.
Message Routing and Secure Realms
At the core of IronFlock’s real-time communication is a robust message routing cluster. This messaging infrastructure connects diverse edge devices within a project to each other and to the IronFlock cloud infrastructure.
To ensure strict data security and isolation, the routing cluster is semantically partitioned into secure realms. A realm acts as an isolated sub-network where messages are strictly contained; data and commands cannot leave or cross between realms.
Applications running on your edge devices can utilize the ironflock-sdk to communicate over these messaging realms using:
- Publish/Subscribe (Pub/Sub): Ideal for continuously broadcasting sensor telemetry or state changes.
- Remote Procedure Calls (RPC): Perfect for triggering direct actions or securely querying device status.
Dynamically Provisioned Project Databases
For persistent storage and historical analysis, IronFlock provisions a dedicated, physical TimescaleDB database for every project.
This project database serves as the central data collection facility:
- App Data Backends: All data backends of the apps installed under your project are securely housed within this database.
- Direct Ingestion: When device apps publish data using the
ironflock-sdk, this stream is directly received and organized within the project database.
Because the project database acts as the single source of truth for your operations, it unlocks advanced capabilities:
- SQL Queries: Write powerful queries directly against your raw, historical tables.
- Physical AI Integration: Let the IronFlock AI agent extract, analyze, and query your data using natural language.
- Visualization Sources: The project database serves as the ultimate data source for live boards, IoT dashboards, and SCADA boards.
Data Ownership & the EU Data Act
IronFlock is built around a clear principle: the project owner is the data owner — not the app developer.
All data produced by apps — whether telemetry streams from edge devices, event logs, or derived analytics — is stored in the project database that belongs to the project owner. The app developer writes the app, but the data the app generates while running inside a project is the sole property of the project that hosts it.
This model directly aligns with the requirements of the EU Data Act, which grants users of connected products and related services full control over the data their devices generate. In IronFlock:
- Exclusive control. The project owner has full administrative control over the project database, including the ability to read, export, delete, and back up all data it contains.
- No silent data collection. App developers cannot access a project’s data without being explicitly invited. There is no hidden data pipeline from projects back to app developers.
- Portability. Because all data lives in a standard TimescaleDB instance, it can be queried with SQL, exported in open formats, and migrated at will — the project owner is never locked in.
- Granular sharing. The project owner can invite app developers, integration partners, or other stakeholders into the project and grant fine-grained access privileges to specific data areas. This makes it easy to benefit from third-party technical support, remote maintenance, or specialist analytics services — on terms the project owner defines and can revoke at any time.
In short: apps produce data, but the project owner owns, controls, and shares it. This ownership model is a first-class design goal of the IronFlock platform, not an afterthought.
Opting Out: Bypassing the IronFlock Data Pipeline
The IronFlock messaging layer and the project database are the recommended path — they give you real-time routing, durable storage, dashboard-ready data, and built-in ownership guarantees out of the box. However, IronFlock does not force apps to use this pipeline.
Apps running on IronFlock-managed devices are regular container workloads and retain full network and system freedom. If a project owner or app developer prefers a different data-handling stack, an app can:
- Push to external systems. Send data directly to third-party brokers (MQTT, Kafka, AMQP), cloud ingestion endpoints (AWS IoT, Azure IoT Hub, Google Cloud IoT), or custom REST / gRPC APIs.
- Use alternative storage. Write to an external database (InfluxDB, MongoDB, S3, customer-owned TimescaleDB, etc.) instead of — or in addition to — the IronFlock project database.
- Bridge to on-premises systems. Integrate directly with existing MES, ERP, historian, or SCADA systems over the local network without touching the IronFlock cloud.
- Mix and match. Publish a subset of data to IronFlock for dashboards and AI analytics, while streaming the full-fidelity data elsewhere.
This flexibility makes IronFlock a good fit both for greenfield deployments that embrace the platform end-to-end and for integrations into existing enterprise data architectures where the data destination is non-negotiable.
Using Data in IoT Dashboards and SCADA Boards
Putting your data to work visually is effortless. When you configure a widget in your IoT board or SCADA board, almost all properties (e.g., titles, values, colors) can be dynamically bound to live data from your project database.
When editing a widget in the Board Studio, you will find a data binding switch underneath the configuration fields. Selecting a specific column of a table establishes a real-time channel for that property. As new telemetry arrives in the database, the bound properties on your dashboard automatically update in real-time, requiring no manual UI refreshes.
Note: For a deep dive into connecting widget properties to your database, see the detailed section on data binding in the IoT Dashboards documentation.