Why is there no "installer" for NixOS?

Why is there no installer that allow you to configure HDD setup and generate an initial configuration file? Is it something that goes against the philosophy of NixOS, or because no-one got around to making one yet? Is it something that will make people upset if I write one?


I think there are many people in the community who would welcome a good graphical or TUI installer. Here are some links to relevant efforts you might want to look into, either for inspiration or to try to push them forward by getting involved in them. I’ve tried to order them by how recently they’ve been active as well as how relevant they are. Probably all of them are worth at least a glance:


Awesome, I will look at those and see if I can be useful.


I’m always skeptical as to what a graphical or guided installer is supposed to achieve. Maybe it allows inexperienced users to perform the partitioning but in the next step they will inevitably be confronted with writing expressions in an exotic functional programming language that isn’t used anywhere else. In my opinion it only shifts the point of resignation to later in the installation procedure.


Both can be learned, I think an inexperienced user adventurous enough to try NixOS would welcome being confronted with the functional language that they were told they would use, while being annoyed at the stateful setup that comes before.

Honestly you can get away with understanding very litlle nix for a long time, doubly so if your graphical installer sets up GNOME and a browser for you.

People that I introduced were often more intimidated by the complexity of partitioning, especially for encrypted setups.


If you do that, I would suggest creating a separate partition for /nix by default, perhaps even defaulting to llvm. Lots of newbies end up confused why everything breaks after they haven’t collected garbage for a month or two :slight_smile:

to be honest, i think a graphical installer could make things more difficult for someone new to the nix ecosystem, just look at the attemps to do something similar with archlinux for example, what i think could be beneficial its to improve documentation, and making easy to read guides like the gentoo AMD64 handbook, for someone new to gentoo in this case the handbook is really helpfull to the point where they explain how to access the boot menu in your computer (which honestly you should’nt install gentoo is you don’t know what is :laughing: ) And offering you the defaults options you may take for an optimal install, that’s something every “advance distro” should take in mind when writing their own documentation

Despite being one of those people who lives half his computing life in tmux and the other half in Emacs, partitioning tools is one of those applications where I still prefer a GUI (even over relatively nice TUI tools, like cgdisk or neat little REPLs like parted). I usually just use the graphical install disk for NixOS and install the KDE Partition Manager app on it, then do the rest of the install. :slight_smile:

When I’ve tried to imagine what a useful guided installer for NixOS might look like, I’ve always pictured basically a pre-configured editor that

  • integrates with documentation (especially the NixOS module search, but also the package search and the manuals) so that you can easily look up terms in your configuration.nix in the complete documentation
  • features basic accommodations like syntax highlighting and autocompletion
  • includes a few templates
  • integrates with nixos-hardware to let you choose an existing profile for your hardware, if one exists
  • has a reset button in case you produce some syntax or other error you don’t understand
  • maybe even has a GUI for enabling some options so that you can watch how enabling and disabling options actually happens in the configuration.nix file in real time as you click
  • gives a little bit of advice about how to navigate the documentation, (for example: check NixOS options before NixOS packages; an option that enables a package will generally integrate things better for you than just dropping a package in environment.systemPackages) before dropping the whole config file in front of the user

Because the Nix language is so simple and because NixOS is so forgiving thanks to its rollback functionality, new users can get a well-configured basic system long before doing a deep dive into the language. Then they can start really thinking about Nix as a programming language as their use case becomes more advanced, or they want to make their configuration more concise or orderly or whatever. I think a guided installer could be useful for letting people who are willing to learn but need to be sold on the language and the tooling experience what the benefits are right away.

I also think that this

overlooks the experiences of some Nix users, including some who are active in the community here on Discourse and who have put a lot of work into Nixpkgs. @aanderse and @Sandro, for example, have both described themselves as having little prior experience with functional programming. But both got into Nix and learned what they now know of the language because they were able to first try Nix and see what it can do, and that motivated them to take up the language as needed to accomplish their goals. A guided installer can help give more users a sense of what Nix can do and what they stand to gain before asking them to take up the task of deeply learning the Nix language.


