Help Center

Build Apps · Gateways & Connections

Gateway Deployment & Architecture

Last updated September 28, 2026, 2:22 PM UTC · fuuz.com/help/gateway-deployment-architecture

Article Type: Concept
Audience: Solution Architects, Enterprise Administrators, Partners
Module: Fuuz Gateway, Fuuz Enterprise
Applies to Versions: 2025.12

1. Overview

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 three 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"
Fuuz Gateways (On-Prem Edge): Secure tunnels connecting physical plant assets to their respective Fuuz Apps
Fuuz 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.

Key Differentiator: Unlike traditional industrial software that requires VPNs, port forwarding, or complex network configurations, Fuuz 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.⚠️ Critical Limitation: Fuuz and the Fuuz 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.

2. Architecture & Core Concepts

Fuuz Enterprise (Hub)

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

Fuuz Apps (Cloud Edge)

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.

Cross-App Communication

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

Fuuz Gateway (On-Prem Edge)

The Fuuz 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

[Illustration: Data domain diagram showing Blue (OT) data flowing from Gateway through WSS tunnel to App where it blends with Red (IT) data]

Note: The Fuuz 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.

Architecture Hierarchy

The following diagram illustrates the Fuuz Enterprise architecture 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)

[Illustration: Visual architecture diagram showing Enterprise hub with multiple Apps as cloud edges, each with their respective gateways as on-prem edges connecting to plant floor assets]

Full On-Premise Deployment

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

Key Definitions

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 Fuuz 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

3. Edge Connector Types

Supported Connector Types

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

Supported Edge Connectors

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

4. Gateway Deployment Options

Windows Application or Service

The Fuuz 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.

Container Deployment (Recommended)

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

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.

5. Capacity Planning & Sizing

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.

System Requirements

Minimum and recommended host specifications for a Fuuz Gateway installation, based on deployment pattern:

Deployment Type	CPU	RAM	Disk
Minimum (workstation/cell deployment)	1 CPU	2 GB RAM	20 GB disk¹
Recommended (centralized/site deployment)	2 CPU	4 GB RAM²	50 GB disk¹

¹ Required disk space is highly dependent on configured log level and utilization of Store and Forward.

² Deployments requiring more than 4 GB of RAM need to increase the V8 heap size using the NODE_OPTIONS environment variable. For assistance, contact Fuuz support.

Data Collection Scenarios

These scenarios assume data collection and monitoring use cases (read operations to 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.

Ultra Hybrid HMI Scenarios

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

[Illustration: Assembly line floor plan showing gateway placement at each cell with PLC connections and edge screen terminals]

Best Practice: For hybrid HMI solutions with bi-directional PLC communication, deploy one Fuuz Gateway per workstation/cell. This architecture provides multiple points of redundancy, high availability, and eliminates dependencies on internal network reliability for individual stations.