LumexUI is a Tailwind-built Blazor component library that has stopped being maintained

The announcement that changes everything about this project

The first thing in the README is an IMPORTANT callout, and it is the most important thing to know about LumexUI.

LumexUI is no longer actively maintained. The repository is archived and will receive no further updates or bug fixes. The final release, v2.4.0, remains available on NuGet, and the code is MIT-licensed if you would like to fork it.

That is stated plainly and up front, which is the right way to handle it. A component library is the kind of dependency that people adopt quickly and then find in their dependency tree years later, and the maintenance status is the single most important fact for anyone reading the repository today.

The announcement is linked from the README, on the discussions page, and it is worth reading before making a decision, because the difference between adopting a dead dependency and forking a well-designed codebase is entirely in whether you read it.

The version history supports the account. The listed releases are v2.4.0 from 2026-06-21, v2.3.6 from 2026-05-09 and v2.3.5 from 2026-03-30. The final release is v2.4.0, and the repository itself was last pushed to on 2026-10-12.

So the practical reading is: the code is frozen, the NuGet package is available, and if you need changes you make them yourself.

What the library was

LumexUI was an open-source UI component library that offered a set of Blazor UI components, all fully built with Tailwind CSS.

The design goal is stated in two clauses. The components are designed to be not only aesthetically pleasing, but also highly customizable, allowing you to tailor them to meet your specific needs.

That combination, a fixed design plus deep customisability, is what separates this from a stock Blazor component set. Blazor ships its own visual language, and swapping it for another one means either accepting that look or fighting the framework's own styling. Building the components on Tailwind CSS means the utility classes are the styling mechanism rather than a wrapper around them, so a project that already uses Tailwind gets a consistent pipeline for its whole interface, and the design tokens live in one Tailwind configuration.

The topics on the repository are blazor, blazor-components, components, library, tailwindcss and ui, and the primary language is C#. The homepage is lumexui.org, and the README points there for full documentation.

For community, the README suggests GitHub Discussions for anything that would benefit from being searchable, which is a reasonable distinction from the Discord server it also links for chat. The searchable channel is where the usage patterns end up, which matters more for a component library than for most projects, because the components are meant to be composed.

The repository layout and the documentation site build

The top level of the repository is a conventional .NET solution with the documentation site built alongside the library.

There is LumexUI.sln as the solution file, src/ for the library source, tests/ for the test projects, docs/ for the documentation application, and scripts/ for the build tooling. There is a Dockerfile at the root, a CODE_OF_CONDUCT.md, a LICENSE file, an .editorconfig, a logo.png and a .github/ directory.

The Dockerfile shows how the documentation is built and published, and it is a two-stage build that produces a static site rather than a running server.

# -----------------------------
# Stage 1: build/publish
# -----------------------------
FROM mcr.microsoft.com/dotnet/sdk:9.0 AS build

# Install Node.js v22 (LTS current)
RUN apt-get update && apt-get install -y curl \
    && curl -fsSL https://deb.nodesource.com/setup_22.x | bash - \
    && apt-get install -y nodejs \
    && apt-get clean && rm -rf /var/lib/apt/lists/*

WORKDIR /src

COPY . .
RUN dotnet publish ./docs/LumexUI.Docs -c Release -o app
RUN node ./scripts/export-static.mjs app/LumexUI.Docs.dll /static

The first stage uses the .NET 9 SDK image, installs Node.js 22 alongside it, publishes the LumexUI.Docs project, and then runs a Node script that exports the result to a static directory.

# -----------------------------
# Stage 2: static site
# -----------------------------
FROM alpine:3
COPY --from=build /static /static

The final image is Alpine with only the static files in it, which is about as small as a documentation site gets. The Node.js dependency exists for the export step, not for the output.

That the docs are a Blazor application exported to static HTML rather than a server-rendered site is a deliberate choice. It means the documentation can be hosted as static files anywhere, and it means the component library dogfoods itself, since the documentation site is itself built from the components it documents.

Getting the components, now that it is a snapshot

The README does not contain an install command, and the reason is that the project is no longer the kind of thing you set up from a README.

The final release, v2.4.0, remains available on NuGet, and the documentation site at lumexui.org holds the full documentation. Those are the two routes, and they are the routes for a library that has stopped changing: add the package to your project at that version, or read the docs for how the components were meant to be used.

If you need to change anything, the third route is the fork. The code is MIT-licensed if you would like to fork it, and for a component library that is the practical path, because a UI library usually needs a tweak the moment you adopt it, whether it is a token change, a new component or a fix for your framework version.

The MIT licence matters for that decision. There is no copyleft obligation and no requirement to publish your product's source, so a fork can be internal to your organisation, and if you contribute changes back to a fork of your own, nobody is obliged to accept them.

The remaining community channels still exist. Contributions were always welcome, subject to the code of conduct, and the Discord server and GitHub Discussions are where questions about best practice went. With the project archived, treat both as read-only archives rather than as places to expect an answer.

Where LumexUI is the wrong choice

Three cases argue against it.

The first is a new Blazor project that wants a maintained dependency. A component library is not a small thing to take on. Every component you use becomes code you own in the sense that you will need it patched for a framework upgrade, and here there is no upstream to send the patch to. For a new project, a component library with an active maintainer is the safer dependency, whatever its visual style.

The second is if you are on a current .NET and Blazor version. The final release predates the archive, so it predates whatever has changed in the framework since, and Blazor components are tightly coupled to the rendering model. The Dockerfile shows the docs being built against the .NET 9 SDK, which is the most recent evidence of the framework version the components were current with.

The third is if you need the ecosystem around it. A component library's real value is partly in its documentation, its examples, its peer components and the fact that other developers are using the same ones. An archived library loses all of that, and a team that adopts it will end up with components nobody else uses and no one to ask.

The alternative in the same direction is one of the actively maintained Blazor component sets, with a design language that differs from LumexUI's Tailwind approach. The difference in approach is that those libraries are built around a framework-native styling system, which means you take their look more or less as given, while LumexUI's components let you keep a Tailwind-based design system and adjust the pieces. That flexibility was the reason to choose it, and it remains the reason to fork it rather than to look elsewhere, since a fork of a Tailwind-built Blazor component set is a smaller and more predictable job than restyling an entire component library to match your design tokens.

Editorial conclusion

LumexUI fits a Blazor team that liked the component design and is prepared to take ownership, because the code is MIT licensed and the final release remains on NuGet. It does not fit a team that wants a maintained dependency, since the project announces no further updates or bug fixes and points at forking. Download v2.4.0 from NuGet, or fork the repository and take the components as a starting point, and read the announcement linked from the README before you decide, because it is the document that changes how you should use this library.

Frequently asked questions

Official sources

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