OUI: a Vue 3 and Lua framework for building OpenWrt web interfaces

What OUI is, and the layer it sits at

OUI is described as a framework used to develop a web interface for OpenWrt, and the repository description spells out the stack, lighttpd plus Lua-eco plus Vue3 plus Vite plus Element Plus. So the pieces are a web server on the router, a Lua back end for APIs, and a modern JavaScript front end built with Vue 3 and the Element Plus component library. The OpenWrt Web interface link points at the LuCI documentation, and the modularisation note says the project is organised as with Luci, so the reference point is the official OpenWrt web interface and the convention it established. The primary language is recorded as JavaScript, the licence is MIT, and the last push to the repository was on 2026-10-13 with the repository not archived and no GitHub releases, which fits a framework that is consumed as source through the OpenWrt build system rather than as a versioned package.

The five features, and the one that changes the deployment model

The feature list is short. Separation of front-end and backend, so the two halves are developed and reasoned about independently. Developing back-end APIs using lua-eco. Developing front-end pages using Vue 3 with Element Plus and Vite. Support for multi-user and ACL management, providing fine-grained permission management. And modularisation as with Luci, where each page is individually packaged as an IPK. The last point is the one that determines whether OUI is a fit. Luci packages each page separately so that an install can include only the pages a device needs, and OUI adopts the same model. That keeps the flash footprint of a router image down, and it means your interface is a set of OpenWrt packages rather than one blob, which is the right shape for the platform and the wrong shape if you just wanted a single settings page.

Why Lua on the back end at all

The back end choice is inherited from the platform rather than a preference. OpenWrt is a Linux distribution for routers with a small embedded footprint, and its native application language is Lua, which is what LuCI uses to serve the pages and the actions behind them. The author maintains lua-eco as a separate project, and OUI uses it to develop the back-end APIs, so the two are coupled and you are adopting both. The topics list carries lua and lede alongside ui, vue and web. For an evaluator the important question is whether the Lua layer is a thin bridge to the uci configuration and system binaries, which is where OpenWrt keeps its state, or whether it reimplements something, because the answer determines how much of the platform you can still reach from your own pages.

The repository layout, which is an OpenWrt build system

The top level of the repository is arranged like an OpenWrt package tree rather than like a JavaScript project, and that is the clearest signal of how it fits. There is a node.mk file, which is the OpenWrt build include used to pull npm packages into an OpenWrt package build, and an oui.mk and a version.mk, the standard make fragments for a package version and its dependencies. The two core directories are named oui-ui-core for the front end and oui-rpc-core for the back end, and the applications/ directory holds the individual pages that get packaged. There is also a ubuntu/ directory with its own README for the quick start, a docs/ directory, an img/ directory, and a .github/ directory for the workflows. There is no package.json at the top level and no node_modules, because the JavaScript toolchain is invoked from within the OpenWrt package build.

Developing away from the router, which is the practical workflow

The documentation links a pair of Ubuntu quick start pages, one in English and one in Chinese, and the existence of the English one next to the Chinese main documentation is itself a small detail worth noting. The reason such a guide exists is structural. Building a Vue application with Vite inside an OpenWrt SDK environment is slow and awkward, because the SDK is built for the target architecture and the front end build wants a desktop Node. A desktop quick start lets you develop the pages, run the back end locally and iterate quickly, and only then package the result as an IPK for the router. The framework's own approach, a per page IPK, means the front end build has to run for each page, and a fast local loop is what makes that tolerable. The project also documents itself bilingually, with the English documentation at the root and the Chinese under a /zh/ path.

Multi-user and ACL, and where that sits in the OpenWrt model

The multi-user and ACL support is the feature that most distinguishes OUI from a static page generator for LuCI. OpenWrt's own web interface has historically been a single administrative user, and a router firmware that wants to offer a read-only view to a guest, or a reseller portal, or per-device permissions, needs an identity and permission model, not just an authentication check. The README describes fine-grained permission management, and the framework is designed to carry it. For an evaluator the question is how the ACLs map onto the system's own model, since OpenWrt already has rpcd, a daemon that exposes a JSON-RPC interface to the system's state, and an interface that duplicates the permission model rather than using it will drift from the platform's behaviour. The project documentation at the linked OpenWrt web interface page is where that mapping would be described.

Where the project stands and what to expect from it

The honest reading of the repository is that this is an active framework from a single author rather than a product with a team behind it, and that shapes how you should evaluate it. There are no GitHub releases, so consumption is through the OpenWrt build system with node.mk and the version fragment, and the last push was on 2026-10-13, so the work is current. The project asks for stars rather than contributors, and the README links a donation page. What you get in exchange is a documented division of labour, a front end stack that matches what web developers already use, a back end that speaks the platform's own language, and a packaging model that respects a router's flash budget. What you take on is supporting the front end build inside the SDK, and maintaining both OUI and lua-eco.

Editorial conclusion

OUI suits an OpenWrt vendor or a router enthusiast who wants to build a real administrative interface rather than patch the stock LuCI pages, and who is willing to maintain a front end build inside a small embedded environment. It is the wrong choice if you need to write a single page for a stock firmware, since the framework assumes a build pipeline and a package per page, and a poor fit if your team does not want to run a Vite build inside OpenWrt's constrained toolchain. Before adopting it, read the Ubuntu quick start, which exists precisely so you can develop the interface on a desktop rather than on the router, and note that the back end depends on a separate lua-eco project by the same author, so you are adopting two things at once.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. zhaojh329/oui on GitHub