It’s absolutely better to have users who feel empowered to investigate what they don’t know and to explore the documentation on their own than it is to have users who feel lost every time they need to attempt something new. And I agree that some efforts downstream of Arch Linux do a bad job of doing what Arch has historically done best, which is to empower users in that way by educating them through an up-front configuration process. But retaining a high barrier to entry is a clumsy way to try to ensure that a community is full of empowered, capable users.

In my opinion, an effective guided installer for us would make configuring NixOS more inviting by enriching (rather than hiding) the experiences of editing configuration.nix and navigating the NixOS documentation. An approach like that could simultaneously lower the barrier to entry and help to actively create empowered users rather than just passively selecting for them.

NixOS is a radically forgiving Linux distribution when it comes to experimentation, and the declarative style of Nix means that each running NIxOS system has a single point of entry that, if traced faithfully, will tell the entire story of how that NixOS system is configured, in every little detail. Distros like ours are in a uniquely favorable position to foster mastery not only through up-front study (like Gentoo, or Arch with the traditional installation procedure) but also through the gradual exploration of an already working system.

In my opinion, the question to ask about a guided installer is not

Is it possible or desirable to make NIxOS usable without learning the system?

but rather

How can a guided installer and other tooling better invite users to learn and master NixOS in a wider range of ways and at a wider range of paces?


I’d love to see a declaritive initial system setup, including things like setting up LUKS, partitioning, determining swap size or if you need a swap partition, boot type and loader. Ideally this plus a configuration.nix could get to a full system including the generation of the hardware-configuration.nix as the output of executoin the declared system setup.

Probably certain things like setting the LUKS passphrase would need prompting, but generally execution should attempt to be hands off.

Maybe it could even be part of a flake, where you provide this installer a git repo url and a hostname and it takes care of the rest.

If something like that existed, it would be relatively easy to make a UI, graphical or otherwise to guide people through the creation of that file. This could provide information and guidance on things like swap size and under which conditions it’s needed.

For more advanced folks who might be setting up lots of VMs in cloud infrastucture, or maybe IT departments configuring a fleet of laptops (might happen one day), then it would be a good way automate a lot of repetitive things.

For the record this is kind of a synthesis of ideas I’ve seen around here (couldn’t find the original topics to give credit), maybe it’s sort of what you have in mind @wmarais.

1 Like

I think this was the goal with nixpart (linked above and again here for convenience). @aszlig do you have any words of advice about the state of that effort or what you think it might take to complete a similar one?

You can use NixOS as your daily driver without having to write expressions in an exotic functional programming language that isn’t used anywhere else. You only need to do that to add a new package to nixpkgs or override an existing one, but since nix repo is one of the largest and most up-to-date, it’s not often you need to do that.

And configuration.nix is mostly just a big JSON file, it’s easy to add packages and other config options to it without writing any actual programs or scripts.


I like graphical installers because they save me time, compared to checking partitioning commands, and because I think (I wonder whether I could be wrong) that I’m much less likely to accidentally format the wrong partition and lose data if I have a graphical representation of my disks. So I’d love a graphical installer for NixOS even if all it did was partitioning and generating a minimal config and putting me into an editor.


Yes, there absolutely needs to be support for graphical configuration management after the installation as well.

do you have any words of advice about the state of that effort or what you think it might take to complete a similar one?

The current state of that effort is pretty much stalled since I’m currently busy with entirely unrelated things and I highly doubt that I’ll get back to it soonish. That said, it does bother me that we only have a heavily monkey-patched version of nixpart for the NixOps Hetzner backend and not what I had in mind as a more generic solution.

If you want to work on a similar implementation, be sure to look at the device tree representation that we’ve worked out back then:

Here is the implementation: nixpkgs/nixos/modules/tasks/storage at 0a18f5953217308f94ea777130bf2efa0f748d29 · NixOS/nixpkgs · GitHub

What’s essentially missing is the actual partitioner that takes the storage configuration and applies the delta between the device tree of the current system and the device tree of that configuration.

1 Like

