Anatomy of a NixOS config

This is my humble, first contribution to the community.

When learning about how to build my own nixos configuration I found it valuable to visualize the structure and thought that there may be others out there who would benefit from a visual learning tool.

I would love to hear any and all feedback about how this helps or hinders, where improvements or corrections could be made etcetera.

I’ve already noted some improvements myself but as the saying goes, perfect is the enemy of good enough.

Looking forward to the feedback and really hope that it is useful.


Nice writeup! Here’s the blog post.


Amazing write-up!! I’m sure it’ll help some of my friends that are struggling with linking and piecing out all together.


Well done! Having diagrams and illustrations to go with a video like you have done makes it more interesting and easier to follow. I find many videos that show quick typing difficult to follow.

1 Like

Thanks all for the kind comments. I’m happy to see that this approach is valuable, so will continue and improve it as I go.

1 Like

Really cool blog post! I was surprised to see that it’s very close to the setup I’m also using for my config (GitHub - futile/nixos-config: My NixOS configs for anyone that is interested).

Super cool! :slight_smile:


Do you ever encounter issues where you want to provide something like “wayland-desktop” via home-manager but not all derivations or configuration are available via home-manager?

I suppose either modules or a mixin style is the only way to resolve this?

Here’s an example of the mixin style:

1 Like

Good question. I haven’t encountered that yet but suspect it’s just a matter of time. As I understand it, lower-use options often aren’t directly available in home-manager so there is less maintenance overhead. They are often still accessible via extraArgs or extraConfig type options though.

The mixin concept is new to me so I had a look at your repo to get a better understanding. I would likely do a module but only due to personal preference for how the code would be organized. I’m curious what the pros and cons between them could be though.

Very interesting config by the way. You seem to have a lot of stuff going on there and a couple of different solutions from what I’ve come across so far. I’ll keep it in mind for reference down the road :slight_smile:

Thanks! I’ll have a look at your config. Always good to get new ideas and inspiration :slight_smile:

1 Like

Not actually my config, but it is very interesting. I’ve been trying to collect the different styles of flake configs I come across.

1 Like

@Gwyn and @Eriim may enjoy it.

@EmergentMind, Great content, thanks.

Some hints, questions:

Do you have any inspiration from Errim config?

You forgot to link your nix-config project.

Do you mind create a playlist with your nix specific content, so I can add to my docs mindmap?


Thank you for the feedback, much appreciated!

Do you have any inspiration from Errim config ?

Yes. I mention Eriim config/nix-flakes in the video introduction. I realize now however, that quite a few people are opting to read the blog rather than watch the video though, so I’ll update the blog accordingly today.

You forgot to link your nix-config project.

Likewise, with this. :wink:

Do you mind create a playlist with your nix specific content, so I can add to my docs mindmap ?

Definitely. I was going to wait until subsequent videos are released but since it will be useful now, here it is…

Nice work on that mindmap, great idea for keeping track of all the information out there.

Thanks again.

1 Like

Generelly really like how you do that, and also love the motto
“The way out, is through”

One passage, where I really cringed, is when you say:
“Why not naming it custom_packages” … “There are no other packages to be placed here, they are all custom”

Now, two things I had never understood in such an instance, both only apply in this specific case, when multiple people deal with a configuration, and some team members might be new to Nix (admittedly rare)

1.) Why would someone avoid to name something so that is more specific, and communicates its intend clearer? Its documentation at this point.

2.) Why would anyone sacrifice this benefit just so they can type a couple of characters less.
As programmers, or people who deal with Nix configurations, we spend 5% of our time typing.
Code is usually read 10 times more often than it is written.

I love this presentation, and I get that Nix configurations and generally desktop files are not that often shared across a team, but I just cringe every time I hear that argument - also for function names and had to write you this, since you insisted so friendly, to write you any feedback that we can come up with.

Love the series, and definitely sign up for the next episodes :slight_smile:


I had to laugh at myself when reading this because it made me remember making the same two points to someone else several years ago at a job regarding function names. Funny how things get forgotten or go unnoticed over time.

You’re correct on both points. I’ve already added an item to update my config accordingly in the future :smiley:

Glad you are enjoying it otherwise. Thanks for the great feedback!

1 Like

I’m new to nix(OS) and just got set up with this structure, so far it is working out great!

I’m wondering if you/anyone has any good advice on how to handle situations where most of the configuration of a package is shared by two hosts/users but there are differences. My problem is with hyprland and waybar, on my laptop I want some extra keybinds for media/brightness keys as well as a battery module in the waybar. I don’t want these on my desktop but it would be great if I was able to update a single file to change styling or to add some keybinds for both hosts.

At the moment I’m not configuring via home manager but instead using xdg.configFile for most things. I would be willing to change that if it helps the situation though.

Thanks :slight_smile: