NixOS configuration

Credits

• https://nixos-and-flakes.thiscute.world (the cornerstone of my journey)
• https://den.denful.dev (framework which helped me grasp and maximize config potential)
• https://den.denful.dev/tutorials/default (base)
• https://github.com/AniviaFlome/nix-config (fish and zen-browser)
• https://github.com/zerokqx/ZNix (some nixvim plugins)
• and redditors over at r/NixOS for ideas and answers to my questions

Table of contents

• Design
• Goals
• Included
• Screenshots
  • Noctalia
  • Dank Material Shell
• Binary cache
• Cloning repo
• Making a config
• Build steps
• Secure boot setup
• Development
  • Just commands
  • Pulling remote changes
• Tips
• Licence and word of warning

Design

Project Overview

• Framework: denful/den — built with SoC in mind.

File Organization

• Manageable size:
  • Aim for ~ 80 lines per file.
  • Split into composable parts when a file gets out of control or mentally heavy.

Aspect Inclusion

• Primary focus: importing aspects.
• Fine‑grained control: optional manual overrides or schema options for advanced users.

Documentation

• Includes tips & tricks gathered from real‑world usage.
• Intended to help fellow Nix users starting with the framework (myself included), with room for future improvements.

Leveraging Den Capabilities

• Choosing the best tool for each task after thoughtful consideration.

Specific Practices

• Declare flake-file inputs, custom classes, etc., as close to the point of use as possible.
• This makes removal or refactoring straightforward.

Other specifics can be figured out by comparing individual files.

Goals

• TUI experience
• Keyboard-driven
• Uniformness with gruvbox theme
• Light gaming , I use it primarily for VNs

Included

Functionality	Software
Terminal	kitty
File Editor	neovim(native and nixvim)
File Manager	yazi / thunar
Window Manager	niri
Quickshell	noctalia, with dms as another option
Browser	zen-browser
Document Viewer	zathura
Input Method	fcitx5
Wallpaper Manager	awww
Shell	fish
Display Manager	ly
Boot Loader	limine, for setup check README
Memory layout	btrfs (unencrypted) via disko + impermanence

and some secondary options.

Screenshots

Noctalia

Logo is from https://gitlab.com/ntgn/ascii-art: LICENCE.

Dank Material Shell

All screenshots can be found here.
Wallpapers can be found here.

Binary cache

Build artifacts are cached and stored via cachix at cache.
Public key is available there:

amanako.cachix.org-1:sYWzosQAXLkVVLsWjl/36EJy5UqYHyvs5ztnKX2mmmY=

Relevant workflow file can be found here.

It is using omnix to create a om.json file with all flake outputs, which is then consumed by cachix-push tool and pushed to cache. This way outputs are also pinned and easier to maintain.
To avoid duplication and reduce cache size, store paths already present at upstream caches are avoided.

Cloning repo

Clone and enter the repo with either of the following commands:

# For enabled flakes and nix-command
nix run nixpkgs#git -- clone https://codeberg.org/abyssal-twilight/nix-config.git && cd nix-config

# For other users (after running installation flakes are used by default so this is temporary workaround)
nix-shell -p git --run "git clone https://codeberg.org/abyssal-twilight/nix-config.git" && cd nix-config

No matter the choice, option repoRoot should be set for either host or user, where user preference may override hosts choice making both of them eligible.
See Making a config.

Making a config

Since then uses import-tree as long as folders aren't prefixed with _, they will be included by default.
That means it all boils down to individual preference. Therefore following will be my current preference which is subject to change. I accept corrections if I am mistaken somewhere or same can be achieved in an easier to understand fashion.

Users can be created by making an entry in users directory, whereas host are made by adding an entry under hosts folder.
Following instruction apply equally to both of them, with difference which is explained below.

Duties are split among 2 folders: entry and aspect(optional), where:

• entry is made for den's definition and options which is tasked with actually creating host/user. Where applicable it should be prioritized over aspect.
• aspect is reserved for potential overrides for each of classes(including custom ones).
  

Notable difference is that one user can be declared across multiple host and even have different den options per host. This explains the structure of attribute set:

{
  den.hosts.${architecture}.${hostname}.users.${username} = {
    ...
  };
}

For such users I would suggest making multiple files within entry folder with this pattern for example: ${user}-${host}.nix.
Furthermore, all files can be broken into easy-to-follow pieces which is displayed in the examples.
My current user and host are provided as a starting point. Please reference users and hosts.

