The FlowFuse Platform
Platform
FlowFuse is an app platform
Not because of what it draws on a screen, but because of how it distributes and manages code. This page covers the major components, how they fit together, and the patterns that take one working application to every site.
01 · How code moves
Why we call it an app platform
Most industrial platforms give you one way to ship what you build. FlowFuse gives you two, and they cover opposite ends of how teams actually work.
Ship the whole application
Build the application once, capture it as a snapshot, and promote that exact snapshot through a pipeline to every instance and every device that should run it. Each target supplies its own configuration, so one artifact runs everywhere without an edit.
- Central team owns the application and the release
- Every site runs a known, identical version
- Per-site differences live in configuration, not in forked flows
Ship the building blocks
Publish the parts worth standardizing, subflows and nodes, as packages into a library your teams pull from. Local teams assemble their own application out of blocks the platform team maintains.
- Local teams keep ownership of their own application
- Central team still controls the parts that matter
- Improvements to a block propagate by version bump
The choice between these two is the first decision on any FlowFuse project, and it is what the design patterns below formalize.
02 · Major components
The major components
Five groups. Everything FlowFuse does sits in one of them.
Where applications run
Instances
Managed Node-RED runtimes, hosted by FlowFuse or in your own infrastructure.
Devices
The Device Agent runs the same applications on edge hardware, including networks with no inbound access.
Learn moreGroups
Devices addressed as a fleet, so a deployment target can be a hundred machines rather than one.
Learn moreHow applications get built
Node-RED
The open runtime and flow editor underneath everything. The build surface, not the platform.
Learn moreFlowFuse Expert
Describe what you need and get starting flows, function code and explanations in the editor.
Learn moreFlowFuse Dashboard
The operator-facing interface, built from the same flows rather than bolted on from a separate tool.
Learn moreHow code is distributed and managed
Snapshots
A versioned, restorable point in time for an application. The unit everything else moves around.
Learn moreDevOps Pipelines
Promote a snapshot from development to test to production, and out to device groups.
Learn moreEnvironment Variables
Per-target configuration held outside the flows, which is what lets one artifact run at every site.
Learn moreShared Team Library
Flows and subflows shared across the team instead of copied between editors.
Learn moreCustom Node Packages
Publish your own nodes and subflows as packages and install them like any other dependency.
Learn moreWhat applications connect to
Integrations
Industrial protocols and enterprise systems, from OPC-UA and Modbus to ERP and cloud services.
Learn moreTeam Broker
A managed MQTT broker, so a Unified Namespace does not start with procuring infrastructure.
Learn moreFlowFuse Tables
Managed storage for applications that need to keep state rather than pass it on.
Learn moreProject Nodes
Instance-to-instance messaging without wiring up a broker or opening ports.
Learn moreHow it is governed
Role-Based Access Control
Who can edit, who can deploy, who can only look, per team and per application.
Learn moreAudit Logs
A record of who changed and deployed what, at team and instance level.
Self-hosted and certified
SOC 2 Type 1 and Type 2, with a self-hosted option for air-gapped environments.
Learn more03 · How it fits together
How the pieces fit together
The components are not a menu of unrelated features. They are one path from a flow in an editor to the same application running across a fleet.
04 · Design patterns
The design patterns
You do not start with Node-RED and later work out how to scale it. You choose the pattern first, then build inside it. There are six, split by where the application runs.
Applications running on edge devices.
Pipeline plus environment variables
One application, distributed by pipeline. Everything site-specific lives in environment variables.
Pipeline plus external configuration
One application, distributed by pipeline, reading its configuration at runtime from a central source so changes need no redeploy.
Edge building blocks
Subflows published as packages and pulled from the team library, with each site assembling its own application.
Applications running on hosted instances.
Packaged application
Self-contained. Everything the application needs travels with it.
Data-driven application
Behaviour driven by an external database rather than by what is wired into the flows.
Shared building blocks
The hosted equivalent of edge building blocks, assembled per team from shared packages.
Naming the pattern up front is what makes an application scalable or not, whether or not the platform makes it easy.
05 · Node-RED
Where Node-RED fits
Node-RED is how the logic gets built. It is not what makes FlowFuse a platform, and treating it as the headline gets the order wrong.
Platform first, then Node-RED
Decide how the application will be distributed and governed, then open the editor. The reverse order produces flows that work on one machine and transfer to none.
The runtime stays open
FlowFuse runs standard Node-RED. Your flows are portable and the foundation stays yours.
The platform is everything after the build
Deployment across sites, versioning, access control, configuration, connectivity and audit. That is the part no editor gives you.
See the platform on your operations
Talk to an expert about which pattern fits your estate, or start building today.
