One Hub, deployed your way
Run on the managed Khorde Cloud, add sites near the field so operations survive a dropped link, or host the whole thing yourself — air-gapped if it has to be.
Hub
The center: control plane, GraphQL API, alarms, interlocks, command routing, and history. Run by Khorde in the cloud, or by you.
Site
A local extension of the Hub near a group of agents. Keeps them running and supervisable when the link to the Hub drops.
Agents
Docker images next to the equipment. Each speaks one field protocol, or calculates new values, and connects to the Hub or to a site.
Your apps
HMIs, dashboards, and integrations. Anything that speaks GraphQL, against the Hub or against a site.
Every topology below is a different arrangement of the same four pieces — the agents and their config don't change between them.
Khorde Cloud
Khorde runs the Hub. You run only the agents, next to your equipment, and they dial out to the cloud — nothing to open inbound on the plant network.
- Fastest start: create agents in the control plane, run their images, and they pull config on connect.
- Elastic and fully managed — scaling, upgrades, backups, and IAM are Khorde's job.
- Agents in any number of locations report to one Hub, and one GraphQL API sees them all.
Cloud, with sites near the field
The Hub stays in the cloud. Where a location can't afford to go blind when the WAN drops, put a site next to its agents: measurements, alarms, interlocks, and commands are evaluated locally, and a local HMI keeps working against the same API.
- Each agent connects either directly to the Hub or through exactly one site — mixing both is normal.
- Configuration is still authored centrally; the Hub syncs it to the site, which re-syncs when the link returns.
- A calculated agent can sit at a site to derive values from that site's measurements, or at the Hub to combine several sites.
Your own Hub, on-prem or air-gapped
The Hub runs on your infrastructure, under a license that works offline. Agents and sites connect to it exactly as they would to the cloud — no traffic has to leave your network.
- Standalone: every Hub service in one binary with its own database and IAM — a single docker compose up.
- Kubernetes cluster: the same services Khorde runs for the cloud, on your Kubernetes, scaling service by service.
- Standalone HA: several standalone Hubs joined into one cluster for fault tolerance — see 04.
- Sites connect to your Hub the same way they would to the cloud; how many is set by the license.
- Server agents (IEC 104 server) can feed an upstream control center from any of these topologies.
Standalone Hubs, highly available
Join several standalone Hubs into one cluster. If a Hub goes down, the others keep serving — redundancy without Kubernetes.
- HMIs and integrations reach the cluster through a load balancer, so any healthy Hub answers.
- Each site knows every Hub in the cluster and connects to one that's up.
- Agents connect to the cluster, not to a single Hub.
- The trade-off against the Kubernetes cluster: it adds fault tolerance, but you can't scale one service on its own.
Pick by who operates it and what the network allows
| Khorde Cloud | Cloud + sites | Self-hosted | Self-hosted HA (soon) | |
|---|---|---|---|---|
| Who runs the Hub | Khorde | Khorde | You | You |
| Internet access | Agents connect out over TLS | Sites and direct agents connect out over TLS | Not needed — can be fully air-gapped | Not needed — can be fully air-gapped |
| When a link drops | Affected agents wait for the Hub | Sites keep operating locally; direct agents wait | Only links inside your own network matter | Only links inside your own network matter |
| When a Hub fails | Handled by Khorde | Handled by Khorde; sites keep operating locally | Standalone: down until it's back. Kubernetes: as redundant as your cluster | The other Hubs in the cluster keep serving |
| Scaling | Elastic, managed | Elastic, managed | Standalone: one node. Kubernetes: service by service | Not service by service |
| Sites | Optional | Yes | Optional, per license | Optional, per license |