Gateway Deployment and Architecture
Article Type: Concept Audience: Solution Architects, Enterprise Administrators, Partners Module: Edge Gateway, Fuuz Enterprise Applies to Versions: 2025.12
Fuuz is the first industrial operations platform to offer a true cloud-to-edge architecture that fundamentally transforms how manufacturing and industrial organizations deploy operational technology (OT) solutions. Unlike traditional on-premise-only MES/WMS systems that require extensive local infrastructure, or pure cloud platforms that depend on VPNs and complex network configurations, Fuuz provides a secure, scalable architecture where the cloud and on-premise worlds seamlessly converge.
The Fuuz architecture consists of these distinct layers:
- Fuuz Enterprise (Hub): The central platform providing infrastructure, scalability, and cross-app visibility
- Fuuz Apps (Cloud Edge): The IT/OT convergence point where business logic meets plant operations — previously called "tenants"
- Edge Gateways (On-Prem Edge): Secure tunnels connecting physical plant assets to their respective Fuuz Apps
- Edge Gateways (On-Prem Node): Deployed at the extreme edge at the machine
This architecture enables organizations to run full facility MES/WMS solutions on a single App, or deploy isolated point solutions for specific work cells, lines, or processes — all within the same Enterprise. The critical mass and infrastructure is handled by Fuuz in the cloud, while gateways serve as secure conduits to the physical site.
Note: Key Differentiator: Unlike traditional industrial software that requires VPNs, port forwarding, or complex network configurations, Edge Gateways establish secure outbound WebSocket (WSS) connections to the cloud. This approach is vastly more secure, reliable, and easier to deploy than legacy methods — requiring only standard HTTPS outbound access that most corporate firewalls already permit.
Important: Critical Limitation: Fuuz and the Edge Gateway are not designed to function as SCADA systems or Level 2 control systems. While the gateway supports bi-directional communications, edge screens, machine-to-machine communications, and distributed architectures, Fuuz does not support use in these capacities — especially when cloud hosted. For real-time process control requiring deterministic response times, safety-critical operations, or regulatory compliance requiring Level 2 system classification, implement purpose-built SCADA solutions at the appropriate automation level.
Fuuz Enterprise serves as the central hub for all industrial operations. A single customer Enterprise can consist of many Apps, regardless of how many physical locations exist. Enterprise can be deployed in three configurations:
- Fuuz Cloud (SaaS): Hosted and managed by Fuuz — the most common deployment
- Private Cloud: Customer-hosted in their own cloud infrastructure (AWS, Azure, GCP)
- Full On-Premise: Complete Fuuz stack deployed within customer facilities
Each Fuuz App (previously called "tenant") serves as the cloud edge — the critical convergence point between IT (Red) and OT (Blue) data domains. This is where:
- Logical and physical world mapping occurs
- Business logic for plant-level scenarios is implemented
- Enterprise data (Red) blends with operational data (Blue)
- Cross-system integrations are orchestrated
Apps can be scoped based on organizational needs:
| App Pattern | Description | Use Case |
|---|---|---|
| Full Facility App | Complete MES/WMS for an entire plant | Single plant operations with unified management |
| Point Solution App | Single work cell, line, or process | Isolated solutions where future enhancements must not impact other systems |
| Aggregation App | Consolidates data across multiple Apps | Enterprise dashboards, cross-plant analytics, central master data |
| Edge IoT App | High-volume data collection from multiple assets | Dedicated IoT data ingestion with multiple distributed gateways |
Note: The decision to use one App for a full facility versus multiple point solution Apps depends on how you want to manage the applications and how isolated you need them to be. Multiple Apps ensure that future enhancements to one will not have any adverse impact on another.
Apps within an Enterprise can communicate and share data through several patterns:
- Shared Enterprise Data Sets: Common master data (products, materials, customers) accessible across Apps
- Split Business Processes: Workflows spanning multiple Apps (e.g., MES hands off to WMS)
- Data Flow Integration: Apps communicate directly via Data Flows for real-time data exchange
- Aggregation Apps: Dedicated Apps that pull and consolidate data from multiple source Apps
The Edge Gateway operates exclusively in the Blue (OT) data domain, serving as a secure tunnel between physical plant assets and the Fuuz App in the cloud. Key characteristics:
- One-to-One Relationship: Each gateway connects to exactly one Fuuz App
- Secure WSS Tunnel: Outbound-only WebSocket connection — no inbound ports required
- OT Data Only: Interacts with plant/factory assets, machines, databases, and on-premise systems
- IT/OT Blend at App: The gateway delivers Blue data to the App where it blends with Red (IT) data
Note: The Edge Gateway is not required if your existing infrastructure (such as Kepware, Litmus, or Ignition) can publish data directly to Fuuz via APIs or MQTT. However, the gateway is essential when existing infrastructure cannot publish to the cloud, is too fragile to leverage, or when hybrid edge capabilities like Fuuz Edge Screens (HMIs) are required.
The following hierarchy illustrates a Fuuz Enterprise with multiple Apps and Gateways:
Fuuz Enterprise (Hub)
├── App A: "Plant 1 MES" (Cloud Edge - Full Facility)
│ ├── Gateway 1 (On-Prem Edge - Central Server)
│ └── Gateway 2 (On-Prem Edge - Distributed/Cell)
├── App B: "Plant 1 Quality" (Cloud Edge - Point Solution)
│ └── Gateway 3 (On-Prem Edge)
├── App C: "Enterprise Aggregation" (Cloud Edge - No Gateway)
└── App D: "Edge IoT Data" (Cloud Edge - High Volume)
├── Gateway 4 (Bottling Line 1)
├── Gateway 5 (Bottling Line 2)
├── Gateway 6 (Oven Control)
├── Gateway 7 (Packaging Station 1)
└── Gateway 8 (Packaging Station 2)
When the complete Fuuz stack is deployed on-premise, Fuuz connects directly to machine assets via Edge Connectors without requiring gateways. However, gateways may still be recommended in certain scenarios:
- Internal Network Reliability: When internal networking is unreliable, gateways provide Store and Forward capabilities
- Network Segmentation: When assets exist on isolated network segments that cannot reach the Fuuz server directly
- Distributed Edge Screens: When HMI applications require local gateway presence for optimal latency
- Redundancy Requirements: When individual cell/line isolation is required for high availability
- Edge Connector: The specific connector used to communicate with an asset (e.g., Ethernet/IP PLC, Modbus TCP, OPC-UA Client, MQTT Client, Native Printer)
- Edge Connector Type: The base connector category sharing common functionality (e.g., PLC, Printer, MQTT, Server, Modbus)
- Edge Connection: A configured connection to a specific asset using an Edge Connector
- Edge Subscription: A configuration that defines what data to collect from an Edge Connection and how to handle it (including Store and Forward options)
- Edge Gateway: The gateway instance that hosts Edge Connections and communicates with a Fuuz App
- Gateway Flow (Edge Flow): A Data Flow that runs on the gateway to collect, transform, and forward data from on-premise assets
- Store and Forward: A feature that locally buffers data when cloud connectivity is lost and automatically syncs when connectivity is restored
| Connector Type | Description | Common Use Cases |
|---|---|---|
plc |
Programmable Logic Controller connectors | Allen-Bradley Ethernet/IP integration, tag read/write |
pccc |
PCCC (DF1) protocol connectors | Legacy Allen-Bradley PLC communication |
opcua |
OPC Unified Architecture connectors | Universal industrial communication standard |
modbus |
Modbus protocol connectors | Industrial equipment communication over TCP/IP |
mqtt |
MQTT messaging connectors | Lightweight IIoT pub/sub messaging |
mqttSparkplug |
MQTT Sparkplug B connectors | Industrial IoT Sparkplug specification |
printer |
Printer connectors | Label printing, document output |
sql |
SQL database connectors | On-premise database integration |
http |
HTTP client connectors | REST API integration from edge |
server |
Server connectors | HTTP endpoints, MQTT broker, folder monitoring |
tcp |
TCP socket connectors | Raw TCP communication |
file |
File system connectors | Local file operations, folder monitoring |
remoteSystemCall |
Remote system call connectors | Execute remote procedures, SAP RFC |
| Connector ID | Connector Name | Connector Type |
|---|---|---|
ethernetIpPlc |
Ethernet/IP PLC | plc |
plcPCCC |
PCCC PLC | pccc |
opcuaClient |
OPC-UA Client | opcua |
modbusTCP |
Modbus TCP | modbus |
mqttClient |
MQTT Client | mqtt |
mqttBroker |
MQTT Broker | server |
mqttSparkplugB |
MQTT Sparkplug B | mqttSparkplug |
nativePrinter |
Native Printer | printer |
tcpPrinter |
TCP Printer | printer |
microsoftSql |
Microsoft SQL Server | sql |
mySql |
MySQL | sql |
oracledb |
Oracle Database | sql |
ibmdb2 |
IBM DB2 | sql |
HTTPClient |
HTTP Client | http |
HTTPServer |
HTTP Server | server |
TCPServer |
TCP Server | server |
tcpSocket |
TCP Socket | tcp |
localFile |
Local File | file |
sapRfc |
SAP RFC | remoteSystemCall |
The Edge Gateway is available as a Windows application or Windows service. This deployment method is suitable for:
- Small-scale deployments with limited functionality requirements
- Single gateway per physical or virtual machine
- Environments where containerization is not feasible
Important: Only one gateway instance can run per Windows virtual machine. Running multiple gateways on Windows requires separate VMs for each, which significantly increases management overhead compared to containerized deployments.
For large-scale deployments, container deployment using Docker with Portainer.io templates is strongly recommended. Benefits include:
- Multiple gateways per host machine
- Simplified management of Build, QA, and Production environments
- Easier scaling and orchestration
- Consistent deployment across environments
- Centralized update management and version tracking
- Reduced infrastructure overhead compared to multiple Windows VMs
Tip: Best Practice: Gateways should generally be deployed using a container approach with Docker and Portainer.io for the best management experience — enabling easy tracking of updates, version control, and multi-environment management. During implementation and continued development, organizations typically require Build, QA, and Production gateway installations.
The primary factor determining gateway requirements is data volume and throughput, not simply asset count. The following tables provide guidance for sizing gateway deployments based on common scenarios.
These scenarios assume data collection and monitoring use cases (read operations to the Fuuz App):
| Scenario | Assets | Points/Asset | Frequency | Updates/Sec | Updates/Min | Updates/Hour | Gateways |
|---|---|---|---|---|---|---|---|
| Simple Monitoring | 10 | 50 | 5 sec | 100 | 6,000 | 360,000 | 1 |
| Label Printing (Plant-wide) | 20 printers | N/A | On demand | Variable | Variable | Variable | 1 |
| Standard Asset Monitoring | 50 | 100 | 1 sec | 5,000 | 300,000 | 18,000,000 | 1-2 |
| High-Density Monitoring | 50 | 1,000 | 1 sec | 50,000 | 3,000,000 | 180,000,000 | 3-5 |
| Large Fleet - Low Frequency | 1,000 | 10 | 1 sec | 10,000 | 600,000 | 36,000,000 | 2-3 |
| Large Fleet - Standard | 500 | 100 | 1 sec | 50,000 | 3,000,000 | 180,000,000 | 3-5 |
| Enterprise Scale | 1,000 | 500 | 1 sec | 500,000 | 30,000,000 | 1,800,000,000 | 10-15 |
| High-Fidelity Process Data | 100 | 200 | 100 ms | 200,000 | 12,000,000 | 720,000,000 | 5-8 |
Note: Gateway counts are approximate and depend on additional factors including network bandwidth, data transformation complexity, and whether data is processed locally before cloud upload. Consider edge pre-processing via Gateway Flows to reduce cloud update volume.
For distributed manufacturing environments with bi-directional HMI requirements, a gateway-per-workstation model ensures optimal performance, redundancy, and availability:
| Scenario | Stations | Read Points | Write Points | Edge Screen | Gateways | Pattern |
|---|---|---|---|---|---|---|
| Single Assembly Cell | 1 | 50/PLC | 5/PLC | Yes | 1 | 1 gateway per cell |
| Small Assembly Line | 10 | 50/PLC | 5/PLC | Yes | 10 | 1 gateway per cell |
| Medium Assembly Facility | 50 | 50/PLC | 5/PLC | Yes | 50 | 1 gateway per cell |
| Large Manufacturing Plant | 100 | 50/PLC | 5/PLC | Yes | 100 | 1 gateway per cell |
| Multi-Site Enterprise | 500 | 50/PLC | 5/PLC | Yes | 500 | 1 gateway per cell |
| Warehouse with Mobile Stations | 25 | 20/station | 10/station | Yes (multiple users) | 2-3 | Centralized gateways |
Tip: Best Practice: For hybrid HMI solutions with bi-directional PLC communication, deploy one Edge Gateway per workstation/cell. This architecture provides multiple points of redundancy, high availability, and eliminates dependencies on internal network reliability for individual stations.
A single Edge Gateway connecting to a single App is appropriate for:
- Plant-wide label printing from a centralized queue
- Asset monitoring with 50 or fewer assets at moderate data volumes
- Monitoring 1,000+ assets with single data points collected at low frequency (e.g., one point per second)
- Limited bi-directional communication requirements
Deploy gateways centrally (like a primary gateway server) when:
- Data collection is the primary use case (minimal bi-directional control)
- Internal network reliability is high
- Centralized IT management is preferred
- Network-based printing or file folder monitoring is required
Distribute gateways throughout the plant for redundancy, availability, and isolation when:
- HMI applications require bi-directional PLC communication
- Edge Screens must remain operational during network disruptions
- Individual cell/line isolation is required for high availability
- Internal network reliability is questionable
Distribution with gateway-to-gateway communications — via MQTT Broker / Client
Tip: Best Practice: For bi-directional HMI capabilities, run the gateway as close to the node as possible. Keep the interface, backend application, and PLC physically proximate to minimize latency. Avoid long network runs and single points of failure.
For hybrid MES, WMS, or HMI solutions at scale:
- Deploy one Edge Gateway per HMI workstation
- Use Docker/Portainer to manage Build, QA, and Production gateways at each node
- Consider local databases (SQLite, PostgreSQL) alongside edge gateways for ultra-high availability
- Store critical data locally (work orders, bill of materials, recipes) for operation during internet outages
Store and Forward provides data resilience during connectivity interruptions between the gateway (On-Prem Edge) and the App (Cloud Edge):
- Data is first stored/logged locally on the gateway
- Data is then pushed to the Fuuz App when internet access is available
- During outages, data buffers locally and syncs automatically when connectivity resumes
- Typically supports 2–6 hours of buffering depending on data volume
- Available for most subscription types including Tag Values, OPC-UA Nodes, MQTT Topics, and TCP Sockets
When Store and Forward is enabled, the Continuous Values setting controls data transmission behavior:
- Enabled (default): All value updates are pushed to Fuuz
- Disabled: Only the most recent value for each data point is pushed to Fuuz
For more robust high availability beyond Store and Forward's capabilities:
- Install a local SQL Server, Oracle database, or historian alongside the gateway
- Use a Gateway Flow to pre-process and publish data to the local historian
- Create a second Gateway Flow to query the historian and push data to the Fuuz App
- Mark successfully synced data points with timestamps for auditing
- The Fuuz App supports this pattern via Flows, API calls, and Webhooks
Important: With Store and Forward enabled, the primary consideration is your internal network stability. For extended outage protection beyond 6 hours, implement the local database pattern described above.
While Edge Gateways connect directly to their respective Fuuz Apps, some deployments require real-time data sharing between gateways — for example, when one gateway processing machine data needs to share information directly with another gateway controlling downstream equipment.
To enable gateway-to-gateway communication, implement a centralized MQTT broker pattern using pub/sub messaging:
An Edge Gateway can function as an MQTT broker using the mqttBroker Edge Connector:
- Deploy one gateway configured as an MQTT broker on your local network
- Configure other gateways as MQTT clients (
mqttClient) connecting to the broker gateway - Use MQTT topics to route data between gateways in real-time
- Gateway Flows can publish and subscribe to topics for data exchange
For enterprise-scale deployments or advanced messaging requirements, consider third-party MQTT brokers:
| Broker | Description | Best For |
|---|---|---|
| HiveMQ | Enterprise MQTT platform with clustering and cloud options | Enterprise scale, mission-critical deployments |
| EMQX | High-performance, scalable MQTT broker | High throughput, IoT at scale |
| Mosquitto | Lightweight open-source MQTT broker | Small deployments, edge computing |
| VerneMQ | Distributed MQTT broker for clustering | High availability, distributed systems |
| AWS IoT Core | Managed MQTT service in AWS | Cloud-native, AWS ecosystem |
To set up distributed gateway communication:
-
Deploy MQTT Broker: Either configure an Edge Gateway with the
mqttBrokerEdge Connector or deploy a third-party broker on your network -
Configure Client Gateways: Add
mqttClientEdge Connectors on each gateway that needs to participate in distributed messaging -
Define Topic Structure: Establish a topic hierarchy for your data (e.g.,
plant/line1/cell3/status) - Create Gateway Flows: Build flows that publish data to topics and/or subscribe to topics from other gateways
-
Optional — Sparkplug B: For standardized industrial messaging, use the
mqttSparkplugBEdge Connector
Note: Distributed gateway communication via MQTT operates independently from the Fuuz App connection. Each gateway still maintains its WSS connection to its Fuuz App while simultaneously participating in local MQTT messaging.
The Edge Gateway is the preferred choice for most deployments. However, if your organization has existing industrial infrastructure, direct integration may be possible:
| Platform | Integration Method |
|---|---|
| Kepware | Push data via Fuuz APIs or MQTT broker |
| Litmus Edge | Push data via Fuuz APIs or MQTT broker |
| Ignition | Push data via Fuuz APIs or MQTT broker |
| Other OPC-UA/MQTT Systems | Configure MQTT broker for Fuuz connection |
- Existing infrastructure cannot publish data to cloud endpoints
- Existing infrastructure is fragile and you want to avoid additional load
- Hybrid solutions requiring Fuuz Edge Screens (HMIs)
- Bi-directional control from the Fuuz App
- Project requirements favor centralized gateway management
Deployment architecture depends on several factors unique to each implementation:
| Factor | Considerations | Recommendation |
|---|---|---|
| App Scope | Full facility MES vs. isolated point solutions | Multiple Apps for isolation; single App for unified management |
| Physical Site Constraints | Network topology, equipment locations, existing infrastructure | Deploy gateways close to controlled equipment |
| Application Type | Cloud-only MES, Hybrid MES/WMS, HMI applications | HMI requires edge deployment; cloud-only can use centralized gateways |
| Communication Direction | Data collection only vs. bi-directional control | Bi-directional requires gateways at point of control |
| Data Volume & Frequency | Points per asset, collection frequency, sub-second requirements | High volume/frequency requires multiple gateways or local pre-processing |
| Availability Requirements | Acceptable downtime, data loss tolerance | Enable Store and Forward; add local DB for critical operations |
| Edge Screen Deployment | Full warehouse app vs. single HMI per workstation | Match gateway deployment to screen deployment pattern |
| Gateway-to-Gateway Communication | Machine-to-machine messaging, distributed processing | Implement MQTT broker architecture for real-time data sharing |
| Cross-App Requirements | Shared data, split processes, enterprise aggregation | Use Data Flows for inter-App communication; consider an aggregation App |
While the Fuuz architecture is highly flexible, certain limitations should be considered during planning:
- Gateway is not a server: The gateway is a client application without unlimited scaling capabilities
- One gateway to one App: Each gateway connects to exactly one Fuuz App
- High-volume/high-fidelity data: Sub-second frequencies with high data volumes may require multiple gateways or pre-processing
- Single instance per Windows VM: Container deployment recommended for multi-gateway scenarios
- Store and Forward capacity: Typically 2–6 hours depending on data volume; extended outages require local database solutions
Important: SCADA/Level 2 System Limitation: Fuuz and the Edge Gateway should not be used as SCADA systems or Level 2 control systems in the ISA-95/Purdue Model hierarchy. While the platform supports bi-directional communications, edge screens, machine-to-machine communications, and distributed architectures, these capabilities are intended for Level 3+ (MES/MOM) operations and data collection use cases — not real-time process control.
This limitation is especially important for cloud-hosted deployments where network latency and internet connectivity cannot guarantee the deterministic response times required for safety-critical or time-sensitive control operations. For Level 2 requirements, implement purpose-built SCADA/DCS solutions and use Fuuz for supervisory data collection and higher-level operations.
Note: There are no specific limitations on the number of gateways per Fuuz App, the number of Apps per Enterprise, nor on the number of Edge Connections per gateway. The deployment architecture should be driven by the factors outlined in this guide rather than arbitrary platform constraints.
- Fuuz Industrial Operations Platform
- IIoT Nodes Reference
- Event Nodes (Edge Subscription)
- Portainer.io — Container Management
- HiveMQ — Enterprise MQTT Platform
- EMQX — Scalable MQTT Broker
- Eclipse Mosquitto — Open Source MQTT Broker
| Issue | Possible Cause | Resolution |
|---|---|---|
| Gateway not connecting to Fuuz App | Firewall blocking WSS connections | Ensure outbound WSS (port 443) is allowed to Fuuz endpoints |
| Data not appearing in Fuuz | Edge Subscription not configured or deployed | Verify Edge Connection, Edge Connector, and Edge Subscription configuration; ensure deployment to correct environment |
| HMI latency issues | Gateway physically distant from PLC | Relocate gateway closer to controlled equipment; minimize network hops |
| Data loss during outages | Store and Forward not enabled | Enable Store and Forward on Edge Subscriptions; consider local database for critical data |
| Gateway performance degradation | Excessive data volume or high-frequency subscriptions | Distribute load across multiple gateways; pre-process data with Gateway Flows; reduce scan rates |
| Cannot run multiple gateways on single machine | Windows installation limitation | Migrate to Docker/Portainer container deployment |
| MQTT messages not reaching other gateways | Broker misconfiguration or topic mismatch | Verify broker connectivity; check topic names match exactly; test with MQTT client tool |
| Cross-App data not syncing | Data Flow integration not configured | Configure Data Flows for inter-App communication; verify shared enterprise data set permissions |
| Version | Date | Editor | Description |
|---|---|---|---|
| 1.0 | 2024-01-02 | Fuuz Documentation Team | Initial Release |
| 2.0 | 2025-01-02 | Fuuz Documentation Team | Updated architecture section with Enterprise/App/Gateway hierarchy; added IT/OT (Red/Blue) data domain concepts; updated terminology (App, Edge Connection, Edge Connector, Edge Subscription, Edge Gateway); added cross-App communication patterns; expanded deployment scenarios |
- Edge-Connections-Complete-Industrial-Integration-Reference
- IIoT-and-Gateway-Nodes
- Edge-Gateway-Flows
- Gateway-System-Requirements
- Data-Flow-Design-Standards-Design-Standards
Source: support.fuuz.com