Which Node-RED deployment model fits your team
A device suits edge hardware close to sensors, Docker on your servers suits central flows you already operate, and managed hosting suits teams that want fleet tooling without running it themselves. Most teams that need Node-RED in production are choosing among these three, and the choice shapes who patches the runtime, who reaches the editor and how changes reach each site. Start by asking where the data is produced and who will own the flows six months from now. A device deployment fits when Node-RED must sit next to Modbus gear, PLCs or sensors and keep running when the WAN link drops. The advantage matters only if the hardware is current enough to run the runtime. Node-RED 5.0, released June 9, 2026, requires Node.js 22.9.0 or later (Node.js 24 is recommended) and a 64-bit OS, so Raspberry Pi 3B and older models are no longer supported. Check each board's OS image and Node.js build before you buy more units, and confirm with the Node-RED team which 4.x line you should keep on older hardware. Every device also needs its own editor access control, since the editor is not secured by default.
Docker on your servers fits when flows are central, such as event routing or API integration, and your platform team already runs container hosts with logging, backup and patching in place. The advantage matters when you want one image, one set of secrets and one place to audit changes. Your team owns the Node.js base image, the HTTPS termination, the editor authentication through Passport, and the volume that holds the flows JSON. Ask who will rebuild the image when a 5.0.x or 4.1.x release ships and how the flows directory is backed up.
Managed hosting through FlowFuse fits when many Node-RED instances must be deployed, tested and rolled back with role-based access and an audit trail, and your team does not want to run that control plane. FlowFuse is available as a managed service or self-hosted in Docker or Kubernetes, so the choice between managed and self-hosted is a separate decision from the choice of a hosted model. Confirm with the vendor which edge features and enterprise-licensed parts your fleet needs, because FlowFuse code in the forge/ee directory is under a separate enterprise license.
Device, Docker and managed hosting compared
This table compares running Node-RED on devices, in Docker on your servers, and on a hosted platform such as FlowFuse across the requirements that decide production fit. Read each row as a question to answer for your own fleet, and treat the confirm entries as items to verify with the vendor before you commit.
| Requirement | Devices (Raspberry Pi and similar) | Docker on your servers | Managed hosting (FlowFuse Cloud) |
|---|---|---|---|
| Node.js and 64-bit requirements | Node-RED 5.0 needs a 64-bit OS and Node.js 22.9.0 or later, so Raspberry Pi 3B and older are no longer supported (5.0 release post). Confirm your board and OS image. | Host must run a supported 64-bit image. Confirm the Node-RED image tag and Node.js version it bundles before upgrading. | Runtime versions are set by the provider. Confirm which Node-RED and Node.js versions are offered and on what schedule. |
| Editor security defaults | The editor is not secured by default, so anyone who can reach the device IP can deploy changes. Enable HTTPS and authentication before exposing it. | Same default applies inside the container. Restrict network exposure and configure authentication in settings before publishing the port. | Access is controlled by the platform's accounts and roles. Confirm how the provider handles SSO, MFA and session policy. |
| Update path | Updates are applied on each device, typically by you, with a rollback plan per board. Plan for devices that are offline or intermittently connected. | Pull a new image and redeploy. Pin versions, test flows against the new runtime, and keep the flows directory in backed-up storage. | The provider handles platform updates. Confirm release notice periods, maintenance windows and whether your flows are tested on upgrade. |
| Fleet and device management | Each device is managed individually unless you add a remote management layer. Scale depends on your own tooling. | Scales as containers, but device fleets are not covered by a plain container setup. Edge devices need a separate deployment method. | FlowFuse documents a Device Agent for managing edge hardware and remote deployment of snapshots to devices (FlowFuse README). Confirm device limits on your plan. |
| Multi-user collaboration | Typically one editor per device, with shared change control handled outside Node-RED. | Shared editor access is possible but requires you to build role separation, review and audit around it. | FlowFuse lists collaborative development on shared instances, DevOps pipelines across development, test and production, and role-based access control (FlowFuse README). |
| Licensing of the tooling | Node-RED is Apache-2.0 licensed, governed by the OpenJS Foundation (nodered.org). | Node-RED is Apache-2.0. Check the licenses of any third-party images or add-on nodes you include. | FlowFuse code is Apache 2.0 except content in forge/ee, which is under a separate enterprise license (FlowFuse LICENSE). Confirm which features your plan uses. |
| Self-hosted or hosted options | Self-managed on your hardware only. | Self-managed in your own container environment. FlowFuse can also be self-hosted in Docker or Kubernetes. | FlowFuse is offered as FlowFuse Cloud or as a self-hosted installation (FlowFuse README). Confirm data residency for your region. |
| Operating effort you keep | You own OS patching, Node.js upgrades, device provisioning, backups and physical replacement. | You own the host, container runtime, backups, TLS, authentication and monitoring of the Node-RED container. | You keep flow design, testing and access policy. Confirm which operations, backups and incident duties the provider carries under your agreement. |
| Cost components to ask about | Hardware, OS maintenance time and the staff who manage devices. | Server or cloud hosting, storage, and the staff time to run containers and security controls. | Subscription fees, support tier, device counts and any enterprise features. Ask for a written quote tied to your scope. |
How each deployment model is put together
Node-RED can run on a single device, inside a container on your own host, or under a managed FlowFuse layer that manages the runtimes for you. Each model moves the same concerns (Node.js version, editor access, patching and fleet visibility) to a different owner, so the cards below focus on the parts you must check in each case.
Node-RED runtime and editor on a device
A device install runs the Node.js runtime and the browser editor directly on the hardware, with flows stored as JSON on the device. Node-RED 5.0 requires Node.js 22.9.0 or later, with Node.js 24 recommended, and a 64-bit OS, so older boards such as the Raspberry Pi 3B and earlier cannot move to 5.0. Check the OS image and Node.js version before you plan an upgrade, and confirm who patches each device once it is in the field.
Node-RED container on your host
Running Node-RED in Docker puts the runtime, its Node.js version and its flow data volume under your container tooling and your host patching. Image tags, volume mounts and the choice of base image become your responsibility, as does rebuilding the image when Node-RED releases a fix. Confirm how your team pins versions and where the flows directory is persisted so a container replacement does not lose flows.
Device Agent for edge hardware
The FlowFuse Device Agent runs on edge hardware and connects it to a FlowFuse instance, so flows can be deployed remotely from FlowFuse rather than edited on each device. This shifts fleet control to the platform layer and adds a dependency on the agent itself. Before adopting it, confirm which hardware and OS combinations the agent supports and how it is updated across devices.
FlowFuse Cloud or self-hosted FlowFuse
FlowFuse is offered as FlowFuse Cloud, a managed service, or as a self-hosted installation that can run in Docker or Kubernetes, with one-click Docker installs documented for DigitalOcean and AWS. The choice decides who operates the FlowFuse platform, where flow data and audit records live, and which network paths your devices must reach. Ask the vendor which parts of the platform you would host and which fall under their support terms.
Secured editor and authentication
The Node-RED editor is not secured by default, so anyone who can reach the device or container can deploy changes. Securing it means enabling HTTPS, configuring username and password or OAuth and OpenID through Passport for the editor and admin API, and setting basic authentication for HTTP nodes. Decide these settings before the first network exposure, and document where the credentials and certificates are stored on each deployment model.
Choosing by environment and team size
This situation fits a small number of sites, each with one or a few gateways, sensors or controllers that need local event handling. Running Node-RED directly on a device keeps the footprint small and removes a container layer that the site team may not operate. The trade-off is that every device becomes a host the team patches, backs up and secures by hand, and the device hardware sets the limits.
- Hardware floor: Node-RED 5.0 needs a 64-bit OS and Node.js 22.9.0 or later, with Node.js 24 recommended, so Raspberry Pi 3B and older models are out of scope for 5.0. Check older hardware against the release post before buying more units.
- Editor exposure: The editor is not secured by default, so anyone who can reach the device address can deploy changes. The team must configure HTTPS and authentication through Passport on each device.
- Manual updates: Each device needs its own update path, and the team owns rollback when a flow or runtime change breaks a site.
- Backups: Flows are stored as JSON, so the team must decide where copies live and how a failed device is restored.
- Low ongoing cost: Licensing is Apache-2.0, so the recurring spend is staff time and any support contract the team chooses to buy.
Before committing, confirm the device model and OS against the Node-RED 5.0 requirements and write down who performs each device update.
This situation fits a data center or cloud team that already builds, scans and runs containers, has an image registry and uses an orchestrator or a standard VM pattern. Node-RED documents a Docker install, so flows can ship as versioned images through the same pipeline as other services. The team gains consistent builds and rollbacks, but it takes on the runtime and the editor as one more internal service.
- Pipeline fit: Images can be built, scanned and promoted like any other service, which suits teams that already run this process.
- Editor access control: The team must decide whether the editor is reachable at all, and place it behind the same identity and network controls as other admin tools.
- Persistent storage: Flow files and credentials must sit on storage that survives container restarts, with backups tested.
- Central fleet view is not included: Docker alone does not manage remote edge devices, so the team must build or buy that layer if devices sit outside the cluster.
- Runtime upgrades: The team owns Node.js and Node-RED version choices, and must track major lines such as 4.x and 5.x.
Confirm with the platform team how images are signed, where secrets are injected and whether the editor can be kept off public networks.
This situation fits an industrial operator with many sites, several engineers who edit flows and a need to separate development from production. A hosted or self-hosted management layer such as FlowFuse covers collaboration, remote deployment to edge devices, DevOps pipelines across development, test and production, audit trails and role-based access control. The team gains shared control over who changes what, but it takes on the choice of Cloud or self-hosted operation and the licensing boundary.
- Multi-user control: Role-based access and audit trails answer the question of who deployed a change, which plain Node-RED does not provide on its own.
- Staged deployment: Pipelines across development, test and production reduce direct edits on live devices.
- Hosting choice: FlowFuse Cloud is a managed service, while self-hosting keeps the platform inside your network, installable with Docker or Kubernetes.
- Licensing boundary: FlowFuse code is Apache 2.0 except the forge/ee directory, which is under a separate enterprise license, so confirm which features you need fall under which terms.
- Support scope: FlowFuse offers professional support for FlowFuse and Node-RED, and the team should ask what that covers in writing.
Ask for a written list of the features in scope, the licensing terms of each one and the support boundary before you choose between Cloud and self-hosted.
Who patches Node-RED and who runs the fleet
This table compares who performs upgrades, backups, monitoring, access control and fleet management under each hosting model, and what skills each one needs. Read it as a responsibility map: the question is less which model is cheapest and more which party carries each recurring task in your environment. The main takeaway is that all three models still require your team to track Node-RED release lines, and the managed option shifts operating work without removing the need to confirm terms in writing.
| Task | On devices, self-managed | Docker on your servers | Hosted platform (FlowFuse) |
|---|---|---|---|
| Tracking releases | Your team follows Node-RED 5.0 and 4.1.16 (both October 8, 2026) and applies runtime changes device by device | Your team follows the same Node-RED lines and rebuilds container images for each update | FlowFuse v3.1.1 (October 8, 2026) is the platform release to track; confirm with FlowFuse how it schedules upgrades |
| Node.js and OS prerequisites | Node-RED 5.0 needs Node.js 22.9.0 or later, Node.js 24 recommended, and a 64-bit OS; older Raspberry Pi models are out of support for 5.0 | Your image must carry a supported Node.js version and 64-bit base; you own the base image patch cycle | Confirm which Node.js and OS versions the hosted runtime uses and how it changes them |
| Backups | Your team builds and tests backups of flow JSON, credentials and device state; confirm the approach for each device | Your team backs up volumes and flow files and tests restores; confirm storage and retention with your own policy | Confirm with FlowFuse what is backed up, how restores work and what the recovery timeline is in the written terms |
| Monitoring | Device health and runtime errors need a central approach your team builds | Container and runtime monitoring runs in your existing stack | Confirm which alerts, logs and audit trails FlowFuse exposes and how they export to your SIEM |
| Editor access control | The editor is not secured by default; your team configures HTTPS and authentication through Passport on each node | Your team sets the same editor and admin API controls inside the container and network | Role-based access control and audit trails are listed by FlowFuse; confirm how they map to your identity provider |
| Fleet management | Remote deployment to many devices requires tooling your team owns | Scales by orchestrating more containers; device fleets still need separate management | FlowFuse documents a Device Agent and remote deployment of snapshots; confirm device count limits and the edge hardware it supports |
| Skills your team needs | Embedded Linux, device networking, Node.js operations and field support | Container operations, Node.js, reverse proxy and secrets handling | Node-RED flow design and FlowFuse administration; fewer host-level skills, but vendor terms must be reviewed |
| Terms to confirm before signing | Support scope from any vendor you engage for device work | Who is paid for patch and backup work under a fixed-scope engagement | SLA terms, data location, exit path and whether the enterprise-licensed forge/ee parts are included |
Why the Node-RED editor needs securing before any deployment model
The Node-RED editor is not secured by default. Anyone who can reach its IP address can open the editor and deploy changes, which means a running flow can be replaced by someone with no login at all. Before you decide between a Raspberry Pi, a container on your servers or a hosted platform, confirm which network paths can reach the editor port on each device or host, and close every path that does not need it. This check applies whichever model you choose, so treat it as a precondition rather than a deployment detail.
The documented controls in the Securing Node-RED guide cover three areas. You can serve the editor and admin API over HTTPS, protect them with a username and password, or delegate sign-in to OAuth or OpenID through Passport. Separately, HTTP nodes that accept inbound requests can use basic authentication, which protects those endpoints rather than the editor. Each of these lives in the runtime's settings file, so whoever manages the device image, container configuration or secrets must version and review them like any other production configuration. Confirm with your identity team which sign-in method you will use before the first deployment, because retrofitting it onto a fleet of devices is more work than setting it at build time.
The controls above apply in every model, but the managed option adds more. FlowFuse, which is built on Node-RED by its co-creator, lists role-based access control and audit trails among its features, alongside collaborative development on shared instances and remote deployment to edge devices. If your auditors will ask who changed which flow and when, check whether self-run Node-RED gives you that record through your own logging, or whether you need the platform to provide it. Ask FlowFuse to confirm exactly how roles and audit records are scoped in the edition you are considering.
How to move from a single device to a managed or containerized fleet
This sequence takes a team from a handful of hand-configured Node-RED devices to a managed or containerized setup where flows are versioned, tested and deployed through a repeatable path. Each phase ends with an artifact the team can check before moving on.
Inventory every flow, node and device
The team lists each Node-RED instance, the device it runs on, the Node.js version it uses, and the flows and community nodes it depends on. Someone who owns the flows, usually the integration or operations lead with input from the device owner, records which flows are business critical, which nodes come from the community library, and which devices reach the editor from outside a trusted network. The step is done when the inventory names every instance and every external node package, and each flow has a named owner. Nothing should be migrated from memory.
Confirm hardware meets 64-bit and Node.js requirements
Platform engineering checks each device against the Node-RED 5.0 requirements: a 64-bit operating system, Node.js 22.9.0 or later, and Node.js 24 as the recommended version. Devices such as Raspberry Pi 3B and older models do not meet the 64-bit requirement and stay on an earlier Node-RED line or get replaced. Confirm the exact hardware and OS image against the vendor documentation for each board, since support depends on the image as well as the model. The step closes with a pass or fail list per device and a replacement plan for any device that fails.
Choose the operating model for each workload
Architects decide, per workload, whether flows stay on a device, move into Docker on the company's own servers, or run on a hosted platform. Devices suit local sensor and edge work where connectivity is intermittent. Docker suits central integration where the team wants its own infrastructure and deployment tooling. A managed platform such as FlowFuse, offered as FlowFuse Cloud or self-hosted, suits teams that want fleet features like remote deployment and role-based access without building them. The output is a decision record per workload, signed off by the security owner, that states the reason for each choice.
Harden the editor before any move
Before flows leave their current hosts, the security owner confirms that no editor or admin API is reachable without authentication. Node-RED's editor is not secured by default, so the team enables HTTPS and an authentication method through Passport, or uses the platform's own access controls, and sets basic authentication on HTTP nodes that accept requests. The step is done when a scan from outside the network cannot reach an unauthenticated editor, and the test result is recorded in the change log.
Migrate projects with the FlowFuse guide
For workloads moving to FlowFuse, the migration team follows the documented guide for moving an existing Node-RED project into FlowFuse. They export flows from one instance, import them into a FlowFuse instance, and re-create credentials and environment settings in the target rather than copying secrets between systems. Devices that run Device Agent are enrolled as a separate step. The step closes when each migrated flow runs in the target, and the flow owner signs off that outputs match the source for a defined set of test messages.
Set up test-to-production pipelines
The team creates separate development, test and production environments, and promotes flows through them using the DevOps pipeline features that FlowFuse documents, or through version-controlled flow files and a container build if they run Docker. Production changes come only from the promoted artifact, not from editing a live editor. The step is done when a test change reaches production through the pipeline, and a rollback to the prior version has been run once in test.
Set update and fleet ownership
Operations defines who applies Node-RED and Node.js updates, how often they review release notes, and who owns each device or container. Because Node-RED 5.0.8 and 4.1.16 were released on the same day, the team should decide in advance which line it runs and how it tracks patches on both. The output is a written runbook listing owners, the review cadence, the rollback steps and the escalation path, approved by the platform lead.
Confirm the model against a quote
Before committing, the buyer asks any implementation partner or vendor to confirm in writing what is in scope: the migration of each flow, device enrollment, pipeline setup, editor hardening and the handover runbook. Ask which FlowFuse features require the enterprise-licensed parts, which parts are covered by the Apache License 2.0, and what support terms apply to self-hosted versus cloud. The step closes when the written scope matches the inventory from the first step, with no flow left unassigned.
Questions buyers ask before choosing where Node-RED runs
Can a Raspberry Pi 3B still run Node-RED 5.0?
No. Node-RED 5.0, released on June 9, 2026, requires a 64-bit operating system, so Raspberry Pi 3B and older models are no longer supported on that line. The release post also sets the Node.js floor at 22.9.0 or later, with Node.js 24 recommended. If you have older boards in the field, you have three practical paths: keep them on an earlier Node-RED line that still runs on them, replace the hardware with a 64-bit board, or move the flows to a host you control. Confirm the exact support status of your current Node-RED release with the Node-RED release notes before you plan the upgrade window.
What drives the cost of running Node-RED on devices, in Docker or on a managed platform?
The cost splits into who pays for hardware, hosting, people and recurring subscriptions. On devices, the main costs are the boards, power, enclosures and the staff time to provision, patch and replace units across sites. In Docker on your servers, the costs are the infrastructure you already run, the engineering time to build and update images, and the time spent on backups and access control. A managed platform such as FlowFuse Cloud shifts hosting and much of the patching to the vendor, but adds a subscription that recurs. Ask any quote to separate one-time setup from recurring fees, to state which edition or tier includes fleet management and audit features, and to name who is responsible for OS patches, Node-RED upgrades and security fixes.
Can our team run Node-RED in Docker without outside help?
Yes, if you have people who already run containers and understand Node.js. Node-RED documents Docker as an install route, and FlowFuse documents Docker and Kubernetes installs for its own platform. The work that usually takes the most skill is not the first container start but the ongoing parts: persistent volumes for the flows and credentials, securing the editor, managing Node.js versions as Node-RED moves between lines, and rebuilding images when you update nodes. If that skill sits in your platform team, self-hosting is realistic. If it does not, a fixed-scope engagement can cover the build, hardening and runbook, with a retainer for upgrades. Confirm the skills and on-call coverage your team actually has before you commit.
How long does a migration to a new Node-RED host take?
The duration depends on the scope, so no single figure applies. The main variables are the number of flows and nodes, how many contributed nodes the flows depend on, whether credentials and secrets must be moved and re-entered, the number of devices or environments, and the testing your operations team requires before cutover. FlowFuse documents a guide for migrating an existing Node-RED project, which helps with the planning, but it does not replace an inventory of your own flows. Ask for a written scope that lists the flows, nodes, sites, environments and acceptance tests, and agree the timeline in writing before work starts. DeployOpen's engagements are fixed-scope, so the timeline follows from that agreed scope.
Does FlowFuse's enterprise-licensed code affect a self-hosted deployment?
It can, and the answer depends on which parts you run. FlowFuse code is under the Apache License 2.0, except content in the forge/ee directory, which falls under a separate enterprise license. If you self-host FlowFuse, you should read the LICENSE file in the repository and confirm with the vendor which features you would use come from the enterprise-licensed part. Ask whether a self-hosted install needs a commercial license key for any feature you plan to rely on, and whether that license restricts use in your environment. Plain Node-RED remains Apache-2.0 licensed, so a team that does not need FlowFuse features keeps a simpler licensing position.
Is an open Node-RED editor safe to leave on a factory or site network?
Not by default. The Node-RED editor is not secured out of the box, so anyone who can reach its IP address can deploy changes. The Node-RED security guide describes enabling HTTPS, username and password or OAuth and OpenID authentication through Passport for the editor and admin API, and basic authentication for HTTP nodes. Before any production rollout, confirm that the editor is behind authentication, that the network path is restricted, and that credentials are stored and rotated according to your policy. A managed platform adds role-based access control and audit trails, which can help with the control evidence an assessor will ask for, but the configuration still needs review.
Who handles Node-RED updates and security fixes on each model?
On devices and Docker, your team or your implementation partner handles updates. That includes the operating system, the Node.js version, the Node-RED release and every contributed node, and it must be repeated across every site. Node-RED 5.0.8 and 4.1.16 were both released on October 8, 2026, which shows that maintenance releases arrive on more than one line. On a managed platform, the vendor applies platform updates, but you still own the flows, the node selection and the test cycle before changes reach production. Ask any provider to state its patch cadence, its support window for each Node-RED line, and how it notifies customers about security fixes.
What does fleet management add when we run dozens of edge devices?
Fleet management matters once you need to deploy the same flows to many devices, track which version each device runs, and roll back a bad change without visiting the site. FlowFuse lists remote deployment of Node-RED snapshots to edge devices, DevOps pipelines across development, test and production, and a Device Agent for running Node-RED on edge hardware managed from FlowFuse. Without a fleet layer, teams usually script deployments by hand or push flows over SSH, which works at small scale but becomes hard to audit. Ask a vendor to demonstrate how it handles a failed rollout, how device identity is managed, and what happens when a device is offline during a deployment.
What to confirm with vendors and in your own environment
The facts available for this comparison do not settle several decisions that will shape cost and risk, so get written answers before you scope a managed or self-hosted deployment. Start with FlowFuse Cloud: ask which regions host tenant data, where backups are stored, what support hours and response commitments apply, and whether those terms are written into the contract or only described on a web page. If data residency matters for your organization, make the answer a condition of selection rather than a follow-up.
Next, confirm the Device Agent hardware list with FlowFuse for your exact boards. Node-RED 5.0 requires a 64-bit operating system and drops Raspberry Pi 3B and older, but the Device Agent may have its own platform requirements, and its documentation should be checked against the models you have in the field. Ask for the Kubernetes footprint of self-hosted FlowFuse as well: the node count, storage classes, database and any ingress or certificate components your platform team would need to run, along with the upgrade procedure for each release line.
Finally, settle backup and disaster recovery ownership for each model. On devices, confirm who captures flows, credentials and context data, where they are copied, and how a failed device is rebuilt. In Docker on your servers, your team owns volumes, database backups and restore testing. In managed hosting, ask the vendor which recovery point and recovery time objectives it commits to, what is included in the subscription, and what you must export yourself. Record these answers in the statement of work so that the scope and the recovery plan match.
How DeployOpen scopes and runs Node-RED deployments
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, so the Node-RED runtime, editor and device fleet are handled as part of a written scope. The work starts with where your flows must run and who can reach the editor, then carries through to a documented handover and optional ongoing support.
How we scope
- Confirm which flows run on physical devices, in Docker on your servers, or on a hosted platform, and why.
- Record the target hardware, operating system and Node.js version so the 64-bit and Node.js 22.9.0 minimum for Node-RED 5.0 is checked before work starts.
- Agree in writing who can reach the editor and admin API, and which authentication method applies to each network zone.
How we build
- Install and configure the chosen runtime, whether a device image, a Docker deployment or a FlowFuse instance in your cloud account.
- Set up HTTPS, editor authentication through Passport and basic authentication for HTTP nodes, so the editor is not left open by default.
- Test flow deployment, device update paths and rollback steps against your staging environment before anything moves to production.
How we hand over
- Deliver written documentation covering the runtime configuration, device inventory, update procedure and access model.
- Walk your operations and security teams through the upgrade path for Node-RED 4.x and 5.x releases and the reasons behind each setting.
- Provide a handover checklist that records what is in scope, what your team owns and which decisions remain open.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the initial build.
- Ask any quote to separate one-time setup from recurring retainer fees, hosting costs you pay directly and any FlowFuse licensing you choose.
