Stylix: applying one color scheme across NixOS, Home Manager, nix-darwin and Nix-on-Droid

What Stylix solves, and who it is actually for

Theming a Linux desktop usually means editing the same color values in a dozen unrelated places. A terminal emulator reads one file, a GTK application reads another, the shell prompt has its own palette, and the wallpaper sits somewhere else entirely. Change your mind about the base color and you repeat the whole exercise. Stylix exists to collapse that work into one declaration. It is a theming framework for NixOS, Home Manager, nix-darwin and Nix-on-Droid that applies color schemes, wallpapers and fonts to a wide range of applications. The audience is therefore narrow and specific: people who already describe their system in Nix and want the theme to be part of that description. If your configuration lives in a flake or a set of Nix modules, Stylix is written for you. If you configure applications by editing files in your home directory, the project's central premise does not apply to you at all. The README draws the contrast with color scheme utilities such as base16.nix or nix-colors: those give you the palette, while Stylix goes further by applying themes to supported applications, which the README describes as following an "it just works" philosophy. That difference is the whole product. A palette generator that hands you sixteen hex values still leaves the wiring to you; Stylix is the wiring.

How the theming actually reaches your applications

The repository layout shows the shape of the mechanism. There is a modules/ directory, a generated/ directory, a palette-generator/ directory, a stylix/ directory, and a flake.nix at the top level. The palette-generator is where colors are derived from source material, most obviously the wallpaper, and generated/ holds output produced from that derivation rather than hand-written Nix. The modules/ directory is what ties the result to individual programs: each supported application needs a module that knows which options to set and which files to write. This is why the supported application list is the real measure of the project. The framework cannot theme something nobody has written a module for, and no amount of palette generation changes that. The README's own framing supports this reading, since it distinguishes Stylix from utilities that stop at the color scheme. The practical consequence is that Stylix is a collection of integrations with a shared color source, not a universal theming engine. When you enable it, the options you set feed the palette generator, the generated palette feeds each application module, and each module writes the configuration that program expects. Everything happens at build time through Nix, which is also why the result is reproducible: the same inputs produce the same theme, and a theme change is a rebuild rather than a manual edit. The README does not document any runtime daemon or live re-theming service, and nothing in the listed repository entries suggests one.

Trying Stylix without installing it: the testbed demo

The README's clearest entry point is not an installation procedure but a live demo. It gives this command for trying the dark GNOME 46 theme:

nix run github:nix-community/stylix#testbed:gnome:dark

Running it fetches the flake from GitHub and starts the testbed output named for GNOME and the dark variant. This is the fastest way to see what Stylix produces before touching your own configuration, and it requires only a working Nix installation with flakes enabled. What the README does not provide is a step-by-step installation section: there is no copy-pasteable snippet showing how to add Stylix as a flake input, no module import line, and no example of the options you would set to choose a wallpaper or a base color. The README points instead to the documentation site at nix-community.github.io/stylix, which is where those details live. That is a real gap in the README for anyone evaluating the project, because the demo proves the theme exists but says nothing about how much configuration your own setup will need. Practically, the evaluation path is: run the testbed command to judge the visual result, then read the documentation site for the flake input and module options, then decide whether the applications you care about are covered. Skipping the second step is how people end up with a theme that applies to half their desktop.

Where Stylix stops being the right tool

The README is direct about one limitation: KDE theming is still a work in progress, and some manual steps may be required to properly apply its theme. For a project whose stated philosophy is that things just work, that sentence matters. It means a KDE Plasma user cannot expect the same hands-off result as a GNOME user, and it means the framework's promise is unevenly distributed across desktops. The second limitation follows from the architecture rather than from any statement in the README. Because theming is delivered through per-application modules, anything without a module is simply not themed. There is no generic fallback that reads an application's config format and guesses where the colors go. If your daily tools are niche, you will either write the integration yourself or keep theming those tools by hand, at which point the single-source-of-truth benefit is partial. The third case is a mismatch of philosophy rather than capability. If you enjoy hand-tuning each application, or if your theme changes are exploratory rather than declarative, a rebuild-per-tweak workflow will feel like friction. Stylix assumes you want one coherent scheme applied consistently, and it is least useful to someone who wants seventeen slightly different ones.

Stylix against base16.nix and nix-colors

The README names the alternatives itself: base16.nix and nix-colors, both described as color scheme utilities. The distinction it draws is that Stylix applies themes to supported applications while those tools provide the scheme. That is a genuine difference in approach rather than a feature checklist. A color scheme utility gives you a set of named colors and leaves the question of what to do with them entirely open. You get maximum control and zero automation: every application you want themed needs its own glue, written by you, mapping the scheme's names onto that program's configuration format. Stylix inverts the trade. You accept its module set and its generated palette in exchange for not writing that glue. The cost of that inversion is coverage: with a scheme utility, any application is themeable in principle because you are the integrator; with Stylix, an application is themeable when someone has contributed a module. So the choice is not which project is better but which kind of work you would rather do. If you have a small, stable set of programs and want exact control over each one, the utility approach is more honest about what it requires. If you have a broad desktop and want the theme to propagate without per-application effort, Stylix is the one that removes the work. The README's "it just works" phrasing is a fair summary of that position, provided you stay inside the supported set.

Maintenance, licensing and what a Nix upgrade costs you

Stylix is licensed under the MIT licence, which is permissive and places few conditions on reuse or redistribution; the LICENSE file at the repository root carries the actual terms, and anyone embedding the modules in a product should read it rather than rely on the short identifier. The repository is not archived, and its last push was on 2026-09-26, two days before this writing, so the codebase is being touched. That says nothing about the pace of new application modules or about how quickly a desktop environment change is absorbed, and the README does not publish a support policy or a release cadence. The upgrade cost is structural rather than financial. Because Stylix is consumed as a Nix flake, moving to a newer revision means updating a flake input and rebuilding; the cost lands when an application module changes the options it sets, because your configuration may then need adjusting to match. The README does not document rollback, so anyone planning an upgrade should treat their Nix configuration history as the recovery path. The README also carries no release notes and no retrieved release list, so there is no changelog to consult before bumping the input. That absence is worth weighing: you are tracking a repository, not a versioned product with a migration guide.

Editorial conclusion

Adopt Stylix if your desktop is already described in Nix and you want one palette, wallpaper and font set to reach many applications without editing each one. Do not adopt it if you theme applications by hand, if you run a desktop outside the supported set, or if you need KDE Plasma theming to be complete: the README states that KDE theming is a work in progress and that some manual steps may be required. Before committing, check the documentation site for which applications are supported and confirm the module options your configuration needs exist; the README itself gives no install steps beyond the live demo command.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. nix-community/stylix on GitHub
4. Project website
5. README