# Flux: the official Livewire component library

> Flux is a hand-built UI component library for Livewire applications, styled with Tailwind CSS and distributed as a Composer package. The free tier ships five components and the rest sit behind a paid licence, and the way it plugs into a Laravel layout is a single pair of Blade directives plus one stylesheet import.

**livewire/flux** — The official Livewire UI component library

- Repository: https://github.com/livewire/flux
- Website: https://fluxui.dev
- Stars: 979 · Forks: 111
- Language: Blade
- License: not declared
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/livewire-flux

## Five free components, and a paid tier for the rest

The component list is short, and the readme is clear about why.

The free package, the livewire/flux Composer package, includes Button, Dropdown, Icon, Separator and Tooltip. The rest of the Flux components are part of the paid Pro tier, and a Pro licence key is purchased on the pricing page on the project site.

That is a split worth thinking about before you evaluate the project. The five free components are the primitives almost every interface needs, and they are the ones where a component library either gets the behaviour right or does not. A button that handles loading states, a dropdown that handles keyboard navigation and focus, a tooltip that positions itself inside the viewport: these are the components where hand rolling costs more than it looks.

The components that sit behind the paywall are, by implication, the more specialised ones, the modals, the comboboxes, the date pickers, the command palettes, the kind of component that is expensive to build and easy to get subtly wrong.

The library is described as hand-crafted rather than generated, which is the claim you would expect for a component library that sells access to its source, and the components can be viewed in action on the project site, which is the fastest way to judge the visual language before you install anything.

The primary language of the repository is Blade, which tells you the components are Blade templates rather than a JavaScript component library, and that is the right shape for Livewire, where the server renders and the browser enhances.

## The version floors are explicit

The prerequisites section lists three floors, and they are worth reading before anything else.

Flux requires Laravel 10.0 or later, Livewire 3.5.19 or later, and Tailwind CSS 4.0 or later.

Each of those numbers is a decision about who the library is for. The Laravel floor of 10 is old enough to include a large installed base, so it is not being aggressive about dropping support. The Livewire floor of 3.5.19 is more specific, and it points at a particular patch of the Livewire 3 line, which suggests the library depends on behaviour that was fixed or introduced in that release.

The Tailwind v4 floor is the one that will decide things for many teams. Tailwind v4 changed how a project is configured, with the CSS-first configuration and the new import syntax, and a component library written for v4 is not going to work with a v3 project without changes.

The practical advice is to check all three numbers against your application before you plan the work, because the fix for any mismatch is a framework upgrade rather than a library tweak.

## Two Blade directives and one stylesheet import

The installation is short, and the shape of it is the interesting part.

You add the package with Composer:

```bash
composer require livewire/flux
```

Then you add two Blade directives to your layout file, one in the head and one in the body:

```html
<head>
    ...
    @fluxAppearance
</head>

<body>
    ...
    @fluxScripts
</body>
```

One directive renders the appearance, which is the CSS the components need, and the other renders the scripts. The split is what you would expect from any component library, and the fact that it is expressed as two directives rather than one asset tag means you control where each lands in the document.

Then Tailwind has to be told about the library's stylesheet, because Tailwind only generates the classes it can see. The readme gives the exact contents for the app stylesheet:

```css
@import 'tailwindcss';
@import '../../vendor/livewire/flux/dist/flux.css';

@custom-variant dark (&:where(.dark, .dark *));
```

The first import pulls in Tailwind itself, the second imports the compiled stylesheet that the Composer package installed into the vendor directory, and the third declares the dark variant against a class rather than the media query, which is how the components switch to their dark palette when the application puts a class on the root element.

That third line is the piece to understand. That line replaces Tailwind's default media-query dark variant with a class-based one, and the components follow it, so dark styling applies when the application puts the class on the root element.

## Typography is a recommendation, and it loads from a third party

The font setup is marked optional, and the way it is done is worth a note.

The recommendation is the Inter typeface, and the snippet loads it from a font mirror rather than from a self-hosted file or from a build step:

```html
<head>
    ...
    <link rel="preconnect" href="https://fonts.bunny.net">
    <link href="https://fonts.bunny.net/css?family=inter:400,500,600&display=swap" rel="stylesheet" />
</head>
```

The preconnect line is the performance detail, because it opens the connection to the font host before the browser discovers the stylesheet, which avoids a round trip in the critical path.

The stylesheet is then configured in the app CSS through a theme block:

```css
@theme {
    --font-sans: Inter, sans-serif;
}
```

In Tailwind v4 the theme block is where design tokens are declared, so this is how the font family becomes the default sans serif across the application rather than being applied to one component.

