Tridium Niagara vs IronFlock: Open Framework Comparison (2026)

The Niagara Framework from Tridium (a Honeywell company since 2005) is the de facto standard for vendor-neutral integration in building automation. Founded in 1996, Tridium built Niagara as a Java framework that normalizes BACnet, Modbus, LonWorks, KNX and dozens of other protocols into a single object model, then serves it up as graphics, histories and control logic. It runs on JACE controllers, the Niagara Edge 10 field controller, and Niagara Supervisor servers, and it is resold under many OEM brands — Vykon, Honeywell, Centraline, KMC, Distech, Lynxspring and others — under the “Powered by Niagara” umbrella. Teams evaluating a Niagara alternative are usually looking for the same protocol openness without per-point licensing, certified-integrator gatekeeping, and a Java-module development model.

IronFlock takes a different route to the same openness: instead of normalizing everything into one framework running on one vendor’s controllers, it runs Docker-containerized apps on any Linux or Windows hardware, connected to central services (FleetDB, AI orchestration, dashboarding) through a real-time WAMP message broker.

Both systems are protocol-agnostic by design, both put compute at the edge, and both aim at multi-site fleets. The differences are in how you extend the system, who is allowed to buy and engineer it, how data is stored and priced, and whether AI is part of the platform.

This page provides an honest comparison to help teams choose the right system.

At a Glance

Architecture

Niagara: A Java Framework on Licensed Controllers

Niagara’s architecture is built around the station — a running Niagara instance that hosts drivers, a component tree, control logic, histories and graphics:

• JACE controllers: The JACE 8000 (QNX-based) and the newer JACE 9000 are the supervisory controllers that run stations at the edge, talk to field devices, and buffer history locally. The Niagara Edge 10 is a 10-point IP field controller that runs Niagara 4 down at equipment level (licensed for 3 devices and 50 points).
• Niagara Supervisor: A station running on a Windows or Linux server that aggregates data from many JACEs, archives histories, serves enterprise graphics, and runs batch provisioning jobs (software upgrades, backups, TLS settings) across the JACE fleet.
• Niagara Workbench: The Java desktop engineering tool. All engineering — driver configuration, point mapping, wire sheet graphical logic, Px graphics pages — happens in Workbench connected to a station.
• Drivers: BACnet, Modbus TCP/RTU, LonWorks, KNX, SNMP, oBIX, OPC UA and MQTT ship as licensed Niagara drivers; hundreds more come from third parties via the Niagara Marketplace. This driver library is Niagara’s single biggest strength.
• Modules: Extensions are Java JAR modules installed into a station. In Niagara 5, modules must be signed and all N4 modules need refactoring.
• Niagara Cloud Suite: A set of subscriptions layered on top — Niagara Data Service (cloud historian plus read/write APIs over station data), Niagara Recover (cloud station backups, five rotating snapshots), and Niagara Remote (remote access to stations without customer-side VPN). All require an active Software Maintenance Agreement.
• Containerized Niagara: Since 4.13, Niagara ships as a Docker container bundling the Niagara core, the JRE and required modules, for x86-64 and Arm64 — aimed at running Niagara itself in the cloud or on third-party hardware, under subscription licensing.

Note the direction of containerization: Niagara can be packaged as a container, but a Niagara station is not a place to run arbitrary containerized workloads.

IronFlock: Distributed Edge + Central Services

IronFlock is a distributed system with two complementary layers. Autonomous edge devices run a lightweight agent and Docker-containerized apps at the point of operation. Central services — FleetDB (TimescaleDB), the FleetDB Service, AI orchestration, and the web UI — provide fleet-wide data storage, dashboarding, and intelligence. A WAMP message broker connects everything with real-time pub/sub and RPC.

You can also provision virtual devices — cloud-hosted compute nodes that join your project alongside physical devices, running fleet-wide services like Grafana, Node-RED, Jupyter, or custom data pipelines.

• Edge devices: Any Linux- or Windows-capable hardware — Raspberry Pi, industrial PCs, NVIDIA Jetson, Windows IPCs, gateways — running apps autonomously (on Windows, the agent runs as a native service with automatic restart and self-update)
• Apps: Docker containers in any programming language, deployed to edge or virtual devices
• Data: Edge apps publish telemetry through the message broker to FleetDB, which automatically provisions per-project TimescaleDB tables you can query with SQL
• Central services: FleetDB Service processes data streams, evaluates alarms, and serves dashboards; the AI Service orchestrates multi-agent conversations with direct device access
• Deployment: Cloud SaaS or on-premises — the full platform can run in your own infrastructure

What This Means in Practice

Feature Comparison

Data & Connectivity

Visualization & Dashboards

Remote Access & Security

App Development

AI & Analytics

Device & Fleet Management

Alarms & Notifications

Pricing Comparison

Niagara: Per-Device/Per-Point Licensing + Mandatory Maintenance

Niagara is licensed per station, sized by how much it connects to:

• Station licenses: JACE licenses are tiered by device and point capacity — for example 5 devices / 250 points, 10 / 500, 25 / 1,250, 100 / 5,000, and 200 / 10,000 on the JACE 8000. Points also convert into device equivalents (roughly 50 points to one device) for licensing purposes. Growing a site past its tier means buying a bigger license.
• Niagara Edge 10: Licensed for 3 devices and 50 points — sized for one piece of equipment.
• Supervisor licenses: Sized by the number of connected stations and points.
• Hardware: JACE 8000 / JACE 9000 controllers, Edge 10 field controllers, and Supervisor server hardware, purchased through the OEM channel.
• SMA (Software Maintenance Agreement): Required with initial licensing (initial term typically 18 months) and required to stay current. Without an active SMA there are no version upgrades and no security patches — and Niagara Cloud Suite subscriptions require an active SMA for their whole term.
• Add-ons: Niagara Analytics Framework (licensed by analytic points), Niagara Enterprise Security, third-party Marketplace drivers, and the Niagara Cloud Suite subscriptions (Data Service, Recover, Remote) — Remote is priced per controller, per year.
• Certification and migration: Niagara certification is a prerequisite for buying a license. The move from Niagara 4 to Niagara 5 requires an active SMA and may carry a migration fee; JACE 8000 hardware cannot be upgraded to Niagara 5.

Because everything is metered by devices and points, cost scales with the size of the plant, not with the value you get from the data. And because commerce runs through certified integrators, there is no self-service path — every deployment starts with a channel conversation.

IronFlock: Free Cloud + Subscription for On-Premises

IronFlock’s cloud version is free — all core features (device management, dashboards, data storage, OTA updates, alarms, remote access, app deployment) are included at no cost. IronFlock charges based on resource usage: storage, remote access sessions, virtual devices, and AI usage. There are no point counts, no device-tier licenses, and no mandatory maintenance agreement. See the pricing page for details.

Additional capabilities can be added by purchasing apps from the marketplace — for example, specialized protocol connectors, analytics tools, or industry-specific solutions built by IronFlock or third-party developers.

For on-premises deployments (air-gapped or private infrastructure), IronFlock offers a subscription-based license.

When to Choose Niagara

Niagara may be the better choice if:

• Your project is building automation first — BACnet, LonWorks and KNX integration across HVAC, lighting, metering and access control is exactly what Niagara was built for, and nothing matches its driver depth there.
• You need an off-the-shelf driver for an obscure protocol — the Niagara Marketplace has accumulated hundreds of drivers over two decades.
• You are working with a certified Niagara integrator you trust, or you have in-house Niagara-certified engineers and existing JACE infrastructure.
• Your specification mandates Niagara — many public-sector and campus tenders name the framework directly, precisely because it prevents single-vendor lock-in at the device layer.
• You want rich building graphics and mature alarm workflows (shelving, escalation, alarm classes) out of the box.
• You need semantic tagging and Project Haystack models over a large estate of building equipment.
• You want the OEM channel model — a local partner who specifies, engineers, commissions and services the system as one contract.

When to Choose IronFlock as a Niagara Alternative

IronFlock is the stronger choice when:

• You want to run real applications at the edge — Docker containers in any language, not Java modules constrained by a framework API.
• You need built-in AI — natural language queries over fleet data, multi-agent orchestration, and physical AI that executes functions on devices.
• Per-point licensing doesn’t fit your data — high-frequency machine telemetry, vision, or vibration data would be economically absurd priced as Niagara points.
• You want self-service — sign up and connect a device today, without a certification course or a channel partner as a prerequisite.
• You want your data in an open database — per-project TimescaleDB with direct SQL access, instead of file-based station histories plus a cloud subscription to get at them.
• You need fleet operations on the whole stack — OS, agent and application updates pushed over the air from one control plane, not just Niagara software provisioning.
• You want remote access included — HTTP, SSH, VNC, TCP and UDP tunneling built into the platform rather than a per-controller subscription gated behind an active maintenance agreement.
• You are building machines and equipment, not buildings — IronFlock is designed for OEM fleets shipping digital services to their own customers, with per-customer data isolation.
• You want security updates as a matter of course, not as a benefit that lapses with a maintenance contract.
• You want to build and monetize apps — package domain expertise and sell it through an open marketplace, without a certification gate on the developer side.

Migration Path

IronFlock and Niagara coexist comfortably, because they meet at the data layer rather than competing for the same wires. The common pattern is to leave the Niagara stations doing what they do well — BACnet and LonWorks integration, building control sequences, local graphics — and add IronFlock alongside for everything Niagara was never meant to carry: containerized applications, machine-level telemetry at high frequency, SQL-accessible fleet data, browser-based remote access, and AI.

Practically, that means running an IronFlock agent on an industrial PC or edge device at the same site, pulling from the station over BACnet, Modbus or MQTT, or subscribing to data the station already publishes. From there the fleet dashboards, alarms, tunnels and AI apply to Niagara-sourced data as much as to anything else. Over time, new equipment and new sites can be brought on without adding Niagara point licenses, while the existing estate keeps running.

Ready to try it? Start free — connect a device and see your first dashboard in minutes.