System Architecture
One codebase, four ways to run: a single binary at the edge, a container, Kubernetes, or a fleet hub with edge sites.
How MaestroHub Is Built
This page describes Context Engine, the MaestroHub product you run today (see What MaestroHub is for the three products). Context Engine is made up of modules: authentication, authorization, connectors, the pipeline engine and scheduler, the unified namespace, audit, and more. Together they handle everything from connecting to a PLC to rendering a live dashboard.
The same modules run in every shape, with the same APIs and the same UI. The two ends are:
Single Binary
All modules run inside a single process. The system database (SQLite), the message bus (NATS with JetStream), the MQTT broker and the historian (Pebble) are all embedded. You download one file, run it, and everything works, with no infrastructure to set up. The same binary also ships as a container. This is how most teams start.
Kubernetes
Each module becomes its own independently deployable microservice on Kubernetes. Services communicate through NATS (request/reply, event streaming, leader election). Data is stored in external managed systems like PostgreSQL, TimescaleDB, and EMQX that can be scaled, replicated, and backed up independently.
Everything you build in one mode works in the other. Pipelines, dashboards, connections, and configurations are fully portable. Start on your laptop, deploy to Kubernetes later, with no rework.
The shape is a deployment choice, not an edition: Foundation and Enterprise are licences, described on Editions.
Fleet Manager: one place for many deployments
An optional, separate instance that manages all your MaestroHub deployments from one dashboard. You need it only when you run more than one deployment; a single deployment manages all of its sites natively.
When you run multiple MaestroHub instances across factories, offices, or regions, you need a way to manage them without logging into each one. Fleet Manager solves this.
Every MaestroHub instance, whether it runs as a single binary or on Kubernetes, sends periodic heartbeats to the Fleet Manager. These heartbeats carry health status, resource usage (CPU, memory, disk), and per-organization execution metrics (pipeline runs, success rates, throughput). Critically, communication is one-way: instances push to Fleet Manager, not the other way around. Fleet Manager never initiates connections to your instances, which means no inbound ports need to be opened on your factory network, a deliberate security decision.
From a single dashboard, you can:
- Distribute licenses. One master license key is automatically split into per-instance entitlements. No manual activation per factory.
- Push configuration. SSO settings (OIDC, SAML, LDAP) and system-level config are pushed centrally. Change it once, every instance picks it up.
- Monitor fleet health. See which instances are healthy, degraded, or offline. Drill into per-organization metrics across your entire fleet.
- Count seats by organization. Every organization on every instance counts as one seat. If Berlin has 3 orgs, Munich has 2, and HQ has 5, that is 10 seats total, counted by organizations, not by instances.