Where the Viewer Comes From

Overview

CONNECT serves signals. The 3D HMI that shows them can reach the operator in three ways, and the gateway works the same in all of them — what differs is who hosts the viewer and which features that viewer has.

Where the viewer comes from	What you install	Typical use
Bundled in the gateway	Nothing beyond the executable	Machine PC, service laptop, isolated network
Hosted — your web server, a CDN, or web.realvirtual.io	The gateway only	One viewer for many machines, updated centrally
Project-specific delivery	An executable with your project embedded	A machine handed to a customer with its own model, documentation and branding

The bundled viewer

The published CONNECT download carries realvirtual WEB inside the executable and serves it on the same port. Open http://localhost:5100 and the viewer is there — no web server, no Node.js, no build step, and no internet connection required.

What you get is the open-source viewer — the AGPL-3.0 core, whose source is on GitHub. That covers the 3D viewer, the HMI overlay with alarms, KPIs and machine information, hierarchy and model browsing, the standalone simulation of drives, transport and sensors, real-time material flow, and the CONNECT panel with live signals.

It shows the “Powered by realvirtual WEB” attribution, and that is part of the licence — an attribution requirement under AGPL §7, not a styling default. Removing or hiding it ends the licence to use the software; a commercial licence is the only way to deliver without it.

Using the free viewer for your own delivery has a price, and it is not money. AGPL requires the complete corresponding source of what you deliver — in our reading including plugins, settings.json and the delivered GLB models with their rv_extras metadata. If your machine geometry or configuration has to stay confidential, that is the point at which a commercial licence becomes necessary. The full position is on licensing the viewer.

The modules on top of it are not part of it. The Layout Planner, DES and the Editor are commercial features: you can try them in the public demo, but their source is not published and they are not in a self-hosted deployment — and therefore not in the viewer that ships with the gateway. Live inverse kinematics and the virtual PLC are likewise absent from a self-hosted open-source deployment; they run on the hosted service or as code in a commercial delivery.

Caution

The public demo at web.realvirtual.io/demo is a hosted instance and shows more than the bundled viewer does. Use it to evaluate features, not as a picture of what the free download contains.

A gateway can also be built without the viewer — an API-only build that speaks REST and WebSocket and serves no HMI at all. That is the right shape when the viewer is hosted elsewhere and the gateway is only a data source.

A hosted viewer with a local gateway

The viewer does not have to come from the gateway. A realvirtual WEB deployment on your own web server, on a CDN, or the public demo can talk to a CONNECT running on the operator’s machine. The browser loads the application from the web and the machine data from the local network — the machine data never travels to the host.

A viewer with no reachable gateway shows the CONNECT panel in its disconnected state — and that panel is also the download channel. It offers the current CONNECT build directly, so the way from viewing a model in the browser to live PLC data is one download and one Connect click, without leaving the page.

On the operator’s own PC this needs no configuration at all. The page reaches http://localhost:5100 directly, and browsers permit that even from an https:// page, because the local address is treated as trustworthy. That is exactly how the public demo connects to a gateway on the same machine.

Two things change once the gateway is not on the same machine as the browser:

1. The browser addresses the gateway by name or IP instead of localhost, so the access rule applies: set an ApiKey and introduce the browser once with http://<host>:5100/?apikey=<key>.
2. The page and the gateway are then different origins. Restrict AllowedOrigins to the host your viewer is served from instead of leaving it open.

For anything beyond the local network, put a reverse proxy with TLS in front of the gateway — see remote access and security.

A project-specific delivery

A gateway can be built with a complete project inside the executable: the model, the machine documentation, the branding, the interface configuration, and — where the project uses it — a prepared documentation index for AI diagnosis. The customer runs one file and has the finished HMI, with no hosting and no setup.

Two consequences worth knowing:

• Such a build has no self-update. Replacing the program file would replace the embedded project with the generic one, so these installations are updated by installing a new build — see updates.
• It does not fetch product news from the portal. A build with an embedded project has that outbound path switched off entirely.

Which one to choose

• One machine, one operator, no infrastructure — the bundled viewer. Nothing to host, nothing to maintain.
• Many machines, one HMI — host the viewer once, run a gateway per machine. Updating the HMI is then one deployment rather than one per machine.
• A machine you hand over — a project-specific delivery, so the recipient gets a single file that works offline and stays what it was on the day it shipped.

See also

• Installation — download and first start
• First connection — model, interface, signals
• Remote access and security — API key, origins, reverse proxy
• Deployment options — hosting the viewer itself