Proxus uses a Hub & Spoke topology: one Central Server (the Hub) manages a distributed network of Edge Gateways (the Spokes). This page explains what each component does, how they communicate, and what this architecture means for your deployment.
After reading this page, you will understand:
- The responsibilities of the Hub vs the Spokes
- How Gateways communicate with the Central Server
- What happens when a Gateway loses connectivity
- How to plan a multi-site deployment
Architecture at a Glance
Central Server
The Hub / SSoT
Gateway Site A
Edge Spoke
Gateway Site B
Edge Spoke
Industrial Assets
PLC, MQTT, Sensors
What the Hub Does
The Central Server is the Single Source of Truth (SSoT) for the platform. Nothing is configured at the edge level — every setting originates here.
| Responsibility | What It Means |
|---|---|
| Configuration Management | Device profiles, rules, functions, and integration settings are defined once and deployed to gateways |
| Orchestration | The Hub decides which gateway runs which workload, and pushes updates as a Deployment Manifest |
| Data Aggregation | Telemetry from all gateways is collected, stored in ClickHouse, and made available for dashboards and queries |
| User Interface | The Management Console provides a single window into all connected sites |
| Health Monitoring | Heartbeats and metrics from every gateway are tracked to detect issues before they escalate |
What the Spokes Do
Each Edge Gateway is an autonomous worker deployed close to industrial equipment.
| Responsibility | What It Means |
|---|---|
| Data Acquisition | Reads from PLCs, sensors, and devices using industrial protocols |
| Local Execution | Runs Rules and C# Functions without waiting for the Hub |
| Data Buffering | Store & Forward keeps collecting data during network outages |
| Network Isolation | Sits between the OT network and the IT/internet, minimizing the attack surface |
Gateways hold no configuration state. If hardware fails, replace it and apply the same token. The new gateway downloads its full workload automatically. See Stateless Edge.
How They Communicate
Gateways and the Central Server communicate through a high-performance messaging backbone (NATS with JetStream persistence). This design provides several critical advantages:
Outbound-Only Connections
Gateways initiate the connection to the Hub. No inbound firewall ports are required at the edge site. This is essential for OT networks where opening inbound ports is a security concern.
Guaranteed Delivery
JetStream persistence ensures that messages are not lost during network interruptions. Combined with Store & Forward, the platform guarantees zero data loss.
Bandwidth Efficiency
Only processed data flows over the WAN. High-frequency raw telemetry stays at the edge. Gateways send aggregates and on-change values, reducing bandwidth by up to 90%.
Real-World Scenario: 3 Factories, 1 Central Server
Consider a manufacturing company with three factories:
Central Server (Cloud or On-Premise Data Center)
├── Factory Istanbul (5 Gateways, 120 devices)
│ ├── Assembly Line 1-3
│ └── Packaging Area
├── Factory Ankara (3 Gateways, 60 devices)
│ ├── CNC Workshop
│ └── Quality Lab
└── Factory Bursa (8 Gateways, 200 devices)
├── Paint Shop
├── Body Shop
└── Final AssemblyHow this works in practice:
Single management point: One admin configures all 380 devices from the Management Console. Device profiles are standardized — the same "Siemens S7-1500 Standard" profile works in all three factories.
Local autonomy: When Factory Ankara loses internet for 2 hours, its 3 gateways continue collecting and processing data locally. Rules still trigger alerts via the local buzzer or display. When the connection restores, buffered data flows to the Hub in order.
Site-level security: Using object-level criteria in roles, users at Factory Istanbul only see their own devices and dashboards. They cannot see Factory Ankara's data.
Cross-site analytics: The Central Server has all telemetry in ClickHouse. Dashboards can compare OEE across factories, show aggregate production volumes, or track energy consumption across all sites.
Scaling Your Deployment
| Scenario | Architecture |
|---|---|
| Single site, 1-5 gateways | Central Server + gateways on the same local network |
| Single site, 5-50 gateways | Central Server on a dedicated machine, gateways on industrial PCs |
| Multi-site, shared Central Server | Central Server in cloud or data center, gateways at each site connecting over WAN |
| Multi-site, dedicated Central Servers | One Central Server per region, federated monitoring (advanced) |
Proxus scales horizontally by adding more gateways. The Central Server handles thousands of gateway connections. For capacity planning details, see Performance Benchmarks.
Gateway Types
| Type | Location | Purpose |
|---|---|---|
| System Gateway | Co-located with the Central Server | Internal system tasks, simulator testing, development |
| Remote Gateway | Factory floor, remote site, edge location | Production data acquisition from physical equipment |
Every Proxus installation includes a default SYSTEM gateway. You can start testing with it immediately and add remote gateways as you deploy to production. See Connect a Gateway.