Gateway Deployment & Architecture

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:

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

Supported Edge Connectors

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:

¹ 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):

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:

[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.