Appliance

Overview

The appliance is one machine in the plant network that brings four things behind a single secured HTTPS address: the HMI, the project repository, the signal history and the CONNECT gateway. No internet, no cloud account, no external DNS. You install it once on a dedicated box, and from any panel PC, tablet or office workstation in the same network you reach all four under one hostname and one login.

Everything else in deployment options is a way of putting static files in front of a browser. The appliance is not that. It runs containers, it keeps a database, it holds a git repository, and it has to be operated — which is why the rest of this page is mostly about what it demands from you rather than what it gives you.

What sits behind the address

A single reverse proxy is the only ingress. One TLS configuration, one login, and for the browser everything is same-origin.

Address	What answers	Where it runs
`/`	The HMI — realvirtual WEB	Static files from the active release
`/appliance/`	Service dashboard, four status tiles	Static, no backend
`/connect/*`	realvirtual CONNECT gateway	Natively on the host, not in a container
`/git/*`	Forgejo — project repository and long-term archive	Container
`/influx/health`, `/influx/api/v2/*`	InfluxDB health and API	Container
`https://influx.<host>/`	The InfluxDB operating interface	Container, own subdomain

CONNECT stays outside the container boundary on purpose: it talks to the fieldbus, it uses UDP broadcast discovery, and on Windows it keeps its tray and its self-update. Putting it in a container would buy nothing and cost all three.

The InfluxDB interface needs its own subdomain

Every route above is same-origin except one. The InfluxDB 2 operating interface does not tolerate a subpath: it ships <base href="/"> and asks for its own bundle at the origin root, where the HMI answers with HTML instead. There is no base-path option in InfluxDB to fix this, and nothing in a health check reveals the failure — the interface simply stays blank.

It therefore lives on influx.<host>, a subdomain of its own. The health and API routes under /influx/ are unaffected and stay same-origin.

Two topologies

The installer is a set of scripts, not an .exe or an MSI — auditable, and the same Linux code path in both cases.

Windows with CONNECT native

The standard form: one Windows box. CONNECT runs natively on Windows, at the OT network, with its tray and its self-update. Everything else — proxy, repository, history — runs as Docker containers inside a WSL2 distribution. Docker Engine, not Docker Desktop, so no Docker licence question arises at your site.

Two scheduled tasks start the distribution and CONNECT at system start, so the appliance comes up after a power cut without anyone logging in.

Linux with systemd

The same picture without the WSL boundary. CONNECT runs as a hardened systemd unit on the same host, the containers run next to it, and the WSL-specific half — networking mode, Hyper-V firewall, a VM address that changes — does not exist.

Both topologies restrict the gateway port to the loopback address and the host’s own address. Never to the local subnet, never to any address.

Windows 11 22H2 or newer — there is no way around it

The appliance requires Windows 11 version 22H2 or newer, build 22621 or higher.

The reason is mirrored networking mode in WSL2. Without it there is no route at all from a container to the gateway on the host: in NAT mode the Hyper-V firewall blocks the path, and no Defender rule opens it. This was measured, not assumed. Windows 10 and older Windows 11 builds are out — use a different machine, or the Linux topology.

You can check in a normal PowerShell before you plan anything:

(Get-CimInstance Win32_OperatingSystem).BuildNumber       # must be >= 22621
(Get-CimInstance Win32_ComputerSystem).HypervisorPresent  # must be True

The installer refuses to run on a system that is not clean

The appliance installs on a dedicated machine. If the installer finds any of the following, it stops before it changes anything:

What it finds	Why it stops
An existing WSL distribution	Someone set that up deliberately. The appliance overwrites nothing.
Docker already present — including installed and stopped	Docker Desktop is the most likely find on a company machine. It brings its own WSL distributions and its own network configuration; someone starting it months later collides with the appliance, and nobody will see the connection.
An existing `.wslconfig`	Same rule — the file holds someone’s settings.
Hardware virtualization disabled	No WSL2 at all.
Ports 80, 443 or 5100 in use	The proxy and the gateway need them.

