Architecture & Deployment

This page explains how IOTA VUE is put together and the ways it can be deployed. For the step-by-step setup sequence, see Getting Started as an Admin.

IOTA VUE Architecture

IOTA VUE consists of two main components:

• IOTA VUE — the web application that serves dashboards and displays to users via a browser. It handles display configuration, view management, user sessions, and the engineering environment.
• IOTA Drivers — data connectors that retrieve information from external systems (historians, databases, cloud platforms) and make it available to VUE. Each driver is specific to a data source.

The diagram below shows how these pieces fit together — drivers pull from on-premises and cloud sources, publish over the NATS message bus to the IOTA VUE backend, which stores configuration in PostgreSQL and serves displays to the browser. Users sign in through your identity provider.

Deployment Options

IOTA VUE can be deployed in three ways:

• SaaS (cloud-hosted) — IOTA manages the VUE application and cloud-hosted drivers. Customers connect their data sources and start building.
• On-premise — VUE and drivers are deployed within the customer's own infrastructure, giving full control over networking, security, and data residency. This can be a single host or VM for evaluation, managed Kubernetes, or a private cloud.
• Hybrid — cloud-hosted VUE with on-premise drivers that reach into plant networks. On-premise drivers are placed by network zone — typically DMZ, Business, or PCN (process-control network).

Because drivers connect outbound only, they can sit wherever the data lives regardless of where VUE runs — which is what makes the hybrid model possible.

QA and Production Environments

Most customers run separate QA and Production environments so displays and configuration can be validated before they reach operators. Two topologies are supported:

• Two separate instances (recommended) — a dedicated QA instance and a dedicated Production instance, each with its own set of drivers. This gives full isolation: you can test drivers, data, and display changes in QA without any risk to Production.
• Shared back end — a separate QA front end that reuses Production's IOTA database and drivers (the same API). This needs less infrastructure to deploy, but because QA and Production share the same data and configuration, testing is limited — you cannot validate driver or data changes in isolation.

With two separate instances, the IOTA team can copy displays on demand between Production and QA (in either direction), so you can promote validated work to Production or pull Production displays into QA for testing.

Warning

For copied displays to bind to data correctly, the driver topics must match between the QA and Production instances. If the topics differ, the copied displays will still load, but their data bindings will need to be reconfigured for the target environment.

What's Next

With the architecture and deployment model in mind, continue to Getting Started as an Admin for the step-by-step setup sequence.

Related

• Getting Started as an Admin — the step-by-step setup sequence
• Administration Page — manage users, drivers, and features
• Data Sources — connect IOTA to your data systems