[{"data":1,"prerenderedAt":362},["ShallowReactive",2],{"application-guide-nav":3,"agmd-flowfuse-app-delivery-methods":118},[4,12,16,22,25,31,36,42,47,53,58,64,70,75,81,87,93,98,103,108,112],{"guide":5,"slug":6,"title":7,"navOrder":8,"parent":9,"blurb":10,"path":11},"flowfuse","overview","Overview",1,null,"The map of the FlowFuse guide — apps, architectures, and a worked example.","\u002Fapplication-guide\u002Fflowfuse\u002Foverview\u002F",{"guide":13,"slug":6,"title":7,"navOrder":8,"parent":9,"blurb":14,"path":15},"node-red","The map of the Node-RED guide — the pattern families that turn an app into a clean flow.","\u002Fapplication-guide\u002Fnode-red\u002Foverview\u002F",{"guide":5,"slug":17,"title":18,"navOrder":19,"parent":9,"blurb":20,"path":21},"foundations","Foundations",2,"The foundation to build on: what FlowFuse is, its core pieces, and how code is shared across teams.","\u002Fapplication-guide\u002Fflowfuse\u002Ffoundations\u002F",{"guide":13,"slug":17,"title":18,"navOrder":19,"parent":9,"blurb":23,"path":24},"The handful of concepts you need to build with Node-RED, and how they fit together.","\u002Fapplication-guide\u002Fnode-red\u002Ffoundations\u002F",{"guide":5,"slug":26,"title":27,"navOrder":28,"parent":9,"blurb":29,"path":30},"app-delivery-methods","App delivery methods",3,"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.","\u002Fapplication-guide\u002Fflowfuse\u002Fapp-delivery-methods\u002F",{"guide":13,"slug":32,"title":33,"navOrder":28,"parent":9,"blurb":34,"path":35},"patterns","Patterns","The moves that turn an architecture into a clean, reusable flow — find the seams and reuse well, then handle data on the right paths.","\u002Fapplication-guide\u002Fnode-red\u002Fpatterns\u002F",{"guide":5,"slug":37,"title":38,"navOrder":39,"parent":26,"blurb":40,"path":41},"hardware-apps","Hardware apps",3.1,"The three shapes a FlowFuse app takes when it runs on a device. Pick by how much varies per site: nothing (Packaged App), a few settings (Configurable App), or you assemble it yourself (Edge Building Block).","\u002Fapplication-guide\u002Fflowfuse\u002Fhardware-apps\u002F",{"guide":13,"slug":43,"title":44,"navOrder":39,"parent":32,"blurb":45,"path":46},"design-patterns","Design patterns","The structural choices you select for a flow: find the seams it breaks into, then reuse each piece at the lightest level that solves it — link in\u002Fout, link call, subflow, or packaged node.","\u002Fapplication-guide\u002Fnode-red\u002Fdesign-patterns\u002F",{"guide":5,"slug":48,"title":49,"navOrder":50,"parent":26,"blurb":51,"path":52},"software-apps","Software apps",3.2,"The three shapes a FlowFuse app takes when it runs on the platform. Pick by what it needs: a headless job (Packaged App), a user-facing app driven by data (Data-Driven App), or a reusable piece other apps embed (Shared Building Block).","\u002Fapplication-guide\u002Fflowfuse\u002Fsoftware-apps\u002F",{"guide":13,"slug":54,"title":55,"navOrder":50,"parent":32,"blurb":56,"path":57},"handling-data","Handling data","Classify each signal by shape, purpose and direction, then pick the methods it needs — separate the paths, pace the flow, hold state in context, and manage config. The methods you select to move a flow's data.","\u002Fapplication-guide\u002Fnode-red\u002Fhandling-data\u002F",{"guide":13,"slug":59,"title":60,"navOrder":61,"parent":32,"blurb":62,"path":63},"good-form","Good form",3.3,"A clean flow isn't luck — it's a handful of habits. Wire for reading, lay it out on a grid, decouple UI from logic, catch errors where you can see them, and keep data on a stable contract. Follow these and a flow stays readable, reusable, and out of spaghetti.","\u002Fapplication-guide\u002Fnode-red\u002Fgood-form\u002F",{"guide":5,"slug":65,"title":66,"navOrder":67,"parent":9,"blurb":68,"path":69},"data-plane","Data plane",4,"Before you pick where things run, decide how data is handled. Two stores come built into every FlowFuse server install — the Team Broker and relational Tables — exposed to every instance with nothing extra to stand up. Everything else you bring your own: run it (a time-series DB, an existing database, a model) and expose it to the fleet over Project Link, no inbound ports. This is the data plane the architectures on the next pages all sit on.","\u002Fapplication-guide\u002Fflowfuse\u002Fdata-plane\u002F",{"guide":13,"slug":71,"title":72,"navOrder":67,"parent":9,"blurb":73,"path":74},"worked-examples","Worked examples","Turn an app concept into a Node-RED flow — or a few — leaning on the design patterns and data handling. The method, then the OEE apps end to end.","\u002Fapplication-guide\u002Fnode-red\u002Fworked-examples\u002F",{"guide":13,"slug":76,"title":77,"navOrder":78,"parent":71,"blurb":79,"path":80},"oee-edge-aggregator","OEE - Edge Aggregator",4.1,"The edge app from the OEE use case as a Node-RED flow — a straight-line flow packaged as a subflow and configured per line (its PLC tags, via a config UI and a get-config node), with the data treated as a stream and its counts held in context.","\u002Fapplication-guide\u002Fnode-red\u002Foee-edge-aggregator\u002F",{"guide":13,"slug":82,"title":83,"navOrder":84,"parent":71,"blurb":85,"path":86},"oee-central-dashboard","OEE - Central Dashboard",4.2,"The cloud app from the OEE use case as a Node-RED flow — one link out fanning to two link ins on separate tabs (dashboard and batched history), so the live and history paths stay separate and easy to read.","\u002Fapplication-guide\u002Fnode-red\u002Foee-central-dashboard\u002F",{"guide":5,"slug":88,"title":89,"navOrder":90,"parent":9,"blurb":91,"path":92},"architectures","Architectures",5,"Every FlowFuse deployment is the same building blocks arranged for where it runs — pick the world you're designing for.","\u002Fapplication-guide\u002Fflowfuse\u002Farchitectures\u002F",{"guide":5,"slug":94,"title":95,"navOrder":96,"parent":88,"blurb":9,"path":97},"it-architectures","IT architectures",5.1,"\u002Fapplication-guide\u002Fflowfuse\u002Fit-architectures\u002F",{"guide":5,"slug":99,"title":100,"navOrder":101,"parent":88,"blurb":9,"path":102},"ot-architectures","OT architectures",5.2,"\u002Fapplication-guide\u002Fflowfuse\u002Fot-architectures\u002F",{"guide":5,"slug":104,"title":105,"navOrder":106,"parent":88,"blurb":9,"path":107},"iiot-architectures","IIoT architectures",5.3,"\u002Fapplication-guide\u002Fflowfuse\u002Fiiot-architectures\u002F",{"guide":5,"slug":71,"title":72,"navOrder":109,"parent":9,"blurb":110,"path":111},6,"Start from a use case, break it into apps, and draw the architecture that ties them together — the same method a FlowFuse Proof of Value runs.","\u002Fapplication-guide\u002Fflowfuse\u002Fworked-examples\u002F",{"guide":5,"slug":113,"title":114,"navOrder":115,"parent":71,"blurb":116,"path":117},"worked-example","OEE, end to end",6.1,"One use case — OEE across three lines — broken into two apps and two shared services, then drawn out end to end.","\u002Fapplication-guide\u002Fflowfuse\u002Fworked-example\u002F",{"id":119,"title":27,"blurb":29,"body":120,"description":132,"extension":355,"guide":5,"meta":356,"navOrder":28,"navTitle":27,"navigation":357,"parent":9,"path":358,"seo":359,"slug":26,"stem":360,"__hash__":361},"applicationGuideDoc\u002Fapplication-guide\u002Fflowfuse\u002Fapp-delivery-methods.md",{"type":121,"value":122,"toc":352},"minimark",[123,126,133,135,318,335],[124,125,27],"h1",{"id":26},[127,128,129],"p",{},[130,131,132],"strong",{},"App delivery methods — start here",[127,134,29],{},[136,137,138,226],"guide-tabs",{},[139,140,142,148,153,156,162,168,173,201,216,222],"guide-tab",{"label":141},"Whole app",[127,143,144,147],{},[130,145,146],{},"Snapshots & pipelines"," — promote a complete, versioned project through dev → staging → prod to every place that runs it.",[149,150],"flow-diagram",{":edges":151,":nodes":152},"[{\"from\":\"golden\",\"to\":\"fleet\",\"accent\":\"indigo\",\"label\":\"snapshot · pipeline\"}]","[{\"id\":\"golden\",\"label\":\"Dev instance\",\"sub\":\"the golden one you build & test\",\"accent\":\"indigo\"},{\"id\":\"fleet\",\"label\":\"Instances\",\"sub\":\"every place it runs\",\"accent\":\"slate\",\"many\":true}]",[127,154,155],{},"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.",[127,157,158,161],{},[130,159,160],{},"Use it when"," — You're shipping a complete application and every site should run the same, controlled version.",[127,163,164,167],{},[130,165,166],{},"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.",[127,169,170],{},[130,171,172],{},"Major components",[174,175,176,183,189,195],"ul",{},[177,178,179,182],"li",{},[130,180,181],{},"Snapshot"," — the whole app, frozen as one versioned build",[177,184,185,188],{},[130,186,187],{},"Pipeline"," — promotes that snapshot through dev → staging → prod",[177,190,191,194],{},[130,192,193],{},"Dev instance"," — where you build and test the project",[177,196,197,200],{},[130,198,199],{},"Remote \u002F Hosted Instances"," — the fleet each snapshot rolls out to",[127,202,203,206,207,211,212,215],{},[130,204,205],{},"Where config & data live"," depends on the kind of app you're shipping — a hardware app tied to a device, or a software app on the platform. See ",[208,209,210],"a",{"href":41},"Hardware apps →"," and ",[208,213,214],{"href":52},"Software apps →",".",[127,217,218,221],{},[130,219,220],{},"More phases when you need them"," — a pipeline isn't limited to two stages. Add the phases your process needs — an extra staging tier, an approval gate, per-region rollouts — each one a controlled promotion of the same golden build:",[149,223],{":edges":224,":nodes":225},"[\"dev>stage\",\"stage>prod\"]","[{\"id\":\"dev\",\"label\":\"Dev\",\"sub\":\"golden build\",\"accent\":\"indigo\"},{\"id\":\"stage\",\"label\":\"Staging\"},{\"id\":\"prod\",\"label\":\"Production\",\"sub\":\"every place it runs\",\"accent\":\"slate\",\"many\":true}]",[139,227,229,235,240,247,252,264,268,300,304],{"label":228},"Pieces",[127,230,231,234],{},[130,232,233],{},"Subflow export"," — publish one piece as a package the team installs, like a shared library.",[149,236],{":edges":237,":nodes":238,":legend":239},"[{\"from\":\"sub\",\"to\":\"node\",\"label\":\"export as\"},{\"from\":\"node\",\"to\":\"inst\",\"accent\":\"red\",\"dashed\":true,\"label\":\"install\"},{\"from\":\"inst\",\"to\":\"bom\",\"label\":\"version-tracked\"}]","[{\"id\":\"sub\",\"label\":\"Subflow\",\"sub\":\"reusable block\",\"accent\":\"indigo\"},{\"id\":\"node\",\"label\":\"Custom node\",\"sub\":\"installable package\",\"accent\":\"slate\"},{\"id\":\"inst\",\"label\":\"Instances\",\"sub\":\"install & run the piece\",\"accent\":\"indigo\",\"many\":true},{\"id\":\"bom\",\"label\":\"Bill of Materials\",\"sub\":\"which version each runs\",\"accent\":\"slate\"}]","[{\"line\":\"red\",\"dashed\":true,\"label\":\"install\"},{\"line\":\"neutral\",\"label\":\"version-tracked\"}]",[127,241,242,243,246],{},"Package a single piece of a flow — a block of logic or UI — as a reusable subflow, export it as a ",[130,244,245],{},"custom node"," other apps install, and pull it in instead of copying code between projects.",[127,248,249,251],{},[130,250,160],{}," — A part of an app should be reused across many apps and upgraded in one place — a shared library, not a whole application.",[127,253,254,256,257,259,260,263],{},[130,255,166],{}," — Export the subflow as a ",[130,258,245],{}," — an installable package apps pull in like any library dependency. Apps install it and the Bill of Materials tracks every version in use. Share an ",[130,261,262],{},"example flow"," in the Team Library to show how to wire it up.",[127,265,266],{},[130,267,172],{},[174,269,270,276,282,288,294],{},[177,271,272,275],{},[130,273,274],{},"Subflow"," — the one reusable piece you package",[177,277,278,281],{},[130,279,280],{},"Custom node"," — the installable package your subflow is exported to",[177,283,284,287],{},[130,285,286],{},"Team Library"," — example flows the team shares (a custom node can ship with one to show its use)",[177,289,290,293],{},[130,291,292],{},"Instances"," — the apps that install and run the piece",[177,295,296,299],{},[130,297,298],{},"Bill of Materials"," — tracks which version each app runs",[127,301,302],{},[130,303,205],{},[174,305,306,312],{},[177,307,308,311],{},[130,309,310],{},"Config"," — the subflow's instance properties \u002F env where it's installed.",[177,313,314,317],{},[130,315,316],{},"Distribution"," — export once as a custom node; apps install and upgrade from it, like a library.",[319,320,322],"callout",{"icon":321},"i-lucide-triangle-alert",[127,323,324,327,328,331,332],{},[130,325,326],{},"Dev and prod in the same team?"," Every instance on a team reaches the same shared resources — the Team Broker, FlowFuse Tables, project links, any external Postgres. So a dev instance can read and write the very data prod depends on. ",[130,329,330],{},"Name and namespace resources per environment"," so test data and real data never mix: separate broker topic prefixes, table or schema names, and project-link targets, driven by each instance's env vars. ",[208,333,334],{"href":69},"See the Data plane →",[319,336,338],{"icon":337},"i-lucide-git-branch",[127,339,340,341,344,345,348,349],{},"Dev and prod on ",[130,342,343],{},"separate servers"," — dev in IT or the cloud, prod in OT or air-gapped? A ",[130,346,347],{},"GitHub bridge"," carries the same versioned code across the boundary. That's an architecture decision. ",[208,350,351],{"href":92},"See Architectures →",{"title":353,"searchDepth":67,"depth":67,"links":354},"",[],"md",{},true,"\u002Fapplication-guide\u002Fflowfuse\u002Fapp-delivery-methods",{"title":27,"description":132},"application-guide\u002Fflowfuse\u002Fapp-delivery-methods","lhjFW0h0IvgSc6s2TPDnjmR3AWcUUkGPIbjbPDtU3gs",1787068105334]