The dependency on an external font host is the trade-off. It is a privacy and availability question, since every page view makes a request to a third party, and a privacy question for a European audience in particular. If you would rather serve the font yourself, download the typeface, drop it into your public directory and point the theme block at your own copy; nothing in Flux depends on the mirror being there.

The recommendation is worth following on the design side. A component library that picks its own typeface and you override with a different one is a source of visual inconsistency, and the components are the kind that render text inside buttons, tabs and inputs where the difference shows.

## Activation and publishing are the two artisan commands

Two Artisan commands cover everything that happens after the install, and both are simple.

If you have bought a Pro licence, you activate it with:

```bash
php artisan flux:activate
```

During activation you are prompted for your email address and the licence key. The command therefore needs a terminal and a human, which is the normal pattern for a licence-gated package.

The second command is the more useful one for everyone, including those on the free tier:

```bash
php artisan flux:publish
```

It publishes the Blade files for the components, and you are prompted to select which ones to publish, or you can pass the all flag to publish everything.

Publishing is the escape hatch, and it is the feature that decides how much you can bend the library to fit your project. Once a component's Blade file is in your own repository, it is yours to edit, and the readme frames the purpose as customizing specific Flux components. The components are Blade templates rather than compiled assets, so what you publish is readable, editable markup with the Livewire behaviour attached.

The cost of that is the usual one. A published component stops receiving upstream fixes, so if a Flux release fixes a bug in the dropdown's keyboard handling, your published copy keeps the bug. The sensible policy is to publish only the components you have genuinely changed, and to leave the rest to the package.

For keeping up to date, the readme suggests updating the dependencies regularly, and the command it gives names both packages, the free one and the Pro one, so a single update covers the whole set.

## A small package with a fast release cadence

The repository layout is compact, and it reflects what the package is.

There is a src directory with the PHP side, a dist directory with the compiled stylesheet that the Tailwind import points at, a stubs directory, which is the conventional Composer term for the files that get copied into an application when you publish, and a composer.json. There is no test directory and no build configuration at the root, which suggests the build happens elsewhere and the repository publishes the artefacts.

The release history shows a project shipping steadily on a 2.20 line, with v2.19.0 on 2026-09-07, v2.20.0 on 2026-09-15 and v2.20.1 on 2026-09-29, and the last push was on 2026-10-15. A minor version every week or two is a normal pace for a component library, because each new component is a minor feature and each fix is a patch.

The licence is the one loose end in the metadata, since the repository does not state one, and the readme does not mention a licence either. The package is a commercial product with a free tier and a paid tier, so the licensing terms for the free components are presumably in the terms of the Pro purchase or on the site, and the readme does not spell them out. Before you ship a product built on the free components, find those terms and read them, particularly if you intend to use the components in a product that competes with a Flux Pro licence.

The documentation lives on the project site under the docs path, separate from this repository, and the readme points there for detailed guides.

## Conclusion

Flux suits a Laravel team that has already committed to Livewire and Tailwind v4 and wants a coherent set of components rather than assembling them from blog posts, and the five free components are enough to judge the fit before you buy anything. It is a poor fit if your project is on an older Laravel, Livewire or Tailwind, since the version floors are explicit, and it is a poor fit if you need a component library you can read in full, because the source of the interesting components is not in the package you install. Before you commit, install the free tier, publish the button component and compare it with your own design system, and read the Pro pricing page to see which components you would actually be paying for.

## FAQ

### How do I install the Flux component library?

Run composer require livewire/flux from your project root, add the @fluxAppearance and @fluxScripts Blade directives to your layout, and import the compiled stylesheet in your app CSS alongside the Tailwind import. The package requires Laravel 10 or later, Livewire 3.5.19 or later and Tailwind CSS 4.0 or later.

### Which Flux components are free?

The free package includes Button, Dropdown, Icon, Separator and Tooltip. The remaining components are part of the paid Pro tier, and a Pro licence key is bought on the project site and activated with php artisan flux:activate, which prompts for your email address and the key.

### How do I customize a Flux component?

Publish the Blade files with php artisan flux:publish, then select which components to publish, or use the all flag to publish everything. Because the components are Blade templates, what you publish is editable markup in your own repository, at the cost of no longer receiving upstream fixes for that component.

### How does Flux handle dark mode?

Through a Tailwind v4 custom variant rather than a media query. The app stylesheet needs a custom-variant dark declaration scoped to a class and its descendants, so the components switch to their dark palette when the application puts the class on the root element.

## Sources

- [Issues](https://github.com/livewire/flux/issues)
- [livewire/flux on GitHub](https://github.com/livewire/flux)
- [Project website](https://fluxui.dev)
- [README](https://github.com/livewire/flux/blob/main/README.md)
- [Releases](https://github.com/livewire/flux/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/livewire-flux