Skip to main content

How Arch Systems Connected 100+ Factory Databases with FlowFuse

Arch cut new-customer rollout time to a fraction of what it was, without adding operational complexity

Sumit Shinde, Technical Writer •
Back to Blog Posts
Image representing null
TL;DR

Arch Systems needed to connect 100+ factory databases across diverse MES systems and environments without rebuilding every integration. By standardizing reusable subflows in FlowFuse's low-code environment and managing deployments through FlowFuse DevOps pipelines, Arch made each integration cheap to build and cheap to maintain, cutting new-customer rollout time to a fraction of what it was.

Arch Systems builds an AI copilot for manufacturers, and to power it the company connects more than 100 factory databases into a single analytics platform. Each one lives in a different production environment. Each one speaks to a different MES. Across them sits a tangle of diverse APIs and databases that rarely share conventions. Connecting any single database was never hard. Connecting the hundredth without rebuilding the work from scratch is the problem worth solving.

That copilot reads dashboards, synthesizes production data, and hands operators and engineers prescriptive guidance in real time, no infrastructure overhaul required. But a copilot is only as good as the data feeding it. In a factory, that data sits in the least cooperative layer of the stack: the gap between the shop floor and enterprise IT, where MES systems, databases, and APIs rarely agree on anything.

Here is the part that matters. Arch didn't just connect the data. They made the choice to connect it once and repeat the result reliably. That choice is the story.

The cost lives in the repetition, not the connection

Connecting one factory system to one platform is a solved problem. Most competent teams clear it. The cost shows up on the second integration. Then the tenth. Then the hundredth.

Hand-built integrations don't compose. Every new customer becomes a separate project. A fix you apply in one environment never reaches the others, so the maintenance surface grows with every deployment, and configuration errors creep in, environments that should be identical pulling apart until something breaks in production. Past 100 databases across multiple environments, that approach collapses. The integration layer stops being plumbing. It becomes the ceiling on how fast the business can grow.

For a company whose entire job is onboarding manufacturers, that ceiling sets the roadmap. So Arch refused to accept it.

Standardize the unit of work

Arch stopped treating each integration as a project. They started treating it as a template.

Working in FlowFuse's low-code environment, the team built standardized, reusable subflows that automate job creation in Arch React. The subflow is the unit of work: a packaged, parameterized piece of logic that does one job the same way on every deployment. Onboarding a new customer shifted from building an integration to deploying a known-good template and adjusting the edges. Do the engineering once. Configure everything after that.

Beneath that layer, MQTT brokers connect straight to the MES systems and open a reliable path for live production data. The flows take the stream, filter it, and generate tasks automatically from the processed production data. The architecture responds to production events immediately, which is what turns raw shop-floor activity into real-time insight.

Arch did this on top of the MES systems already running on the floor, not by replacing them. FlowFuse sits as a low-code layer above them, connecting to existing factory systems rather than forcing a rebuild. It runs as part of Arch's broader technology stack, working alongside the company's own platform capabilities and its other partner technologies rather than standing alone.

DevOps: one place to change everything

Standardized subflows make each integration cheap to build. FlowFuse's DevOps model makes each integration cheap to maintain. For anyone running a system at this scale, the second property is the one that decides whether the first one survives.

FlowFuse manages every instance running your flows from a single platform, and its deployment pipelines propagate changes across development and production environments. Arch edits in one place and pushes the change to every production instance automatically. No instance-by-instance patching. No divergence between deployments that are supposed to match. Fewer configuration errors, because the system runs on one source of truth instead of dozens of hand-managed copies.

Two distinct properties, one outcome. One keeps the cost of building low. The other keeps the cost of maintaining low. Together they break the link between Arch's growth and its operational load. Arch adds customers without adding the same weight to the team keeping everything running.

Results

  • More than 100 databases connected through automated subflows. Every integration runs on the same FlowFuse-orchestrated pattern rather than a hand-built connection, which is why the hundredth database came online on the same proven path as the first.
  • New-customer rollout cut to a fraction of the time. Reusable subflows replaced manual configuration, cutting the time to bring a new customer online to a fraction of what it once took and removing the per-customer engineering that had limited how fast Arch could grow.
  • Reliable real-time processing across diverse systems. MQTT pipelines paired with FlowFuse-managed environments keep live production data consistent and dependable, regardless of how different each customer's MES happens to be.
  • A single edit reaches every environment at once. Single-point editing and centralized deployment pipelines propagate updates across all production instances simultaneously, with no divergence between environments and no instance-by-instance patching, so the cost of maintenance no longer rises with each new deployment.

Taken together, these results separate Arch's growth from its operational load. The standardized subflows keep each integration inexpensive to build, the centralized DevOps model keeps it inexpensive to maintain, and the combination lets Arch add customers without adding the same weight to the team that keeps everything running. As Arch describes it, the ability to edit once and deploy everywhere added real efficiency to how the team manages integrations.

What comes next

Arch keeps expanding the platform: more data sources, more third-party integrations, more manufacturing customers. Because the foundation is templated and centrally managed, each addition starts from proven ground instead of an empty canvas.

The first 100 databases were never the result that mattered. The architecture is. The next 100 cost a fraction of what the first ones did.

Read the full story on the FlowFuse customer page.

Scaling integrations across many environments?

See how FlowFuse helps teams standardize, deploy, and maintain industrial data integrations from a single platform. Talk to us about your setup.

Frequently Asked Questions

About the Author

Sumit Shinde

Technical Writer

Sumit is a Technical Writer at FlowFuse who helps engineers adopt Node-RED for industrial automation projects. He has authored over 100 articles covering industrial protocols (OPC UA, MQTT, Modbus), Unified Namespace architectures, and practical manufacturing solutions. Through his writing, he makes complex industrial concepts accessible, helping teams connect legacy equipment, build real-time dashboards, and implement Industry 4.0 strategies.

Related Articles:

Sign up for updates