Skip to content
MaestroHub
Menu
DocsFree trialStart the pilot

Product · Deployment reference

Three ways to run it, one product.

Three deployment tiers cover everything from a single factory to a multi-site enterprise. Pick the tier that matches the site; the same configuration model scales between them.

01 At a glance

How MaestroHub runs at each site.

Lightest

Tier 1

Single site only. Embedded stack, native binary install, no Docker, no high availability. Smallest footprint.

Multi-site, no high availability

Tier 2

Runs on one K3s node. Natively manages many sites from a single instance. Runs centrally or on site.

Enterprise, highly available

Tier 3

Full enterprise stack with application-tier high availability across a three-node Kubernetes cluster. Multi-site. Runs centrally or on site.

A different question

The three tiers answer "how does MaestroHub run at one site?" Managing many sites from one deployment is a separate capability. It works on Tier 2 and Tier 3.

Tier is not location

Tiers describe deployment shape, not where the software runs. Any tier can be placed at a factory site or centrally, in a cloud or your own data centre.

02 Managing multiple sites

Included with the Enterprise licence, on both Tier 2 and Tier 3. There is no separate add-on product to license, install or operate.

Pattern A · one deployment, many sites

One central instance

A single MaestroHub deployment manages all sites natively. Sites stream data; no software is installed at the sites. No Fleet Manager is needed, because there is only one deployment to operate. The central instance can live anywhere: cloud, an on-premises data centre, or Kubernetes at one of your factory sites.

New site provisioning is configuration only. No hardware order, no install, no field engineer visit.

Good for

  • New sites are added as configuration
  • One install, one upgrade, one place to operate
  • Lowest total infrastructure cost

Trade-offs

  • Sites depend on the WAN: an outage stops the data flow
  • Not suitable for sub-second control loops
  • Data leaves the site (sovereignty and OEM rules)
Use it for
Warehouses, R&D labs, regional offices, and light monitoring sites with reliable connectivity.
Central instance
Tier 2 (about 1 to 10 sites) or Tier 3 (a large fleet, or high availability needed)

Pattern B · many deployments, optional fleet management

Fleet Manager

Relevant only when you have several separate MaestroHub deployments, for example Tier 1 installs across several factories. A Fleet Manager coordinates the fleet: monitoring, licensing and updates across deployments. It is optional and recommended for operational simplicity. Skip it if you run a single instance, or are comfortable operating a couple independently.

Good for

  • Each site is resilient and survives WAN outages
  • Sub-second control loops stay local
  • Data sovereignty: production data stays on site

Trade-offs

  • Each site needs its own install and upgrade
  • Higher total hardware footprint
  • More moving parts to operate
Use it for
Production factories with real-time control, offline tolerance requirements, or data residency rules.
Central instance
Tier 2 (about 1 to 10 local sites) or Tier 3 (a large fleet, or high availability needed)
Mix both patterns freely

Critical factories run their own local MaestroHub. Light sites are added to a central instance as configuration, with no hardware and no install. A central instance only manages the sites inside its own deployment; once you have more than one deployment, you can add a Fleet Manager as a separate instance for one view across all of them. It is recommended for simplicity, not required.

03 How the pieces fit together

One site, seen from the factory floor outwards.

Factory floor

PLCOPC UA
PLCModbus
SCADAMQTT
SensorREST

Telemetry in, governed writes back

Tier 1 at the sitesingle binary

MaestroHub runtimenative systemd or Windows service
Pebbleembedded store
MQTTembedded broker
Local bufferkeeps working through an uplink outage

8 cores · 16 GB RAM · 200 GB SSD, about a workstation PC

Fleet Manageroptional

Site monitoringhealth, metrics, alerts
Licences and updatescentral rollout

8 cores · 8 GB RAM · 100 GB, K3s single node, for about ten sites. Add it only when you have two or more deployments.

An alternative for the site itself

If a site needs multi-site management or high availability, install Tier 2 or Tier 3 there in place of the Tier 1 binary.

04 What hardware do I need?

Per-machine specifications to procure.

Tier 1

1 machinesingle binary install

CPU
8 cores
RAM
16 GB
Storage
200 GB SSD

Think: A high-spec workstation or industrial PC

Tier 2

1 machineK3s, single node

CPU
16 cores
RAM
24 GB
Storage
500 GB SSD

Think: A single mid-range server, rack or tower

Tier 3

3 machinesidentical Kubernetes nodes

CPU per node
16 cores
RAM per node
24 GB
Storage per node
500 GB SSD
Cluster total
48 cores · 72 GB · 1.5 TB

Think: A small server rack with three identical nodes

For multi-site management

The central instance uses the same Tier 2 or Tier 3 specification shown above, wherever it is deployed. No separate "manager" hardware is needed.

What "high availability" covers on Tier 3

Tier 3 provides application-tier high availability only. The infrastructure underneath is the customer's responsibility.

MaestroHub handles

  • Pod replication across the three Kubernetes nodes
  • TimescaleDB primary and replicas, with automatic failover
  • EMQX cluster: the broker survives a node loss
  • NATS cluster: internal messaging keeps quorum
  • Elasticsearch index replicas, distributed

You handle

  • Multi-zone or multi-region placement of nodes
  • Redundant network, load balancer and DNS
  • Storage availability (no single SAN behind three nodes)
  • Power redundancy and data centre operations
  • OS patching, node replacement, Kubernetes upgrades

05 Supported platforms

Operating systems and runtime requirements per tier. All three tiers run on amd64 and arm64: no proprietary OS, no vendor-locked hardware.

Tier 1, native install

Windows
10, 11, Server 2016 / 2019 / 2022
macOS
12 and later, Intel and Apple Silicon
Linux
Ubuntu 20.04+, Debian 11+, RHEL 8+
Docker
amd64 and arm64 images

