# UIBUILDER gives Node-RED flows a web front end without requiring a framework > UIBUILDER is a Node-RED add-on for building data-driven web applications that talk to your flows, offering no-code and low-code nodes alongside editable full-code front-end templates. It runs on Node.js 18 and Node-RED 4, it is framework agnostic, and it ships Apache 2.0 licensed with a version line that has moved through seven major releases. **TotallyInformation/node-red-contrib-uibuilder** — Easily create data-driven web UI's for Node-RED. Single- & Multi-page. Multiple UI's. Work with existing web development workflows or mix and match with no-code/low-code features. - Repository: https://github.com/TotallyInformation/node-red-contrib-uibuilder - Website: https://totallyinformation.github.io/node-red-contrib-uibuilder/#/ - Stars: 529 · Forks: 92 - Language: JavaScript - License: Apache-2.0 - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/totallyinformation-node-red-contrib-uibuilder ## What it is: a Node-RED add-on that is a conduit to the browser UIBUILDER is a Node-RED add-on that makes it easy to build custom web UIs that talk to your flows. The README puts it as Easy data-driven web UI's. Batteries included! The capability list at the top of the README lays out four positions, and each one is a design commitment. No-code and low-code options driven from Node-RED. Dynamic data interchange between Node-RED and the browser. No front-end framework needed, but you can use any of them if you want to. And integration with existing web development workflows. The fourth of those is the one that distinguishes this from the many dashboard add-ons for Node-RED. Most dashboard projects assume you will not write front-end code, and give you a set of widgets with configuration dialogs. UIBUILDER explicitly supports the opposite end of the spectrum, and the README says it includes helper features that can reduce or eliminate the need to write code for building data-driven web applications, which is a deliberate mixture of both worlds rather than a choice between them. The Purpose section states the goals and they are worth quoting because they define the boundaries. UIBUILDER supports easy methods for creating and delivering data-driven web apps and web pages. It is to be a conduit between Node-RED and the front-end browser UI web apps. It is to be UI framework agnostic, with no framework needed but working with them where desired, and it aims to reduce the requirement for a framework by making it easier to work with vanilla HTML and CSS. It provides interface and data standards for exchanging data and controls between Node-RED and the web pages. The conduit framing is the key mechanism. The value is not that the tool renders your UI for you, it is that it defines the standard for how a flow pushes data to a page and how a page pushes control back, and lets you choose how much of the front end you want to own. The repository metadata describes it as easily create data-driven web UIs for Node-RED, single and multi-page, multiple UIs, work with existing web development workflows or mix and match with no-code and low-code features. The topics list includes websockets, web-components, low-code, no-code and zero-code, which is an unusually wide vocabulary for a single project and reflects exactly that mixture. ## Installation, and the Node and Node-RED baselines that decide your version UIBUILDER is best installed using Node-RED's Palette Manager, which is the standard path for any Node-RED add-on and requires no command line at all. The version requirements are stated precisely, and they are the first thing to check. UIBUILDER requires at least node.js v18 and Node-RED v4, and you should be using a current LTS version of node.js. To help develop UIBUILDER you need at least node.js v24 LTS and the latest release of Node-RED. The last sentence in that paragraph is a maintenance promise rather than a constraint, and it matters for planning: UIBUILDER will release a new major version when the baseline node.js and/or Node-RED versions are increased. So the add-on tracks the platform, and each platform bump costs you a major upgrade. Manual installation is documented as well, from a command line on the Node-RED server: ```bash cd ~/.node-red npm install node-red-contrib-uibuilder ``` And to install an older major version, you provide the major version number: ```bash cd ~/.node-red npm install node-red-contrib-uibuilder@v5 ``` Development branches install from GitHub, with branch names usually being future version numbers: ```bash cd ~/.node-red npm install totallyinformation/node-red-contrib-uibuilder#v7.1.0 ``` One operational detail follows the install instructions: you will need to restart Node-RED if installing manually. The Palette Manager handles that for you, and a manual install that does not restart leaves you with the old version loaded and no obvious error. So the decision tree is short. If you are on Node-RED 4 with Node 18 or later, install from the Palette Manager and take the current version. If you need an older major because your platform is pinned, install the specific major explicitly and read the changelog between it and the current release before you assume the features you want are present. ## The documentation, the walkthrough and the built-in examples The README is a pointer to a documentation site rather than a manual, and it says where everything is. For a super-quick start there is a Getting Started guide linked from the README, then a First-timers walkthrough on the documentation site and an Introduction Video on YouTube. The walkthrough is the one to read if you are new to the add-on, because the README's own framing is that the tool has a lot of ways in and a guided path through them saves an hour. There are also built-in example flows, accessible through the Node-RED Import menu, which means you can load a working configuration into your editor and look at it rather than building it from a screenshot. The examples directory in the repository shows what those flows cover. There is a Quick Start Flow.json, a Simple Flow.json, a Simple UI Updates.json and a Control UI from Node-RED.json at the top level, and then a set of directories: Low-code, No-code, Node Examples, Template Examples, Layout Examples, Client-side code, and a directory for 3rd-party Frameworks. That directory listing is the clearest statement of the project's scope. The No-code and Low-code directories correspond to the two ends of the spectrum the README describes, the Template Examples directory is the full-code route, Client-side code is for people writing their own front-end logic, and 3rd-party Frameworks is for people bringing their own framework. A new user can start from whichever of those matches how they intend to work, and that is a better position than a tool that assumes one way of building. The documentation site can also be accessed from within UIBUILDER nodes even without an Internet connection, which matters for an air-gapped or intermittently connected installation. For support, the README points at the Node-RED Forum, which has a dedicated UIBUILDER tag for questions, discussions, ideas, support, examples and FAQs, the GitHub issues log for raising issues, and a dedicated Discord channel. The forum tag first is the useful detail, because a large body of prior answers is already there and the maintainer is active in it. ## The repository structure shows a front end and a back end in one package The top level entries reveal how the project is organised, and they are more informative than a feature list would be. There is a src/ directory, a nodes/ directory, a front-end/ directory, a templates/ directory, and a packages/ directory. There are also resources/, examples/, docs/, tests/, bin/ and a gulpfile.js. The split between nodes/ and front-end/ is the important one. The nodes/ directory holds the Node-RED node implementations, that is the back-end side of the add-on, and front-end/ holds the browser side, including a node-blue.svg icon. The templates/ directory holds the front-end templates you edit, which is where the full-code route lives. The packages/ directory is a pnpm workspace, and the package.json confirms it with a workspaces array of packages/*. The scripts in the root package.json make the build structure explicit. There is a single build entry point, node bin/build.mjs, and then sub-targets for each artefact: build:fe, build:node, build:css, build:json-viewer, buildVersions for the version metadata, and buildDocBundle for the documentation bundle. There is a watch mode, build:watch, and the older gulp watch script is still present as old-watch. That single build script with named targets is a good sign about how the project is maintained, because it means the different artefacts are built by one tool rather than by a scattering of scripts that drift. The runtime dependencies are short: degit, express, jsdom and socket.io. express serves the static front-end and the API, socket.io carries the live data interchange, jsdom is the DOM implementation used for server-side rendering of the UI, and degit is the scaffolding tool that copies a template repository into a new project. The workspace scripts also reveal that the project has three separate editor workspaces, opened with code:main, code:client, code:markweb and code:core-docs, and a madge dependency graph script that renders the runtime dependencies of the nodes as an SVG. The markweb workspace implies a separate rendering mode, and the graph script is the kind of tool a maintainer uses to reason about the dependency structure of a package with this many moving parts. There is also a CI story worth noting. The README carries CodeQL analysis workflow and DeepScan badges alongside the usual build badge, which is a signal that the project runs independent static analysis rather than relying only on its own tests. ## Where UIBUILDER is the wrong choice The first limit is the coupling to Node-RED. Everything UIBUILDER does is mediated through flows, and if the logic driving your interface lives in a service rather than in Node-RED, the add-on becomes an awkward intermediary rather than the natural home for the application. There is no supported way to use UIBUILDER's data standards without Node-RED underneath them. The second limit is the version churn. A new major version ships whenever the Node.js or Node-RED baseline moves, and the release history shows that this happens: the version line has reached 7.x, with v5 being installable explicitly for older setups. For a production deployment, that means a Node-RED upgrade and an add-on upgrade are coupled, and the add-on's major version is the less predictable of the two. The third limit is that the no-code route and the code route are genuinely different products with different maintenance profiles, and the README does not say much about where the boundary between them lies. If you build your interface from the no-code nodes and then want one custom component, you have to understand enough of the template system to escape the node editor, and that transition is where projects like this tend to become expensive. The presence of a Client-side code and a 3rd-party Frameworks examples directory tells you both routes are supported, not how smoothly you move between them. The alternative to weigh is the other end of the spectrum. If you want a Node-RED flow to push data to a browser and you want complete control of the front end, you can skip the add-on and use socket.io directly from a Node-RED function node, serving your own pages. The difference in approach is that UIBUILDER gives you a data standard, a control vocabulary, node configurations for the common cases and a set of templates, so the difference is whether you want to design that contract yourself or use one that already exists. The other alternative is a dedicated dashboard add-on with a narrower scope, where you accept a fixed set of widgets and never write front-end code. That is less flexible and much less work. If your interface is a handful of gauges and switches over flow data, that is the smaller commitment, and UIBUILDER's flexibility is not the deciding factor. One more practical point. The add-on serves static assets and a websocket endpoint from the Node-RED process, so the deployment has to serve those routes. That is usually nothing, but it does mean UIBUILDER is not separable from the Node-RED runtime the way a separate front-end application would be. ## Maintenance, licence and the shape of the project The maintenance record is current. The last push was on 2026-10-20 and the repository is not archived, so the code is being actively worked on. The recent release history shows the kind of releases a mature add-on produces: v7.7.3 with bug fixes for Node-RED projects use, v7.7.2 with mostly bug fixes with a couple of feature tweaks, and v7.7.1 described as a bug fix only, forcing Markweb pages to dark mode. That last one is a useful detail. It says the add-on has a Markweb rendering mode in addition to the others, and that the maintainer treated a dark mode issue as worth a dedicated patch release. A project that ships patch releases for one-line fixes has an active issue tracker behind it. The licence is Apache-2.0, recorded in the repository listing with a LICENSE file at the root. Apache 2.0 is a permissive grant with an explicit patent clause and, unlike MIT, it carries an express patent grant and a patent retaliation clause. That matters slightly more for a project that ships as a Node-RED add-on inside commercial products, though in practice it is a low-friction licence. This is a licensing note rather than legal advice. The repository also carries the files a well-run open source project has. There is a CHANGELOG.md, a CODE_OF_CONDUCT.md, a CONTRIBUTING.md, a SECURITY.md and a PRIVACY.md, plus a CITATION.cff for academic citation and a TODO.md that keeps the roadmap in the repository rather than in an issue. The PRIVACY.md and SECURITY.md are worth a look before you deploy it, because UIBUILDER serves a web UI and therefore handles whatever your flows send it. The project publishes to npm as node-red-contrib-uibuilder and the README links the npm version and download badges, and it is also listed on the Node-RED Palette Manager, so installation does not require anyone to trust a tarball URL. The documentation lives on the project's own GitHub Pages site, which means the docs for a specific version are available offline from within the add-on itself, which is more than most Node-RED add-ons manage. ## Conclusion Adopt UIBUILDER if you run Node-RED and want to expose flow data through a browser without hand-rolling the websocket plumbing or committing to a front-end framework. Do not adopt it if your Node-RED is on version 3 or your Node.js is below 18, since the add-on requires Node-RED 4 and Node 18, and note that a major version is released whenever those baselines move. Verify first which front-end approach you want, since the no-code nodes and the editable template are different workflows with different maintenance costs, and that your deployment can serve the static assets the add-on expects. ## FAQ ### How do I install UIBUILDER for Node-RED? Use Node-RED's Palette Manager, which is the recommended path. A manual install runs cd ~/.node-red followed by npm install node-red-contrib-uibuilder, and you must restart Node-RED afterwards. To install an older major version, use npm install node-red-contrib-uibuilder@v5. ### What versions of Node.js and Node-RED does UIBUILDER require? At least node.js v18 and Node-RED v4, with a current LTS version of node.js recommended. Developing UIBUILDER needs node.js v24 LTS and the latest Node-RED release, and the README says a new major version is released when the baseline node.js or Node-RED versions increase. ### Do I need a front-end framework to use UIBUILDER? No. The README states UIBUILDER is UI framework agnostic, that no framework is needed, and that it aims to reduce the requirement for a framework by making it easier to work with vanilla HTML and CSS, while still working with frameworks where desired. The repository's examples include directories for No-code, Low-code, Template Examples, Client-side code and 3rd-party Frameworks. ### What licence is UIBUILDER released under and what are its runtime dependencies? Apache-2.0, with a LICENSE file at the repository root. The runtime dependencies are degit, express, jsdom and socket.io, and the package is published on npm as node-red-contrib-uibuilder at version 7.7.4, with the last push on 2026-10-20. ### Where can I find UIBUILDER examples and support? The repository's examples directory holds Quick Start Flow.json, Simple Flow.json, Simple UI Updates.json and directories for Low-code, No-code, Node Examples, Template Examples, Layout Examples, Client-side code and 3rd-party Frameworks, and the built-in flows can also be loaded through the Node-RED Import menu. Support is via the Node-RED Forum UIBUILDER tag, the GitHub issues log, a dedicated Discord channel and the documentation site at totallyinformation.github.io. ## Sources - [License: Apache-2.0](https://github.com/TotallyInformation/node-red-contrib-uibuilder/blob/main/LICENSE) - [Project website](https://totallyinformation.github.io/node-red-contrib-uibuilder/#/) - [README](https://github.com/TotallyInformation/node-red-contrib-uibuilder/blob/main/README.md) - [Releases](https://github.com/TotallyInformation/node-red-contrib-uibuilder/releases) - [TotallyInformation/node-red-contrib-uibuilder on GitHub](https://github.com/TotallyInformation/node-red-contrib-uibuilder) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/totallyinformation-node-red-contrib-uibuilder