Your plant deserves better than a panel from 2009.
NEXT HMI replaces proprietary HMI/SCADA panels with one self-hosted server: your PLCs on OPC-UA in, live operator screens in any browser out, and the whole project as plain files your team can diff, review and version.
Every part of the project is a file you can read.
Author pages, wire datasources and define alarms in the browser. Every artifact lands as plain JSON or CSV on disk — which is why your change control already works on it, and why an AI agent can author against the same project the editor and the runtime read.
In-browser editor
A three-pane WYSIWYG editor with a live preview. Pages, datasources, alarms, translations and users — no engineering workstation, no dongle, no seat to licence.
Git-native projects
Pages, alarms, theme and translations are plain JSON/CSV on disk — no database, no binary blob. Your change control already works, and a project moves between installations as a folder or a single zip.
Custom widgets
Drop a .tsx into custom-widgets/ and it hot-compiles to a schema-driven widget — no Node toolchain, no rebuild of the core. Reuse your house widgets on every project.
Property sources
Composable property sources — $var, $if, $switch, $loc and 19 more — let any property react to live data. Nothing for your integrators to script, review or debug at 2 a.m.
AI-driven engineering
A built-in MCP server exposes 30+ read/write tools, so an agent can build the 40 near-identical screens a line needs — with dry-run diffs guarding every destructive change.
OPC-UA out of the box
An asyncua client pool subscribes, writes and browses your address space — viewport-aware, so the tags on screen update first however many the machine exposes.
Responsive design
One project branches layout by viewport class — panel PC, tablet, phone — through $viewport. The maintenance engineer's phone gets the same screens, not a second project to keep in step.
External JS libraries
Drop an ESM bundle into external-libraries/ and import it from any widget through a generated import map — charting, gauges, whatever the customer already standardised on.
No feature paywall
Historian, alarms with acknowledgement, recipes, users and permissions — all in one open-source build. No licence token, no locked features, nothing to quote per tag or per seat.
Rather see it than read it? The product tour walks one real project screen by screen — the operator runtime, the editor, the property panel, OPC-UA browse, recipes, and the manager that ships it to the panel.
One binding language. Zero scripting.
Every property has a type and a source. The source is either a literal or one of 23 composable sources, and they nest recursively: a colour that switches on a live tag, inside a label that resolves through a translation, inside a layout that branches by viewport. One idea, learned once, and it covers every property on every widget.
// colour the gauge from the live motor temperature "color": { "$if": { "cond": { "$compare": [ { "$var": "PLC1:motor1.temp" }, ">", 120 ] }, "then": "#e5484d", "else": "#2563eb" } }, "label": { "$loc": "MotorSpeed" }, "value": { "$var": "PLC1:motor1.speed" }
One server between your operators and your machines.
One box to install, one port to open, one thing to explain to the customer's IT department. Browsers connect over a single WebSocket; the FastAPI server holds the OPC-UA client pool and pushes live tag updates to every screen.
Browser runtime
Any device with a browser renders pages and custom widgets — nothing to install on the floor, nothing to re-license per panel.
FastAPI server
Serves pages, hosts the editor, holds the OPC-UA pool and streams tag updates to every screen. Project data is plain JSON/CSV on disk.
PLCs & machines
Subscribe, write and browse over OPC-UA through the asyncua client pool. Any controller that exposes an OPC-UA server, or sits behind a gateway that does.
What it needs.
Nothing here is a NEXT HMI product you have to buy. The screens are whatever already has a browser, the server is whatever already runs Docker or Python, and the machines are whatever already speaks OPC-UA. These are the floors for each.
| Role | Architecture | Minimum | Platforms |
|---|---|---|---|
| Server runtime, editor, OPC-UA pool |
x86-64 (Intel, AMD) or ARM 64-bit | 2 GB RAM, 2 cores | Windows x64, Linux, Apple-silicon macOS. Docker on linux/amd64 or linux/arm64, or from source on Python 3.11+. |
| Operator device the screens themselves |
Any | A modern browser | Panel PC, industrial monitor, tablet, phone. Screens run in the browser, so nothing is installed on the device and nothing is licensed per screen. |
Those RAM figures are measured, not estimated: on a reference install the manager holds about 11 MB resident and a running project about 44 MB — roughly 87 MB for the pair. 2 GB leaves headroom for the historian, several projects at once, and the operating system underneath.
Three ways in. Same project folder.
Ship a panel PC from a portable zip, deploy to the customer's server with Docker, or build on your laptop from source. Same runtime, same project — so what you tested in the office is what runs on the line.
Portable zip
A self-contained Windows or Apple-silicon Mac build for a panel PC. Unzip, double-click, live — nothing to install, nothing to activate. Unsigned today, so the OS asks once — the install guide has the one-time steps.
From Docker
One command brings up the server with the example project. Mount your own folder to deploy — the customer's IT department gets a container, not a Windows workstation.
From source
Clone the repo and run the dev server — hot reload for the runtime and for the widgets you are writing beside it.
Know when the next version ships.
You have the download. The other half is hearing when there is a new one — what changed, what is fixed, and what is worth upgrading a running panel for.
Free software, stated plainly.
AGPL-3.0-or-later on the whole repository — no dual-licensed core, no licence check in the build. Stated plainly here so you can clear it with your own policy, and your customer's, before you download anything.
LICENSE-EXCEPTION.md rather than left to interpretation.
Two things are sold alongside: a commercial licence at €100 per shipped unit, for machine builders who would rather not pass the source on with the machine, and a proprietary enterprise build for regulated plants, activated with a key, which is the only place the audit trail — the one paid feature — is available. Neither takes anything out of the open-source build; the audit-trail code was never in it, and there is no licence check in it either. Full licensing details →
Frequently asked questions.
What NEXT HMI is, how it connects to your machines, what happens at handover, and how it differs from traditional HMI/SCADA panels.
What is NEXT HMI?
NEXT HMI is a free, open-source, self-hosted HMI (Human-Machine Interface) and SCADA platform that runs entirely in the browser. It connects to PLCs over OPC-UA, streams live tag data to operator screens over a single WebSocket, and includes an in-browser editor for building dashboards without proprietary tooling.
How is NEXT HMI different from traditional HMI/SCADA software?
Traditional HMI panels require proprietary editors, per-device licences, and Windows-only runtimes. NEXT HMI runs in any browser, stores every project as plain JSON/CSV on disk (so it is Git-friendly and diffable), and uses a single composable expression language for every property instead of split tag/expression modes.
Is NEXT HMI free and open source?
Yes — AGPL-3.0-or-later, applied to the whole repository with no per-file carve-outs. You can self-host it with no per-seat licences, no vendor lock-in, and full access to the source on GitHub. The build contains no licence check of any kind. See the licence summary or the full licensing page.
Is any part of NEXT HMI not open source?
One feature: the audit trail — an append-only, attributed record of operator actions. It is the only paid feature, and it ships solely in the separate, proprietary enterprise build for plants that answer to a regulator, activated with a licence key. That build is an addition to the open-source one, not a piece carved out of it: no feature was removed to create it, and the free build has no licence check and no disabled audit code waiting for a key. Details on the licensing page.
How does NEXT HMI connect to PLCs?
NEXT HMI uses an asyncua OPC-UA client pool to subscribe to, write, and browse tags on your PLCs and field devices. A FastAPI server holds the connection pool and pushes live updates to every connected browser, with a viewport-aware fast/slow window so visible tags update first.
Which protocols does NEXT HMI support?
OPC-UA. NEXT HMI is an OPC-UA client over opc.tcp://: it discovers a server’s endpoints, takes the security policy and message-security mode from the endpoint you pick, signs in anonymously or with username and password, and subscribes, writes and browses through an asyncua client pool. Encrypted endpoints use a per-project client certificate. A static datasource lets you build and test a whole project with no PLC connected. Native MQTT is on the roadmap as the second transport.
Can an AI agent build HMI pages in NEXT HMI?
Yes. NEXT HMI ships with a built-in Model Context Protocol (MCP) server that exposes more than 30 read/write tools. An AI agent can author pages, datasources, and alarms directly, with dry-run diffs guarding every destructive change.
How do I install and run NEXT HMI?
You can run it three ways from the same project folder: from a self-contained portable zip on a panel PC — unzip and double-click, nothing to install — from Docker with docker compose up on a server, or from source with hot reload during development.
Build your first HMI page in minutes.
Clone the repo, open the editor, drop a widget on a page and bind it to a live OPC-UA tag. Evaluate it on a real machine this afternoon — there is no trial to request and no quote to wait for.