Runs as a native service. No container runtime required.

Tier 2, K3s

Host OS
Ubuntu 20.04+, Debian 11+, RHEL 8+
K3s
1.26+ (bundled installer)
Helm
3.x
Storage
Local-path provisioner by default, or any K3s-compatible storage class

K3s is installed and managed by MaestroHub. No separate Kubernetes expertise needed.

Tier 3, Kubernetes

Kubernetes
1.26+: EKS, AKS, GKE, or on-premises (Rancher, OpenShift, vanilla)
Helm
3.x
Ingress
nginx, traefik, or any standard ingress controller
Storage
A StorageClass with dynamic provisioning; block storage recommended

Works on any conformant Kubernetes, cloud-managed or on-premises.

06 Which tier do you need?

Answer two questions.

1Is high availability required?
YesTier 3three-node Kubernetes cluster
Nogo to question 2
2Do you need to manage several sites from one instance?
YesTier 2one K3s node
NoTier 1single binary at the site
+Do you have two or more deployments?
YesAdd Fleet Managerone place to monitor, license and update them

07 What is inside each tier

The same architecture at a different scale.

Swipe sideways to see every column

ComponentTier 1Tier 2Tier 3
Deploymenthow it runsNative serviceK3s, single nodeKubernetes, three nodes
Packaginginstaller formatBinary and installerHelm chartHelm chart
Metadata databaseconfiguration and relationalEmbeddedPostgreSQLPostgreSQL
Time-series databasetelemetry storageEmbedded (Pebble)TimescaleDBTimescaleDB
MQTT brokerdevice messagingEmbeddedEMQXEMQX cluster
Internal messagingservice-to-service busIn-processNATSNATS cluster
Search and logsfull-text searchPostgreSQL (built in)Elasticsearch
Monitoringmetrics and alertsBuilt inBuilt inPrometheus
High availabilityapplication tier only; infrastructure availability is the customer's responsibilityApplication-tier
Docker requiredruntime dependencyNoNo (uses K3s)No (uses Kubernetes)

08 Questions

What procurement and operations teams ask first.

OperationsCan we start with Tier 1 and move to Tier 2 or 3 later?

Yes. All three tiers share the same configuration model. From Tier 1 to 2: install K3s on the same machine and import the embedded data into PostgreSQL. From Tier 2 to 3: add cluster nodes and switch the backends to TimescaleDB and Elasticsearch, automated by migration tooling. Plan one to two days of migration services per upgrade.

LicenseWhich connectors and protocols are included?

The licence includes the standard MaestroHub connector library: common industrial protocols such as OPC UA, Modbus, MQTT, REST, S7, EtherNet/IP, BACnet, file and CSV, and others. There is no per-connector or per-protocol metering. Specialised industry connectors or advanced modules, if they apply to your use case, are confirmed in the commercial agreement.

OperationsWith one central instance, who pays for infrastructure and data transit?

MaestroHub is software you deploy, not a hosted service. The central instance's infrastructure is owned and paid for by the customer, wherever it lives. Hosted in a cloud, you pay the provider for nodes, storage and egress, and egress is the main cost that grows with each site. Hosted on premises or at a factory, there are no cloud bills, only hardware and your own network, which is often the lowest total cost when you already own data centre capacity.

ServicesWhat does implementation involve, for the first site and for each one after?

The first site covers architecture sizing, network and security integration, connector configuration, training and acceptance: typically two to eight weeks of professional services, depending on protocol mix and integration depth. Each further site under a central instance is configuration only, often done by your own team after first-site training. With local deployments, each new local MaestroHub repeats a slimmer version of the first-site setup. Detailed scoping yields a fixed-bid quote.

ServicesWhat is the support model?

Standard Enterprise support includes ticketing and knowledge base access. The premium tier adds 24/7 Slack support. Maintenance releases and security patches are included in all tiers.

OperationsHow often are upgrades released, and what downtime do they need?

MaestroHub follows a quarterly minor-release cadence with monthly security patches. Tier 3 uses rolling Helm upgrades: pods restart one after another and the service continues. Tier 2 is a single-node restart, typically under five minutes. Tier 1 is a native service restart, under a minute per site. Upgrades are customer-controlled: you choose when to apply them.

StrategyIf MaestroHub is acquired or goes out of business, what protects us?

MaestroHub stores all customer data in open, documented formats: PostgreSQL and TimescaleDB rows, MQTT messages, YAML and JSON configuration. You can export data at any time with standard database tooling, and configurations can be versioned in Git. Source code escrow is available through the commercial agreement. You always own your data, your configurations and your hardware.

OperationsCan Tier 2 or Tier 3 be deployed at a factory site instead of Tier 1?

Yes. Tiers describe deployment shape, not location. Tier 1 is the lightest option and is typical for a factory that needs local control at one site. But any tier can be placed at a factory site: if the site needs multi-site management on premises, or application-tier high availability of its own, install Tier 2 or Tier 3 there. The reverse holds too: Tier 2 and Tier 3 can live at a factory, in your data centre, or in a cloud.

OperationsIs Fleet Manager required for multi-site or multi-plant deployments?

No, Fleet Manager is optional. Multi-site management is handled natively by a single Tier 2 or Tier 3 instance. Fleet Manager becomes relevant only when you have several separate MaestroHub deployments and want one place for monitoring, licensing and updates across all of them. We recommend it once you have two or more deployments, but you can skip it if you run a single instance.

Want it sized for your sites?

The six-week pilot starts on one VM with no production writes. We size MaestroHub for your sites, your protocol mix and your growth plan, and give you the deployment plan in writing.

Cookie preferences

Choose which categories of cookies you allow. Strictly necessary cookies are always on because the site cannot function without them.