There are some necessary options like user.repoRoot taking host.repoRoot as fallback value, which is supposed to represent directory of cloned repo, and should be set upfront. Other than that some other options which are a must likely have an assertion forcing repo users to make a declaration.

For hosts using disko configuration packages are exposed when using disko.devices host schema option with the following format: ${host}-disko, and can be easily run with:

# Run script to format disks of all declared devices on host
just disko

If this is not the case, manual partitioning is required, I can recommend taking a look at this video.

When using impermanence: to persist configuration add directory containing configuration to persys class in host or user aspect, either with:

persistUser.directories = [
  # Example path - made at $HOME/nix-config
  "nix-config"
  # It can be some upper path for example:
  "Documents"
  # and then copied as a subfolder
];

or

persistSystem.directories = [
  # Typical nixos configuration path
  "/etc/nixos"
;]

Build steps

After completing previous section:

1. Run nixos-install and follow instructions:

nixos-install --flake $REPO_DIR

2. And then copy configuration over to desired (or persisted) folder.

cp -r $CONFIG_DIRECTORY $PATH_TO_FOLDER

3. Reboot

reboot

After completing setup running:

# Configuration activates after reboot
just rb

will build host using nh.

Secure boot setup

After rebuilding, extra steps are needed to enable secure boot.

For limine:

• Boot to firmware and clear keys via restart to setup mode or similar.
• Run:

# Create keys in /var/lib/sbctl
sudo sbctl create-keys
# Enroll keys with --microsoft flag recommended
sudo sbctl enroll-keys --microsoft --firmware-builtin
# Sign limine boot entry to be able to boot to it
sudo sbctl sign /boot/efi/limine/BOOTX64.EFI
# Reboot
reboot

If anything fails try the following:

• Secure boot failures in BIOS: Apply previously mentioned setup mode in bios. Retry.
• Keys don't get recognized: Temporarily remove wantsSecureBootSupport host option, run sbctl reset, rebuild and remove /var/lib/sbctl(for non-ephemeral users). Reboot and retry.

Development

nix-direnv is automatically enabled for all users. To begin with development you are advised to use direnv allow . in repo root. This enables automatic loading of environment and all packages each time you cd into directory, all while caching results for great responsiveness. If that doesn't fit you(possibility of running arbitrary dangerous commands) simply run nix develop to enter shell with all dependencies.

Just commands

All supported just commands can be displayed by running just. This is the recommended way of interacting with repo since it's simple and focused. Descriptions are provided.

  just
just --list
Available recipes:
    disko                    # Run disko configuration for current host [alias: d]
    fcheck                   # Check configuration of flake.nix from repo root [alias: fc]
    fupdate *inputs          # Update one or more flake inputs, all when no inputs specified [alias: fu]
    fwrite                   # Update flake inputs using "write-flake" app of flake-file [alias: fw]
    help                     # Display all recipes [alias: h]
    pull-flake branch="main" # Pull in changes from remote [alias: pf]
    rebuild-boot             # Rebuild config with nh and make it the default boot entry, activated after reboot [alias: rb]
    rebuild-switch           # Rebuild and activate config with nh and make it the default boot entry [alias: rs]
    repl                     # Enter nix repl with flake.nix from repo root [alias: r]
    vm                       # Spin up a virtual machine for current host

Pulling remote changes

In case of remote updates, run just pull-flake to grab latest flake.nix and flake.lock files. Works if no changes were made to local flake files. Otherwise manual intervention with git rebase is required.

Tips

Following are some of tips from personal experience(pending update and subject to change):

• If faced with choice, prefer using home manager as a NixOS module over standalone homes.
  Den allows declaring den.homes to achieve functionality for standalone home but I have deliberately omitted using it in configuration for convenience of rebuilding.

• Be sure to refer to upstream documentation whenever met with difficulties.

• Use nix-repl when not sure why something doesn't work as intended. For den-specific stuff, reference [den's debug guide][den's debug quide].

Licence and word of warning

Repository is licenced under MIT.
Even though it's just a bunch of config files, I mainly did this to evade law suits or similar and protect rights.
In general, to avoid unpleasant situations(deletion of partitions, emergency modes, kernel panics... all situations I have been through) you are highly advised to actually read through the code and understand it's purpose. For the most part I haven't documented it, but when I have some time to spare I will make advancements in that aspect.
Having a backup of important data is absolutely recommended.
Den seems to be a niche spot in already niche Nix environment, so most of the time following their github repo updates and conversations will aid you best.
Assets from third-party repositories(primarily flake-inputs, den included) are licenced under their respective licences.