I created nixos-up for precisely this purpose: GitHub - samuela/nixos-up: The fastest NixOS install there is! 🏎️🏁. It’s a TUI you can run directly from the installer ISO and it takes care of everything to get you into a working NixOS install as quickly as possible!


Thanks gang. A lot of really good information here.

@hmenke, My main concern is about partition tables and filesystem configurations. The installer is great once you have a suitable configuration.nix file. However, there will be things that will be unique between deployments, I.e. name and configuration of network interfaces, time zone, user accounts, language and the type of environment. I would expect having good and secure default templates for servers, desktops, laptops, gaming, etc configuration will also make it more accessible to more people. (Perhaps use a Union function to more than one role can be configured.) One of the things I teach my team is that a component of good software are good defaults. I think this a way to provide that.

@Carlos, you are right, bad defaults will always ruin your day, but I think more days has been ruined because of brave amateurs making mistakes such as having insecure configurations. Ideally by providing good defaults, we can can get assumptions evaluated by the larger community and hopefully pick up on badness. I expect that the expert users will still do their thing their way and that’s fine, but we should also look out for the less experienced users in our community.

@wkral really like the idea of a declarative initial system setup. My thought is that the installer should be able to generate this configuration file for you.

@pxc, thanks for the bullet point whish list. Some great ideas there. I’ve been wondering about how to integrate things like the option and package search into the installer.

@pxc, @aszlig, @samuela Thanks for all the links, I have been casually reading through them. If you guys like to exchange notes, I’ve been putting together my own lazy man’s installer at: GitHub - wmarais/nixos-installer: A simple script to install NixOs.

What you can see from the scripts, I have three HDD configurations all running on LVM.

  1. No Encryption - Generally for VMs running either in data centres with high physical security, or VMs on encrypted PCs etc.
  2. Partial Encryption (Root Only) - Encrypt the root and swap partitions, but leave /boot unencrypted. (faster booting than full encryption).
  3. Full Encryption - Everything is encrypted and you need to enter the password twice, first to unlock for grub boot, then for linux boot.

One of the big issues I had found was that the hardware-configuration.nix file refer to device by UUID which is not super useful for a generic file system configuration. One of the things I’ve been doing is to run on gpt only and name the partitions. Then I can refer to them by part-label. That way I can deploy the exact configuration on every VM that my team deploys. This would be an example of a default I would recommend be changed to make a more portable deployment. This is shown in the example: nixos-installer/gen_fs_conf.sh at 265ae3029db4a3c89d2da9ec13bdef52b9149440 · wmarais/nixos-installer · GitHub

It also generate a default filesystem layout and a default configuration for a few things. (Still missing the bash, vim, git, etc configurations.) My idea would be to extend this with a UI and pull in the good ideas and existing work from the community where it exist.

Thanks all.


Do it! Don’t listen to the gatekeepers! There are lots of barriers to entry to NixOS, and a graphical installer both removes one of those barriers for a large group of worthy people, as well as makes life nicer for another large group of people. At with removing any barrier, it will accelerate the removal of other barriers.

If some of you think that doing some other than building a graphical installer is more valuable, then by god, get to it. No need to discourage other people while you’re doing your own part.


Pretty new to NixOS myself, but started working on some modules for calamares that generate a configuration based on some presets. See: GitHub - vlinkz/calamares-nixos-extensions: Examples of Calamares branding. I also made a pr to fix the currently broken calamares modules. So far also have only tested basic installs with efi and ext4 filesystem, but results seem promising. Does anyone have any suggestions on what a default configuration file should look like? So far I just modified the default gnome configuration with a few extras: calamares-nixos-extensions/main.py at ef141de81bb4238dbb52ab0c91a4e3d4d7edfcaf · vlinkz/calamares-nixos-extensions · GitHub


@vlinkz Looks terrific to me, except maybe use pipewire these days, e.g.:

hardware.pulseaudio.enable = false; 
security.rtkit.enable = true; # for pipewire

services.pipewire = {
            enable = true;
            alsa.enable = true;
            alsa.support32Bit = true;
            pulse.enable = true;
            config.pipewire = {
                "context.properties" = {
                    "default.clock.rate" = 44100;