Infohub Architecture at a Glance

The database is the centre#

Everything in Infohub — the model, the configuration, the calculated values, the chart definitions, the deployment layout, the log — lives in a single SQL Server database.

That has a useful consequence: the database is the system of record, and every component is stateless relative to it. Flow Config edits it. The Data Engine reads its configuration from it and writes values back into it. Flow Server reads values out of it to draw charts. Nothing holds important state anywhere else, which is why backing up the database backs up Infohub.

One service: Flow Bootstrap#

Infohub installs exactly one Windows service, called Flow Bootstrap. Its own description says what it does: it hosts a Flow Platform and its service objects.

This is the fact that clears up most architectural confusion. The Data Engine is not a Windows service. Neither is Flow Server, nor the Message Engine. They are service objects that you define in the model, and Bootstrap starts, stops, supervises, and hosts them on the machine it runs on.

Windows Server
+-- Flow Bootstrap                 < the only Windows service
    +-- Platform "Default"         < a host entry in the model
        +-- Connections            < data source connections
        +-- Engines                < Data Engine: retrieve, aggregate, calculate
        +-- Servers                < Flow Server: charts and dashboards over HTTP
        +-- Integration Engines    < run data consumers
        +-- Message Engines        < evaluate limits, raise notifications
        +-- Notification Servers   < deliver email, Teams, Slack, SMS
        +-- Consumers              < publish data downstream

Bootstrap listens on port 4501 (with 4500 also in use) and is how components discover and authenticate to each other, including across servers.

The Platform is the host#

A Platform in the Infohub model represents a machine that runs Infohub components. It carries a Host name, and Bootstrap on that machine claims the Platform whose host matches.

A fresh installation gets one Platform, and for most sites that is all they ever need: one server, one Platform, everything hosted on it. Platforms matter when you grow:

• Split the load. Put the Data Engine on one server and Flow Server on another by defining two Platforms and placing the service objects accordingly.
• Reach a network you cannot reach directly. A Platform can be marked Remote, and Platforms can be nested under a parent, so a Bootstrap in a plant network can host connections to equipment that the central server cannot see.
• Separate concerns. A heavy reporting workload can be isolated from collection.

The service objects#

Each service object does one job.

Data Engine. The heart of Infohub. It works out which measures need values for which intervals, asks the data sources for the raw data, aggregates and calculates up the chain, and writes results into the database. Most "Infohub is not producing numbers" questions are Data Engine questions. See Running the Data Engine.

Flow Server. Serves the web client — dashboards, charts, forms — over HTTP to browsers and to Flow Mobile. It reads calculated values; it does not calculate.

Integration Engine. Runs the data consumers, pushing calculated values outward to SQL, Snowflake, MQTT, Kafka, Event Hub, and other Infohub instances.

Message Engine. Evaluates limits and message definitions, decides when something needs to be said, and hands messages to Notification Servers.

Notification Servers. Deliver a message over a specific channel — email, Teams, Slack, Telegram, SMS, a file drop.

Report Server. Renders and distributes scheduled reports.

Each object type has its own property set, and each is placed on exactly one Platform.

Two further pieces run alongside the service objects and are worth knowing by name, because they appear in Task Manager and in diagnostics:

The Data Source Host is the process in which data source plugins execute — connections run inside it rather than inside the engine itself, which isolates a misbehaving connector from the calculation work. When retrieval degrades and the engine looks healthy, this process's memory and CPU are the next thing to check: a leaking or overloaded Data Source Host presents as slow or failed queries and missing report data while everything else looks normal.

The Monitor, inside Flow Config's Deployment view, is where the engines' live activity is visible — backlogs, pending event periods, and faulted items. It is the screen that answers "is Infohub behind, or broken?" See Monitoring Infohub and Its Health.

Connections and plugins#

A connection binds the model to an external system. It names a connector — one of the 31 data sources — and carries that connector's properties: server address, credentials, database, query, whatever that particular system needs.

Connectors are plugins. They are packaged separately from Infohub itself, loaded at runtime, and can be added without rebuilding Infohub. That is how an Infohub instance can talk to a historian released after the Infohub version it is running.

Flow Config and the CLI#

Flow Config is a .NET 8 Windows desktop application. It connects directly to the SQL database — it is not a client of an Infohub server — and it is where the model, charts, deployment, and templates are all edited.

Everything Flow Config can do, the Config CLI can do too. It is the same executable driven by command-line options, which makes model building scriptable, repeatable, and reviewable. See Automation & the Config CLI.

How a value gets from a tag to a dashboard#

Putting it together, the path of a single number:

1. You define a Retrieved measure in Flow Config against a connection, and deploy it.
2. Bootstrap notices the deployed configuration and the Data Engine picks it up.
3. The Data Engine asks the connector for the tag's values for the interval that is due.
4. It stores the result, then walks up the chain — aggregating to hourly, daily, monthly — and evaluates any calculations that depend on what changed.
5. The Message Engine checks the new values against their limits and raises anything necessary.
6. The Integration Engine sends the values to any consumer configured to receive them.
7. A user opens a dashboard; Flow Server reads the stored values and draws the chart.

Every step is driven by configuration in the one database, which is why the deploy step in item 1 matters so much.

Minimum and typical deployments#

For multi-site patterns see Multi-Site Architecture.

See also#

• What Infohub Is and How It Fits
• Installing Infohub
• Deploying Configuration
• Running the Data Engine