There is no switch that skips this check. That is deliberate: an appliance is a dedicated device, and a half-migrated one is worse than none.

A preflight run lists every finding at once and changes nothing, so you can check a candidate machine before you schedule the work.

The host address must be static

The host address is held in two independent places — in the container network configuration and in the firewall rule. A silent change takes the appliance down, and there is no reconciler that notices and repairs it.

The installer therefore refuses a DHCP-assigned address. Give the machine a static address, or pass a documented DHCP reservation as an explicit argument with the reference to your IT ticket.

What you need before you start

Windows

Windows 11 22H2 or newer (build 22621+), 64-bit
Hardware virtualization enabled in BIOS/UEFI
A machine with no WSL distribution, no Docker and no .wslconfig
A static IPv4 address, or a documented DHCP reservation
Ports 80, 443 and 5100 free
Administrator rights, and a reboot slot — enabling the Windows features requires one
Network access during installation: the WSL distribution, the Docker Engine and CONNECT are downloaded

Linux

64-bit Linux with root access
Docker Engine 24 or newer with Compose v2
At least 20 GB free disk space
openssl and a correct system clock
A static address, ports 80 and 443 free

In both cases

A built HMI release, as an archive, to seed the appliance with. Without it the stack starts and says so clearly, but / has nothing to serve. Importing a release keeps the previous one in place, so a rollback is a symlink switch.

Trusting the appliance — the root CA

The appliance serves HTTPS. By default it uses its own internal certificate authority, because there is no public DNS name and no internet, so a public certificate is not available.

HTTPS is not cosmetic here. As soon as the HMI is opened from any device other than the appliance host itself, plain HTTP is an insecure context and the viewer loses concrete functions: encrypted persistence and the password gate, the CAD and GLB cache digest, the copy buttons, and VR/AR. localhost counts as a secure origin, so a single-seat PC would work over HTTP — a panel PC or tablet in the plant network would not.

Three things to plan for per device:

Windows takes about two minutes and is scriptable by group policy.
Firefox keeps its own certificate store and does not use the Windows one.
iPadOS needs a second step after the profile is installed: Settings › General › About › Certificate Trust Settings. This is the single most common support case.

If your site has its own PKI, use it. Point the appliance at a certificate from your own authority and the endpoint effort drops to zero — the devices already trust it.

Access protection: one authenticated origin, no roles

Authentication happens at the reverse proxy, in front of everything. Every route is covered: the HMI, the dashboard, the repository, the history, the gateway, and the WebSocket upgrade. Without credentials you get 401 everywhere, and nothing reaches the services behind the proxy.

Two accounts exist. One is for people — its password is printed exactly once, at the end of the installation, and is stored nowhere. The other is a machine account used by the health check and the test scripts.

The origin credentials are never passed through to CONNECT. The proxy strips the authorization header and injects the gateway’s API key behind it, so the browser never sees the key.

Two more things worth knowing:

There is no login rate limiting. Basic authentication does not slow down guessing. The appliance sits in the plant network behind the firewall rule that restricts the gateway port — that is the whole of the protection against a determined attempt from inside the network.
Failed logins are indistinguishable. A wrong password and an unknown user produce the same response, byte for byte, and the response names none of the services behind the proxy.

There is no backup and no restore

This is the largest open gap, and the reason the appliance is not released.

The appliance keeps its state in three volumes: the project repository and long-term archive, the signal history, and the certificate authority. Nothing in the product backs them up, and nothing restores them. Uninstalling deliberately leaves them in place, which is what makes a reinstall harmless — and also what makes their loss final.

Until a backup path exists, treat the machine as disposable and take a snapshot at the virtualization layer before anything risky. Whatever you do, the volume that holds the certificate authority belongs in your own backup regime.