FUXA: a web-based SCADA and HMI editor you run in a browser

The gap FUXA fills between a PLC and a browser tab

Traditional SCADA suites are licensed per tag, installed on Windows engineering stations, and edited through a desktop IDE. FUXA takes the opposite position: the engineering editor is a web page, the runtime is a Node.js process, and the whole thing is MIT licensed. The target user is an automation or IoT engineer who wants a process visualization running on a Raspberry Pi, a small Linux server, or a laptop, without buying a seat licence. The README describes it as a "web-based SCADA / HMI platform for industrial automation, IoT and real-time process visualization", and the repository topics confirm the intended surface: angular, bacnet, dashboard, hmi, iot, modbus, mqtt, nodejs, opc-ua, plc, s7, scada, siemens, svg-editor, web-editor, web-hmi, web-scada. That list is the honest scope statement. FUXA is aimed at people who already know what a tag is and want a drawing surface plus a protocol stack, not at someone looking for a turnkey MES.

How the editor, the server and the protocol drivers fit together

The architecture is split cleanly in two. The frontend is Angular with HTML5, CSS and SVG, and it is the part you actually look at: a visual editor for dashboards and process visualization where the drawing primitives are SVG. The backend is Node.js, and it owns the protocol drivers and the data historian. The README lists the supported protocols as Modbus RTU/TCP, Siemens S7, OPC-UA, BACnet IP, MQTT, Ethernet/IP (Allen Bradley), ODBC, ADSclient, Gpio (Raspberry), WebCam, MELSEC and Redis. The built-in historian, called DAQ in the documentation, writes to SQLite, InfluxDB or other time-series databases, with ODBC and Redis available as external integrations. The practical consequence of this split is that a protocol driver is a Node.js native module loaded by the server process. That is why the Dockerfile has a separate builder stage that compiles sqlite3 from source, and why node-snap7 and odbc are optional. If a driver fails to build, the editor still loads; you simply have no data behind your widgets. The repository also contains a node-red/ directory and an odbc/ directory at top level, which tells you the project treats external integration as a first-class concern rather than an afterthought.

Installing FUXA with Docker and opening the editor

The fastest path in the README is Docker. The image is published as frangoteam/fuxa:latest and the container listens on port 1881.

docker pull frangoteam/fuxa:latest
docker run -d -p 1881:1881 frangoteam/fuxa:latest

After that, the README says to open a browser (Chrome is suggested) and navigate to http://localhost:1881. With the command above you get a working editor, but every project file lives inside the container. The README gives a second form that mounts four volumes so the project, the historian database, the logs and the images survive a container replacement:

docker run -d -p 1881:1881 \
  -v fuxa_appdata:/usr/src/app/FUXA/server/_appdata \
  -v fuxa_db:/usr/src/app/FUXA/server/_db \
  -v fuxa_logs:/usr/src/app/FUXA/server/_logs \
  -v fuxa_images:/usr/src/app/FUXA/server/_images \
  frangoteam/fuxa:latest

If you prefer a compose file, the repository ships compose.yml, which uses bind mounts instead of named volumes and places the data in ./appdata, ./db, ./logs and ./images next to the file:

services:
  fuxa:
    image: frangoteam/fuxa:latest
    restart: unless-stopped
    volumes:
      - './appdata:/usr/src/app/FUXA/server/_appdata'
      - './db:/usr/src/app/FUXA/server/_db'
      - './logs:/usr/src/app/FUXA/server/_logs'
      - './images:/usr/src/app/FUXA/server/_images'
    ports:
      - '1881:1881'

The README fetches it with wget and starts it with docker compose up -d. Installing from source follows the same port: unpack a release, then cd ./server, npm install, npm start. The README recommends Node.js 18 LTS and notes that Node.js 14 and older stopped being supported from FUXA 1.2.7. There is also an npm route, npm install -g --unsafe-perm @frangoteam/fuxa followed by the fuxa command, and a @frangoteam/fuxa-min package for installations that do not need Siemens S7.

Native modules are the part that breaks

