FlowFuse Application GuideFlowFuse Guide
App delivery methods
Two different units of code, delivered two ways: ship the whole app, or publish one reusable piece.
App delivery methods — start here
Two different units of code, delivered two ways. Ship the whole app — a complete, versioned project promoted through environments — or publish one reusable piece — a package the whole team installs and upgrades in one place. Pick by what you're shipping: the app, or a part of it.
Snapshots & pipelines
Promote a complete, versioned project through dev → staging → prod to every place that runs it.
Dev · one build
Dev instance
build & test once
Fleet · one instance per place, each pointed at its own data
Remote Instance
Site A · env A
Remote Instance
Site B · env B
Remote Instance
Site C · env C
- Managed
- Snapshot / pipeline
Take the whole app — every flow, setting and dependency — as a versioned snapshot, then promote that one controlled build through pipeline stages to every place that should run it.
Use it when
You're shipping a complete application and every site should run the same, controlled version.
How it works
A pipeline promotes a snapshot dev → staging → production; each target is parameterised by its own env vars, so one controlled build serves every site.
Major components
- Snapshot — the whole app, frozen as one versioned build
- Pipeline — promotes that snapshot through dev → staging → prod
- Dev instance — where you build and test the project
- Remote / Hosted Instances — the fleet each snapshot rolls out to
Where config & data live
- Config — each target is parameterised by its own env vars.
- Rollout — Device Groups + pipeline promotion: one controlled build, many places.
Dev and prod on separate servers — dev in IT or the cloud, prod in OT or air-gapped? A GitHub bridge carries the same versioned code across the boundary. That's an architecture decision.
See Architectures →