The README is unusually candid here, and it is worth taking at face value. It warns that on Linux systems, especially Raspberry Pi, installing native dependencies with Node.js 18 may require additional build tools, and it suggests removing entries from server/package.json: node-snap7 if you do not need Siemens S7 communication, and odbc if you do not need external database connectivity. The npm section repeats the warning, calling installation on Linux with Node.js 18 "a challenge", and points at @frangoteam/fuxa-min as the workaround. The Dockerfile makes the same trade explicit with build arguments: NODE_SNAP defaults to false and INSTALL_ODBC defaults to true, and the Snap7 module is only installed when NODE_SNAP is set to true. The runner stage installs unixodbc, odbc-mariadb, odbc-postgresql, libsqliteodbc and tdsodbc when INSTALL_ODBC is true. So the default image ships with ODBC and without S7. If you are connecting to a Siemens PLC, you are on a non-default path, and the README does not document a rollback if the node-snap7 build fails. That is a real limitation: a tool whose headline protocol list includes Siemens S7 makes that protocol the optional one in its own container build.

Where FUXA is the wrong tool

FUXA is a visualization and connectivity layer, not a safety system and not a certified control platform. Nothing in the README claims redundancy, deterministic scan cycles, or certification for any industrial safety standard, and the security posture is left to SECURITY.md rather than the main document. If your deployment requires a validated historian with audit trails, or a vendor who will answer the phone at 3 a.m., this is the wrong choice. The same applies if your plant is built on a proprietary protocol that is not in the supported list; the README enumerates what it talks to, and anything outside that list is your problem to bridge. There is also a maintenance consideration to weigh honestly. The last push to the default branch was on 2026-09-17, and the most recent release listed is v1.3.4 on 2026-08-12, with v1.3.3 in June and v1.3.2 in May. That is a steady cadence, but it is a small-team cadence. You are adopting a codebase you may need to patch yourself.

FUXA against Node-RED dashboards and Grafana

The obvious comparison for a lightweight setup is Node-RED with its dashboard nodes, and the repository itself contains a node-red/ directory, so the two are not strangers. The difference is the drawing model. Node-RED dashboards are assembled from a fixed library of widgets wired together in a flow editor; FUXA gives you an SVG editor where you draw the process yourself, which is the difference between a form and a mimic diagram. Grafana is the other frequent alternative, and it is better at time-series analysis over the DAQ data FUXA writes to InfluxDB or SQLite, but Grafana has no native Modbus or S7 driver and no SVG process editor. The honest split is that FUXA replaces the HMI drawing tool, while Grafana replaces the trend viewer. Teams that need both often run FUXA for the operator screen and point a time-series database at the same historian data.

Licence and the cost of staying current

FUXA is MIT licensed, which is permissive and places few obligations on how you redistribute or embed it. The repository carries a LICENSE file and the README shows the MIT badge. One caveat that is easy to miss: the Dockerfile installs unixodbc, odbc-mariadb, odbc-postgresql, libsqliteodbc and tdsodbc in the runner stage. Those are separate pieces of software with their own licences, and the MIT licence on FUXA does not cover them. If you redistribute a container built with INSTALL_ODBC=true, check what those drivers require. This is not legal advice; read the licences yourself. On upgrade cost, the version history shows a release roughly every one to two months, and the Node.js 18 LTS requirement is the constraint that will force action first, since the README ties support to that runtime. Upgrading means rebuilding the native modules, which is the same step that is fragile on first install.

Editorial conclusion

Adopt FUXA if you need a browser-based HMI editor and your plant already speaks Modbus, OPC-UA or MQTT, and you are willing to keep the Node.js 18 runtime current. Skip it if you need a vendor support contract, certified redundancy, or if your Linux target cannot build native modules. Before committing, verify three things yourself: that your protocol driver actually loads on the target hardware, that the _appdata, _db, _logs and _images volumes are mounted so a container restart does not erase your project, and that your licence obligations around the bundled ODBC drivers are acceptable.

Frequently asked questions

Official sources

1. frangoteam/FUXA on GitHub
2. License: MIT
3. Project website
4. README
5. Releases