thein3rovert - Posts & Notes

From 20 Minutes to 1 Minute: Optimizing NixOS Builds

Sun, 15 Mar 2026 00:00:00 GMT

I wrote about building a self-hosted Terraform CI pipeline. The main aim of that is to deploy my terraform infrastuture changes automatically on push to default branch, which works pretty well..saves me alot of time. However the main aim for me wasn't just. What I really wanted was to fix the painfully slow feedback loop in my NixOS builds. Using the default github runner provided by github the ubuntu_latest my build time takes over Twenty minutes per build and seeing that i am building more than one host, the time taken per host were just not right. Today I'm running the same builds in under a minute.

GitHub's Hosted Runners

My NixOS configurations were building on GitHub's hosted runners and taking forever. Not just slow, but "go make coffee and hope it finishes" slow. Each build would take around 20 minutes, sometimes stretching past 27 minutes depending on what GitHub decided to give me that day. When you're iterating on infrastructure changes, waiting half an hour to discover a typo means you've lost your flow state twice over.

However, here is the reason, the slowness came from a few places. The fact that the GitHub's runners start fresh every time, so there's no persistent Nix store between builds. Every derivation gets built or downloaded from scratch per build and runs. Then there's the network overhead of pulling from Cachix over the public internet. And finally, the runners themselves aren't particularly fast machines.

I already had the self-hosted runner set up as per my previous blog, it is the same runner i use for my Terraform deployment, sitting on my Proxmox cluster with direct access to my local network. It was time to put it to work on the real problem.

Moving NixOS Builds to Self-Hosted

The existing runner was already configured with most of what I needed: GitHub Actions, Tailscale for network access, all my host run within my tailnet, this helps to improve security hardening as we all know self hosted runner are not overly secure when we run them with public repo and basic tooling. My nest step was NIX itself..since i dont want it to be downloaded during run time each time. I installed it using the Determinate Systems installer, which is what i'd recommend for anyone and it also when is been used widly in workflows:

curl --proto '=https' --tlsv1.2 -sSf -L https://install.determinate.systems/nix | sh -s -- install

This installer is better for CI systems than the official one. It sets up multi-user mode properly and integrates with systemd without requiring manual tweaking.

The next issue was permissions, which i ran into. Cachix needs to configure binary caches, which requires the user to be in Nix's trusted users list. The Determinate installer creates a clean config structure with a custom configuration file for user modifications:

echo "trusted-users = root runner" >> /etc/nix/nix.custom.conf
systemctl restart nix-daemon
systemctl restart actions.runner.thein3rovert-nixos-config.github-runner.service

After that, I updated my build workflow to use the self-hosted runner. The changes were minimal since I already had the validation steps in place:

build-nixos:
  runs-on: [self-hosted, terraform]
  needs: [validate-ssh, validate-cachix]
  steps:
    - name: Setup SSH
      uses: webfactory/ssh-agent@v0.9.0
      with:
        ssh-private-key: ${{ secrets.SSH_PRIVATE_KEY }}
    - name: Checkout
      uses: actions/checkout@main
      with:
        fetch-depth: 1
    - name: Install Nix
      uses: DeterminateSystems/nix-installer-action@main
    - name: Cachix
      uses: cachix/cachix-action@master
      with:
        authToken: ${{ secrets.CACHIX_AUTH_TOKEN }}
        name: thein3rovert
    - name: Build nixos
      run: nix build --accept-flake-config --print-out-paths .#nixosConfigurations.nixos.config.system.build.toplevel

The only change is runs-on: [self-hosted, terraform] instead of runs-on: ubuntu-latest. One things i also learn is you can use self hosted runner for more than one build and manage them using labels. Everything else stayed the same. I kept the Nix installer action in the workflow even though Nix was already on the runner, since it handles some additional setup and doesn't hurt to run.

Disk Space Issues

The first attempt failed to running the workflow failed when it starts building the third host nixos, the other two host bellay and marcus were fine... this failed because i had set the runner to a 30GB disk thinking i'd be enough, which sounds reasonable however, nixos host been a very large management sever, it managed every other server so i expect it to have alot of packages and dependencies, so it ran out of space half way through.

error: writing to file: No space left on device
error: Cannot build '/nix/store/24rbhg4di3sb33h9phpf0mzb7kzcjr80-nixos-system-nixos-26.05.20260304.80bdc1e.drv'.

NixOS builds accumulate a lot of intermediate derivations. Each configuration shares some packages, but they each have their own closure that needs to be built or downloaded. Thirty gigabytes wasn't enough.

I already had the runner defined in Terraform, so fixing this was just updating the disk size:

module "github_runner" {
  source = "../../modules/lxc"

  # ... other config ...
  disk_size = "80G"  # was 30G
}

A quick terraform apply later and the runner had enough space to handle all three configurations with room to spare.

The Finale..

First build after the disk resize: 6 minutes. Not the 1 minute I was hoping for, but a massive improvement over 20+ minutes and i assume thi is because it needed to cache new derivation from the previous failed builds. Also, the Nix store was being populated from Cachix over my local network instead of the public internet, which helped. The runner also had persistent storage, so anything built stayed around for subsequent runs.

Second build: 1 minute and 30 seconds.

Third build: 1 minute flat.

That's a 20x speedup compared to GitHub's hosted runners. The first build still takes a few minutes because it's populating the local Nix store, but every build after that is essentially instant. The persistent Nix store means most derivations are already present. When something does need to be fetched, it's coming from Cachix over a low-latency local network connection instead of traversing the public internet.

The difference in iteration speed is dramatic. Before, I'd push a change, go do something else, and come back to check if it worked. Now I push and immediately see results.

A lil more on why this works, yea...the speedup comes from a few factors working together. The persistent Nix store is the biggest win. As i mentioned above the github hosted runners start fresh every time, so every package has to be downloaded or built, however this keep everything around between builds, so only changed derivations need work.

Local network access matters more than I expected. Cachix is fast, but there's still latency involved in pulling packages over the internet... in this case my runner sits on the same network as my infrastructure, so when it does need to fetch something, it's happening at LAN speeds.

Running on my own hardware means I control the resources. The LXC container has 2 cores and 4GB of RAM, which isn't a lot, but it's consistently available. GitHub's runners vary in performance depending on what you get assigned. Consistency helps with predictable build times.

What's Actually Running

I'm building three NixOS configurations in parallel: my main desktop (nixos), a server (marcus), and another machine (bellamy). Each build job runs independently on the same runner:

strategy:
  matrix:
    config:
      - nixos
      - marcus
      - bellamy

This matrix strategy means all three builds kick off simultaneously. Since they share most of their dependencies through the Nix store, the second and third builds benefit from whatever the first one already fetched. The whole workflow completes in whatever time the longest individual build takes, which is consistently around 1 minute after the initial cache population.

The Cost of Self-Hosting my own runner

I know i've discussed the benefit and pros, but one thing i personally believe is every good thing has a downside or costs, there are tradeoffs to running your own infrastructure. The runner needs maintenance. When something breaks, I'm the one who has to fix it. Compare to GitHub's hosted runners that just work, even if they're slow.

Another, NixOS builds are large, and you need to plan for that. Eighty gigabytes feels like overkill for a CI runner, but it's necessary when you're building multiple system configurations and i see my adding more host later on.

Security is one other cons..yea. The runner has network access to my infrastructure and credentials to push to Cachix. It's running on my network behind Tailscale, which helps, but it's still a potential attack surface, comparing that to GitHub hosted runners which are ephemeral and isolated, which is safer by default.

For my use case though, the tradeoffs are worth it.. and i'd spend more time hardening it. The speed improvement is substantial, and I was already running this infrastructure anyway. Adding a CI runner to an existing Proxmox cluster doesn't add much operational overhead.

Future Improvements

Right now the runner just builds NixOS configurations. The next step is actually deploying them. I could have the runner push builds directly to machines instead of building locally on each host. That would let me deploy to multiple machines simultaneously without each one needing to build independently.

I'm also thinking about adding build artifact caching beyond what Cachix provides. The runner could maintain a local binary cache that's even faster than pulling from Cachix. For frequently rebuilt derivations, that might shave off a few more seconds.

The current setup is good enough though. One minute builds are fast enough. When I push a change, I know immediately if it worked. That's what I was after.

If you're running NixOS and getting frustrated with slow CI builds, setting up a self-hosted runner might be worth the effort. The initial setup takes some time, but the productivity gain is real. Twenty minutes to one minute is GOAT...

Thanks for reading...happy learning.

Building a Self-Hosted GitHub Runner

Sat, 14 Mar 2026 00:00:00 GMT

The problem with most of my infrastructure projects is the feedback loop when i make a change, push it and have to wait 20 minutes for the build.. and then discover i have made a typo. I repeat this a few times and and realise i've burned an entire afternoon. I got introduced to github runner from someone at work place and I've decided it's time i build mine.

What I'm really after is building and deploying my NixOS infrastructure with fastee iteration cycles. But i have to start somewhere..first i'd like to use it to run my terraform infra workflow, you know the fmt, validate, plan and apply...after i'd want to use it for my nixos build for each of my server which as of today takes over 27min of build time.

The Runner Problem

As it's my first time building a custom runner, i wasn't to familiar with the specs i'd need or what is enough so i went with the following.
Image: Ubuntu 22.04
core: 2
Memory: 4gb
Disk size: 30gb
Network: Tailscale

The reason why i am using tailscale is because i want to keep my runner within my tailnet, as all my server also run within my tailnet, exposing it over the internet is risky especially for self hosted github runner in a public repo and additionally, i have other services that will be needed by my workflow like hasicorp vault that is running within my tailnet, i use it to store my secrets for terraform and othher things.

I already had Terraform managing my LXC containers on Proxmox, so spinning up a dedicated GitHub Actions runner was straightforward. I added a new module to my dev environment:

# GitHub Actions Runner (Ubuntu 22.04)
module "github_runner" {
  source = "../../modules/lxc"

  target_node = var.target_node
  password    = var.root_password
  hostname    = "github-runner"
  vmid        = 120
  ostemplate  = "local:vztmpl/ubuntu-22.04-standard_22.04-1_amd64.tar.zst"
  cores       = 2
  memory      = 4096
  swap        = 1024
  disk_size   = "30G"
  storage     = var.rootfs_storage
  ssh_keys    = file(var.ssh_public_key_path)

  gateway         = var.gateway
  cidr_suffix     = var.cidr_suffix
  ip_base         = var.ip_base
  bridge          = var.bridge
  container_id    = 120
  proxmox_host_ip = var.proxmox_host_ip
  os_type         = "ubuntu"
  extra_tags      = ["github-runner", "ci"]
}

After applying that, I SSH'd into the container and set it up as a GitHub Actions runner. GitHub provides the download links and token when you add a new runner in your repository settings. The setup process looks like this:

# Create a runner user and switch to it
useradd -m -s /bin/bash runner
su - runner

# Download and extract the runner
mkdir actions-runner && cd actions-runner
curl -o actions-runner-linux-x64-2.332.0.tar.gz -L \
  https://github.com/actions/runner/releases/download/v2.332.0/actions-runner-linux-x64-2.332.0.tar.gz
tar xzf ./actions-runner-linux-x64-2.332.0.tar.gz

# Configure the runner
./config.sh --url https://github.com/YOUR_USER/nixos-config --token YOUR_TOKEN

# Exit back to root and install as a service
exit
cd /home/runner/actions-runner
sudo ./svc.sh install runner
sudo ./svc.sh start

The important part is installing it as a systemd service so it survives reboots and runs automatically.

Next i installed tailscale on the runner, along with a few other dependencies. Installing Tailscale is just curl -fsSL https://tailscale.com/install.sh | sh followed by tailscale up. For the other tools, I installed Node.js 20 (the GitHub runner needs this), Terraform, Vault CLI, unzip, and the usual bosses like curl and git.

I didnt want to store the secrets directly on github. That works, but it means duplicating secrets across different systems. I already had everything in Vault: Proxmox credentials, S3 credentials for Terraform state, SSH keys. So duplication there wasnt just necessary. The workflow starts by pulling everything from Vault:

- name: Get S3 credentials from Vault
  id: vault
  run: |
    export VAULT_ADDR="${{ secrets.VAULT_ADDR }}"
    export VAULT_TOKEN="${{ secrets.VAULT_TOKEN }}"

    # Fetch S3 credentials from Vault
    S3_ACCESS_KEY=$(vault kv get -field=access_key_id secret/s3)
    S3_SECRET_KEY=$(vault kv get -field=secret_access_key secret/s3)

    # Fetch SSH public key from Vault
    SSH_PUB_KEY=$(vault kv get -field=ssh_public_keys secret/ssh)

    echo "::add-mask::$S3_ACCESS_KEY"
    echo "::add-mask::$S3_SECRET_KEY"
    echo "S3_ACCESS_KEY_ID=$S3_ACCESS_KEY" >> $GITHUB_ENV
    echo "S3_SECRET_ACCESS_KEY=$S3_SECRET_KEY" >> $GITHUB_ENV
    echo "SSH_PUBLIC_KEY=$SSH_PUB_KEY" >> $GITHUB_ENV

The only secrets stored in GitHub are VAULT_ADDR and VAULT_TOKEN. Everything else comes from Vault at runtime. I added the ::add-mask:: lines, this ensures that these values don't leak into logs.

The Full Pipeline

The complete workflow runs on pull requests and manual triggers. I specifically excluded pushes to main since I didn't want plans running on production commits. The workflow runs in parallel for both dev and prod environments using a matrix strategy:

jobs:
  terraform-validate:
    runs-on: self-hosted
    strategy:
      matrix:
        environment:
          - dev
          - prod

Each environment goes through the same steps: format checking, initialization with the S3 backend, validation, and finally plan. The format check is set to continue-on-error: true so it doesn't block the rest of the pipeline, but the workflow fails at the end if formatting is off:

- name: Terraform fmt check
  id: fmt
  run: terraform fmt -check -recursive
  working-directory: terraform/
  continue-on-error: true

# ... other steps ...

- name: Fail on fmt error
  if: steps.fmt.outcome == 'failure'
  run: |
    echo "Terraform fmt check failed. Run 'terraform fmt -recursive' to fix."
    exit 1

The init step needs both S3 credentials for the backend and Vault credentials for the provider. Terraform reads S3 credentials from AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables, while Vault credentials are passed as Terraform variables:

- name: Terraform init (${{ matrix.environment }})
  id: init
  run: terraform init -reconfigure
  working-directory: terraform/envs/${{ matrix.environment }}
  env:
    AWS_ACCESS_KEY_ID: ${{ env.S3_ACCESS_KEY_ID }}
    AWS_SECRET_ACCESS_KEY: ${{ env.S3_SECRET_ACCESS_KEY }}

- name: Terraform plan (${{ matrix.environment }})
  id: plan
  run: terraform plan -no-color
  working-directory: terraform/envs/${{ matrix.environment }}
  env:
    AWS_ACCESS_KEY_ID: ${{ env.S3_ACCESS_KEY_ID }}
    AWS_SECRET_ACCESS_KEY: ${{ env.S3_SECRET_ACCESS_KEY }}
    TF_VAR_vault_address: ${{ secrets.VAULT_ADDR }}
    TF_VAR_vault_token: ${{ secrets.VAULT_TOKEN }}
  continue-on-error: true

Conclusion

Right now this one runs validates, fmt and plan for Terraform changes and shows what would happen if I applied them. Great, but the real goal for me is speeding up NixOS build which takes around 20 minutes and I want to get that under 5 minutes or less using this same self-hosted setup.

For now though, I have a working Terraform CI pipeline that doesn't leak secrets all over GitHub and runs on hardware I control. That's a solid foundation to build on.

Looking forward to what's next....Happy Learning.
Have a blessssssssssssssssed day.. :)

NixOS LXC on Incus

Sat, 21 Feb 2026 00:00:00 GMT

A few days ago I set up my own Git instance, Forgejo. As a certified tinkerer, it was about time I explored that space, but mainly because I wanted to set up my own custom runner for my workflows, and also because I thought it would be fun to figure out. Beyond that, running my own runner means I have full control over the build environment without relying on third-party services.

I've also been experimenting with Incus as my virtualization method, and I thought... hmmm, it would be cool to run my custom runner on a minimal Incus LXC container. That's when I decided to create a minimal NixOS LXC image that I could spin up quickly whenever I needed a new runner. I didn't want the bloat that comes with minimal ISOs, so I decided to build my own custom image with exactly what I needed from the start.

Creating the Flake Structure

Before we build an image, we need to think about a few things..why we want the image, what it'll be used for, how small it should be. In my case, I wanted an image to serve as a custom runner for my Forgejo instance.

The entry point for managing a NixOS system is the flake.nix, so we need a few inputs to get started.

inputs = {
    nixpkgs.url = "github:nixos/nixpkgs?ref=nixos-unstable";
    colmena.url = "github:zhaofengli/colmena";
    disko = {
      url = "github:nix-community/disko";
      inputs.nixpkgs.follows = "nixpkgs";
    };
    nixos-generators = {
      url = "github:nix-community/nixos-generators";
      inputs.nixpkgs.follows = "nixpkgs";
    };
  };

The nixpkgs input is the main NixOS package repository containing all packages and NixOS modules. disko handles declarative disk partitioning and formatting right from the Nix config. nixos-generators lets us generate different image formats like LXC, ISO, or VM images from a NixOS configuration. colmena is what I'll use later to deploy NixOS configs to remote servers.

Then we need to add the NixOS configuration that takes in the configuration to be applied to the image. This configuration lives in configuration.nix. I won't include the full config here since it's quite long, but there's a link to the repo at the end if you want to make your own.

The NixOS configuration uses nixos-generators to build a bootable LXC container image (rootfs plus metadata) from your configuration.nix, which can then be imported into Incus.

  packages.x86_64-linux = {
	lxc = nixos-generators.nixosGenerate {
	  system = "x86_64-linux";
	  pkgs = nixpkgs.legacyPackages.x86_64-linux;
	  modules = [
		./configuration.nix
	  ];
	  format = "lxc";
	};
	lxc-meta = nixos-generators.nixosGenerate {
	  system = "x86_64-linux";
	  pkgs = nixpkgs.legacyPackages.x86_64-linux;
	  modules = [ ./configuration.nix ];
	  format = "lxc-metadata";
	};
  };

The config is reusable, so make sure to check the repo...just copy the flake.nix and configuration.nix, and make sure to change the hostname and username.

  nixosConfigurations.<HOSTNAME:CHANGE ME> = nixpkgs.lib.nixosSystem {
	system = "x86_64-linux";
	modules = [
	  disko.nixosModules.disko
	  ./configuration.nix
	];
  };

  users.users.<USERNAME:CHANGE ME> = {
    isNormalUser = true;
    extraGroups = [
      "networkmanager"
      "wheel"
    ];
    openssh.authorizedKeys.keys = [ "ENTER-SSH-KEY" ];
  };

Building the Image

Now we build the image with nix build .#lxc.

After that, we send the image over to the server and run the incus command to add the image to the Incus images list. Incus doesn't support NixOS images built with nixos-generator directly, which was frustrating to figure out.

 thein3rovert@marcus  ~/images/nixos  incus image import nixos-image-lxc-proxmox-26.05.20251205.f61125a-x86_64-linux.tar.xz  nixos-image-lxc-26.05.20251205.f61125a-x86_64-linux.tar.xz --alias nixos-runner           ✔  102  00:12:29
Error: Metadata tarball is missing metadata.yaml
 thein3rovert@marcus  ~/images/nixos 

I think I figured out the issue. I was using the nixos-generator proxmox-lxc format instead of just the plain lxc format, so the format was wrong. The issue I likely hit before was using proxmox-lxc format alone that generates a Proxmox-specific tarball without the metadata.yaml that Incus requires. The lxc-metadata format generates exactly that metadata tarball.

We need to create separate folders for both the metadata and the LXC image since they have the same name.

 thein3rovert@marcus  ~/images/nixos  ls
result-meta
 thein3rovert@marcus  ~/images/nixos  mkdir result-lxc
 thein3rovert@marcus  ~/images/nixos  ls
result-lxc  result-meta

The command to import into Incus is: metadata comes first, then the image second.

incus image import \
  result-meta/*.tar.xz \
  result-lxc/*.tar.xz \
  --alias nixos-runner

Done, the image has been imported.

 thein3rovert@marcus  ~/images/nixos  incus image import \
   result-meta/*.tar.xz \
   result-lxc/*.tar.xz \
   --alias nixos-runner
Image imported with fingerprint: ed79d35efadf77f2fdf046ed4b76a9692cf160c3efc12a2b9494e2d2689e55a6

Now let me verify with incus image list.

Here below is a pretty minimal image that will serve my needs and many more to come.

incus image list

ALIAS         FINGERPRINT    PUBLIC  DESCRIPTION                                     ARCHITECTURE  TYPE       SIZE      UPLOAD DATE
nixos-runner  ed79d35efadf  no      NixOS Yarara lxc-26.05.20251205.f61125a       x86_64        CONTAINER  213.74MiB  2026/02/21

Now let's launch a new LXC with the added image.

incus launch nixos-runner nixos-runner

And there we go...it works like it's supposed to. Now my aim is to use Nix as my own custom CI/CD runner.

Managing Deployment with Colmena

I had a bit of a problem after the creation. When I entered the created nixos-runner container, I was unable to connect to it or ping it from my main management server where I planned to manage it. Here's how the flow works...I have my main server (NixOS) and then have another server (NixOS on Marcus) on the same network at 10.10.10.x. Then on Marcus, I have Incus running nixos-lxc. But Incus wasn't getting the IP from Marcus, which was supposed to be 10.10.10.x. Instead, it gets a different one that only Marcus can connect to and not my main NixOS.

To solve this, I had to use something called SSH proxy-jump. ProxyJump means SSH through an intermediate server to reach a destination that isn't directly accessible. My main server can't reach 10.127.42.183 directly (it's a private network on Marcus), so it SSHs into Marcus first, then Marcus SSHs into the container on your behalf. To you, it feels like one direct connection.

One issue with the image I built is that the hostname I set for the image when I built it didn't happen to apply on the image after it was built, so I guess I'd have to figure out why that is. Other settings applied, but only the hostname didn't.

Apart from that, everything else looks fine. Now the next step is to apply new config using colmena. In my flake.nix, I added a new colmena deployment.

	# ---- Node: Runner [ lxc 02 ] ----
	nixos-runner = {
	  deployment = {
		targetHost = "nixos-runner";
		targetPort = 22;
		targetUser = "thein3rovert";
		buildOnTarget = true;
		tags = [
		  "prod"
		  "runner"
		];
	  };
	  nixpkgs.system = "x86_64-linux";
	  imports = [
		./hosts/runner
		agenix.nixosModules.default
		self.nixosModules.users
		self.nixosModules.containers
		self.nixosModules.nixosOs
		self.nixosModules.snippets
	  ];
	};

Upon applying my new config, I ran into a sandboxing issue. I think I've had this issue before on a previous day while I was building an image for Proxmox.

Sandboxing isolates each build in its own restricted environment so it can't access the internet or files outside its declared dependencies, ensuring reproducible builds. LXC containers don't have the kernel namespaces required to create that isolation, hence the error.

To disable that, I added the config nix.setting.sandbox = false. But my build was still failing, so I needed to do it manually. NixOS being a read-only system...I can't edit the /etc/nix/nix.conf so I had to edit the nix config in the root dir instead before my build successfully applied.

mkdir -p /root/.config/nix
echo "sandbox = false" >> /root/.config/nix/nix.conf

Yay, welcome me nixos-runner

Agent as Code

Wed, 18 Feb 2026 00:00:00 GMT

I used to not be a big fan of AI. I used to also not be a fan of "agentic workflows" as a concept. But I'd be lying if I said AI hasn't been genuinely helpful in ways I didn't expect.

Here's the thing about me: I lose focus when I have to repeat the same process over and over. Every. Single. Time. I'll be working on a project, hit a repetitive task, do it manually once or twice, and then just... quit. I don't want to do it again. So the project dies.

This has happened more times than I can count, but I've been noticing a significant improvement over time since I started using AI agents for some of my daily tasks.

How AI Found Me

First: the boring stuff. I don't want to automate everything...I mean...I actually enjoy certain manual tasks. But the repetitive stuff that drains me? The "I know how to do this, I just don't want to do it again" stuff? AI handles that now. It's not glamorous, but it's real.

Second: my journals. I write every day. Seven days a week, 2000-3000 words on what went wrong, what went right, ideas I had, things I learned, weaknesses I noticed, personal projects I worked on. Writing daily has become a habit I take seriously.

But here's the problem: what good are all those notes if they just sit there? I needed them to actually improve my habits, my work, my life. So I started using AI to process all that raw journal material into actionable insights. That alone has been worth it. I won't go into details on how I created an automated workflow that acts as my personal coach and mentor in this post, but I will share how I've been able to manage my agentic workflow.

The Real Problem: Too Many Tools

There are so many AI tools now. Claude Code. Gemini CLI. Opencode. Copilot. Every week something new drops. And each one has its own context folder...claude/, .copilot/, .gemini/, etc. Rules for this tool, references for that one, commands scattered everywhere.

rwxr-xr-x    - thein3rovert 19 Feb 21:59  .claude
.rw------- 2.8k thein3rovert 19 Feb 21:59  .claude.json
.rw-------  92k thein3rovert  8 Feb 19:20  .claude.json.backup
.rw------- 2.8k thein3rovert 19 Feb 21:59  .claude.json.backup.1771538342266
.rw------- 2.8k thein3rovert 19 Feb 21:59  .claude.json.backup.1771538342270
.rw------- 2.8k thein3rovert 19 Feb 21:59  .claude.json.backup.1771538342475
.rw------- 2.8k thein3rovert 19 Feb 21:59  .claude.json.backup.1771538342941
.rw------- 2.8k thein3rovert 19 Feb 21:59  .claude.json.backup.1771538343914
drwxr-xr-x    - thein3rovert 10 Dec  2025  .copilot
drwxr-xr-x    - thein3rovert 10 Dec  2025  .opencode
rwxr-xr-x    - thein3rovert 19 Feb 21:59  .gemini-cli

I'd be working on a task with Claude Code, build up a nice set of rules and references for it, then switch to try another tool because it has a free model or whatever. And suddenly I had to recreate all those documents. My agent configurations were scattered across my system. No version control. No single source of truth. Just chaos.

That's where the productivity gain disappears. Not from using AI...but from managing all the noise around it.

Not just that, what if you want to manage permissions? Each AI agent CLI has something called agent.json or some sort of JSON file where you can add the default model for a specific agent, the name, permissions on things the agent can access, commands it can run and more. Having to cd into a ".agentname" can just be a productivity killer and it makes us just forget about restricting our agent to certain permissions and commands, and maybe one day the agent runs rm -rf / on us because it was hallucinating. What I am driving at here is all of this can be done in one centralized project/dir regardless of where the agent main dir is situated, with the help of Nix and home-manager. You might then be thinking, I don't know Nix, what is Nix? Well, you can also do it with bash, which I am sure every engineer is familiar with. I won't be sharing how to do this with bash, but reading how I did it with Nix should give you ideas on how to do it with bash.

Why Nix? Why Home-Manager?

You might wonder: why not just use a shared folder and symlinks? Why bring Nix into this?

Fair question. Here's my answer:

I already manage my entire dotfiles and system configuration with Nix. My nixos-config handles everything..my terminals, my editors, my development environments, my dotfiles. When I rebuild, my entire setup is reproducible from a single git clone && nixos-rebuild switch.

So when I thought about managing my AI agent configs, the answer was obvious: do it the same way I do everything else. Home-manager already handles XDG config directories. My agent resources are just more files. Why would I maintain them separately?

xdg.configFile = {
  "opencode/commands" = { source = "${inputs.polis}/commands"; recursive = true; };
  "opencode/context" = { source = "${inputs.polis}/context"; recursive = true; };
  "opencode/prompts" = { source = "${inputs.polis}/prompts"; recursive = true; };
  "opencode/skills" = { source = "${inputs.polis}/skills"; recursive = true; };
};

One place. One repo. One rebuild. Everything stays in sync.

And when I get a new machine? The flake pulls down, I run home-manager switch, and all my agent configs, skills, and context are there. No manual setup. No "I forgot to copy that folder" moments.

The Agents: Meet Arkadia

I've built out agents with distinct personalities. The main ones:

Arkadia: Named after the sanctuary built from the Alpha Station in The 100 (yes, I'm a fan). It's my personal assistant in "Plan Mode." Read-only analysis, planning, guidance. It knows my context: software engineer, PARA methodology, early mornings for deep work, evening daily reviews. It routes requests to the right skills and stays out of the way.

Arkadia-Forge: Same assistant but in "Worker Mode." Full write access, but with safety prompts for destructive operations. This is the one I use when I actually want to get things done, not just plan them.

Then there are others..Prometheus for orchestration, Hephaestus for building, Sisyphus for running commands (heavily restricted for safety), Librarian and Explore for research. These are built-in agents that came with the opencode installation, but I barely use them because they aren't really tailored to my personal workflow and needs.

I would always suggest creating agents that suit your needs. You alone know why you do on a daily basis to accomplish a task, how you achieve a task to the best of your ability, so why not train your agent to do the same and refine as much as you want until you reach a desired state.

The Skill System

The skills are what make this actually useful, dont confuse skills for agents. Each skill is a small, focused module that teaches my agent how to handle specific types of work. The task-management skill knows my PARA methodology and Obsidian setup, understanding where notes should go and how to format them. The reflection skill processes my daily journal entries into actual insights I can use. The communications skill helps with drafting emails and follow-ups. The research skill handles investigation workflows, and the knowledge-management skill keeps my notes organized and searchable.

Skills to me are what I use to train my agent on how to go about doing a specific task. Say, for example, I just finish having a planning session with my agent Arkadia on how to go about building a CI/CD pipeline.

The conversation goes on and on, ideas spill out alongside my coffee, and we finally arrive at a destination. But then I don't want to just close the session or tell it to implement. I want to have a summary of our discussion: what I suggested, what we decided not to do, problems we had, solutions we suggested, and what we finally went with, in a short summary and then a list of todos so I can follow along step by step. Later, when I need to use Arkadia Forge for the implementation and execution, I can just tell it to go straight to this note, saving me time to prompt again and it gets the full context of what I want to do.

Arkadia will use the task-management skill to perform the actions, and that skill still has all my note structure, knows where it's supposed to save the note, how to format it, the location of references and similar notes and more.

Each skill has a SKILL.md as the entry point, with optional scripts/, references/, and assets/ directories.

skills/
├── agent-development/
├── brainstorming/
├── doc-translator/
├── excalidraw/
│   ├── references/
│   └── SKILL.md
├── frontend-design/
│   └── SKILL.md
├── mem0-memory/
├── memory/
│   ├── references/
│   └── SKILL.md
├── obsidian/
│   └── SKILL.md
├── outline/
├── outlook/
├── pdf/
└── reflection/

When Arkadia receives a request, it routes to the appropriate skill based on intent.

What This Gives Me

This setup gives me a single source of truth for everything. When I edit a skill, every agent can use it immediately without copying. Changes are tracked in git, so I can review what changed, revert if needed, and see my thinking over time. When I get a new machine, one flake update pulls down all my agent configs, skills, and context. The knowledge is decoupled from any specific tool, so I'm not locked in.

It's Not Perfect!!! Runnnnn!!!!

I'll be honest...this setup isn't perfect.

Agent configurations are embedded into opencode's config.json at Nix evaluation time. That means when I change an agent definition, I need to rebuild for it to take effect. Skills and commands are symlinked, so changes appear immediately, but it's still a compromise.

But here's what I've learned: treating my AI workflows as code..modular, versioned, declarative..has made them more maintainable. When I improve a skill or write a new command, I do it once and every agent immediately has access, so I don't have to copy prompts between tools or wonder where I put that reference.

The Honest Take

I'm not sold on the AI hype. I don't think AI is going to take over the world or whatever. But I'm practical about what helps.

This helps.

Not because it's AI. But because it solves a real problem I had. too many tools, too much scattered context, too much friction. And at the end of the day, that's what good systems do: they reduce friction so you can focus on what actually matters.

May we meet again.

LTSP network on Incus

Sat, 10 Jan 2026 00:00:00 GMT

Today I woke up quite earlier than usual and couldn't go back to sleep, so I decided to work on something with the little time I had. I've been putting off this project for a while now because I pretend that I don't have the time, haha.

The project involves emulating a complete LTSP network. LTSP stands for Linux Terminal Server Project... it makes maintaining tens or hundreds of diskless clients as easy as maintaining a single PC. The terminals (client machines) boot over the network without needing any permanent storage attached.

In this setup, both the ltsp_server and ltsp_client run as virtual machines on a physical machine with LXD installed. The main architecture is just two computers... one for the server and one client. Later we could add any number of clients easily.

The setup aims to do two things. First, it roughly matches the physical network topology where the server has two connections... one to the internet and one to a switch. Second, it helps us get around an issue that we might run into when getting an LTSP network running with LXD.

For this setup, you need to have Incus or some sort of LXD installed on your system. I decided to go with LXD because it gives you the ability to manage both virtual machines and system containers. We could do this with just a single application in a container if we used something like Docker, but we're not doing that because we need to run an entire Linux operating system... which is possible through the Linux kernel LXC system.

I already had Incus installed on my system since I use it to spin up LXC containers for some of my services like Garage. I wanted that isolation, so I didn't need to worry about installing anything new on my server.

The setup works like this... the LTSP client is set up as a virtual machine booting via iPXE, and the LTSP server itself runs as an LXC container. iPXE is basically a network boot firmware that lets machines boot from the network instead of a local disk.

The big benefit of this setup is that it lets you have your own personal development machine without having to install something like Proxmox on bare metal or set up a dedicated server machine just for personal use.

The Virtual Network

For the virtual network, we need two bridge networks. The first one is called lxdbr0 and the second is lxdbr1. I already had the first bridge network since it came by default when I installed Incus LXD, so I only needed to create the second one.

You can think of these bridge networks as physical switches... they basically allow containers to communicate with anything that's attached to the bridge. The client and the server will communicate through the second bridge, lxdbr1.

One really nice thing about LXD is that it provides containers with IP addresses using DHCP and gives them internet access through NAT. This means our first network lxdbr0 acts as the internet router in the physical network topology.

Since I already had the first bridge network, I just had to create the second one. This bridge network is what we'll use to connect all the instances we create. lxdbr1 uses the LTSP standard subnet which is 192.168.67.1/24. I disabled NAT, DHCP, and IPv6 addresses because LTSP will be providing a PXE-enabled DHCP for the client to enable network booting.

incus network create lxdbr1 \
  ipv4.address=192.168.67.1/24 \
  ipv4.nat=false \
  ipv4.dhcp=false \
  ipv6.address=none

After creating lxdbr1, I confirmed the network was created using this command:

incus network list

RESULT
+----------+----------+---------+-------------------+---------------------------+---------------------------------+---------+---------+
| lxdbr1   | bridge   | YES     | 192.168.67.1/24   | none                      | Custom: lxd tutorial bridge     | 2       | CREATED |
+----------+----------+---------+-------------------+---------------------------+---------------------------------+---------+---------

Perfect... now I have both bridge networks I need.

Next step was to create the server container. For the container, I went with Linux Mint since it's lightweight.

incus init images:mint/xia ltsp-server

If you want to view the list of available container images, you can use this command:

incus image list images: | grep mint

Security Configuration

In order to get LTSP working in a server container, there are some LXD security settings we need to relax. This isn't ideal for production, but since this is for a development environment, it's fine. We need to enable security nesting and security privileged mode. The reason is that LTSP wasn't designed as a confined workload... it assumes root-level access. Without relaxing these settings, it won't function properly.

When we set security.nesting to true, this allows the container to create nested namespaces and perform operations that look like container-inside-container behavior. Setting security.privileged to true removes the user namespace mapping, giving the container near-host privileges. Without this, mounting filesystems, exporting NFS roots, or accessing kernel features needed for PXE and client boot often fail in subtle ways.

# Enable nesting and privileged mode
incus config set ltsp-server security.nesting true
incus config set ltsp-server security.privileged true

LTSP also needs access to loop devices for mounting images. This required three steps:

# Set cgroup permissions for loop devices
incus config set ltsp-server raw.lxc "lxc.cgroup2.devices.allow = b 7:* rwm
lxc.cgroup2.devices.allow = c 10:237 rwm"

# Add loop-control device
incus config device add ltsp-server loop-control unix-char \
  path=/dev/loop-control source=/dev/loop-control

# Count and add all loop devices from host
HOST_LOOP_COUNT=$(ls /dev/loop[0-9]* 2>/dev/null | wc -l)
echo "Found $HOST_LOOP_COUNT loop devices on host"

for i in $(seq 0 $((HOST_LOOP_COUNT - 1))); do
  if [ -e /dev/loop$i ]; then
    incus config device add ltsp-server loop$i unix-block \
      path=/dev/loop$i source=/dev/loop$i
  fi
done

Optionally, you can bump up the resources allocated to the server. I did this so that later, when building a compressed image of the server's filesystem, it runs quickly. Adjust these as you see fit:

incus config set ltsp-server limits.cpu=5
incus config set ltsp-server limits.memory=3GiB

Server Network Configuration

Now for the server network configuration, we need to have two virtual network interface cards. One will be attached to lxdbr0, which will take an IP address from DHCP since it's enabled by default. The second interface card will be attached to lxdbr1, which we already disabled DHCP for. We'll also need to attach a static IP address to the second interface card. Since LTSP handles things differently, we need to use the distribution's standard method to assign an IP address from within the container itself.

The first interface card is already connected to lxdbr0 by default, so I only needed to configure the second one manually.

incus config device add ltsp-server eth1 nic \
  network=lxdbr1 \
  name=eth1

After connecting the interface, we need to start the server and confirm that the server has an IP address from DHCP on eth0 and no IPv4 on eth1.

incus start ltsp-server

incus exec ltsp-server -- ip --brief address

And as you can see below, we have an IP address on eth0 and nothing on eth1, exactly as expected.

lo     UNKNOWN  127.0.0.1/8
eth0   UP       10.135.108.178/24 ... <----- comes from LXD's DHCP
eth1   UP        ... <--- no IPv4 address

To wrap up the network configuration, we need to create a netplan file for eth1 with a static IP so it persists across reboots.

incus exec ltsp-server -- bash -c 'cat > /etc/netplan/60-ltsp-static.yaml << EOF
network:
  version: 2
  ethernets:
    eth1:
      addresses:
        - 192.168.67.2/24
EOF'

Then fix the permissions so netplan doesn't complain:

incus exec ltsp-server -- sh -c 'chmod 600 /etc/netplan/*.yaml'

And finally, apply the changes:

incus exec ltsp-server -- netplan apply

I verified again that the changes took effect:

incus exec ltsp-server -- ip --br -4 a
lo      UNKNOWN  127.0.0.1/8
eth0    UP       10.135.108.178/24
eth1    UP       192.168.67.2/24 # <-- now set

So that's all about setting up the LTSP server. I'll make a new post on setting up the client. Hope you enjoyed it.

Backups the hard way

Thu, 08 Jan 2026 00:00:00 GMT

Learning About Backups the Hard Way

Backups were never really something that I took seriously. I don't know why... maybe it's because I'd never really experienced a system failure before, or maybe because when I did, I eventually didn't end up losing that much data. I just relied on my system as long as it looked clean and things were running pretty well. I assumed that no unfortunate event would cause my laptop to get destroyed or something. That mindset changed pretty quickly.

About six months ago, I had an unfortunate event with my homelab. I got this new mini PC that was just about seven months old at the time. This PC was what I used as my management node... I used it to manage all my other machines and nodes on my servers in my homelab. I never really foresaw my PC having an NVMe failure because I believed it was a new PC. I had a lot of data, a lot of important documents, and a lot of important notes on this PC. I even had my second brain on this PC. My second brain is like my notes folder where I write down things I learn and other things.

On this day, I had just finished updating my system to the latest version, so I decided to go downstairs to get a cup of tea after the long updating and patching process. I didn't know that the latest version of the operating system I was running had a package that wasn't being maintained. The package consumed quite a lot of RAM and memory, and that made my system overload. It was running at one hundred percent while I was busy making my tea downstairs. When I got back to the system, I realized that my system had stopped working. I couldn't move my mouse. I could not do anything on it. I tried to reboot the system and found out that my drive had been burnt due to the overload.

I lost everything. When I say everything, I mean everything. I used that management system to save most of what I know... my documents, my everything. It was devastating. Eventually I got a new NVMe after about two months when I could save up and buy a new one. At that time, I started thinking about backups. Even though I didn't really take backups seriously, I tried as much as possible to back up the most important things to my Google Drive, and to take it seriously enough to enable the backups that I was running on my servers and save them into an S3 bucket.

You'd think I would have learned my lesson by then, right? But I didn't.

Not so long after that, I had another unfortunate problem with my work laptop, which I had just gotten. I thought maybe because it's a new laptop and I haven't really used it for and then it safe. I forgot to back up my notes to Google Drive. I had been taking notes since the start of my placement... I logged everything I did daily. I had a lot of notes and presentations from meetings I'd been to, conferences, conversations, and other important stuff that I kept for work. Unfortunately, I lost all of it when the system crashed. This put me in a really sad place for about a week. At that time, I started to take backups a lot more seriously, and I would say I'��m not Evangelist when it comes to backing up things on the system. I always make sure that I remind my friends... have you backed up your system? Have you backed up your phone? Have you backed up your backup? Have you backed up yourself? And stuff like that. So in order not all? I'm just going to work to my current you back up the most important thing on my system Currently, I only use two tools for backing up things on my system. The first one is Ansible, and the second one is Restic.

Ansible is a widely used infrastructure tool called IaC. It's mainly useful for managing multiple servers at once and can also be used for infrastructure automation and infrastructure deployment, and other cool stuff. However in this post we will not be talking about my ansible backup but my zerobyte backup because it's easier to selfhost and easy to use, this cannot be used in an actual production setting, it's best suitable for homelab use case.

In order to run Zerobyte, you need to have Docker and Docker Compose installed on your server. Then, you can use the provided docker-compose.yml file to start the application.

services:
  zerobyte:
    image: ghcr.io/nicotsx/zerobyte:v0.21
    container_name: zerobyte
    restart: unless-stopped
    cap_add:
      - SYS_ADMIN
    ports:
      - "4096:4096"
    devices:
      - /dev/fuse:/dev/fuse
    environment:
      - TZ=Europe/Paris # Set your timezone here
    volumes:
      - /etc/localtime:/etc/localtime:ro
      - /var/lib/zerobyte:/var/lib/zerobyte

Do not run Zerobyte on a server that is accessible from the Internet. If you want to do so, make sure you have a VPS or change your port to something non-standard and use a secure SSH tunnel... something like Cloudflare or Tailscale.

Also, do not try to point this specific volume to a network share because if you do, you'll face permission issues and strong performance degradation.

After running the command to start Zerobyte, you can visit the web UI on the specified port and you should get a minimal interface like this:

As you can see, the interface contains five main sections... the volume section, the repository section, the backup section, notification section, and the settings section.

The volume section represents the source data that you want to backup. The repository represents where you want your encrypted backup to be stored. And the backup section is where you create your actual backup jobs once you already have your volume and repository configured. The backup is the main important part of the application.

Zerobyte also offers a few backends that we can use for our repository... S3 bucket, Cloudflare R2 (which is what I use for my permanent backup), Google Cloud Storage, Azure Blob Storage, REST Server, SFTP, and local storage.

One very interesting thing I love about Zerobyte is the ability to create snapshots. Zerobyte automatically helps you create snapshots of your backup. So in case you lose your data or if you need to restore your data from two weeks ago, you can basically just restore from the snapshots.

To add a volume, navigate to the Volumes section in the web interface and click Create volume. You'll need to fill in the volume name, volume type (SMB, NFS, WebDAV, Directory, etc.), and connection settings like credentials and paths. For local directories, you'll need to mount them into the ZeroByte container first by adding a volume mapping in your docker-compose.yml, then select Directory as the volume type in the web interface.

For creating repositories, navigate to the Repositories section, click Create repository, select the backend type (Local, S3, REST, rclone, etc.), and configure your connection settings.

Once you have your volumes and repositories set up, you can create backup jobs.

Navigate to the Backups section and click Create backup job. You'll configure which volume to back up, which repository to store it in, set your schedule (daily, weekly, etc.), specify which files or directories to include, and set your retention policy... like keeping the last 10 snapshots, 5 dailies, 3 weeklies, and 2 monthlies. You can also set exclude patterns for specific files you don't want backed up.

Backup jobs will run automatically according to your schedule, but you can also trigger manual backups using the Backup Now button.

When you need to restore data, just navigate to the Backups section, select the backup job, choose a snapshot, browse the files and select what to restore, choose your restore location (original location or custom), and configure any restore options like overwrite mode.

ZeroByte makes it easy to restore individual files or entire directories from any snapshot.

So that's a simple walkthrough on how to back up your files and data. If you've been postponing this, now is the time to back up your life.

Zerobyte is very easy to use because of its simple minimalist web interface and structure. One last thing worth mentioning... Zerobyte also includes notifications.

Notifications are important but not necessary. You can use them to confirm or verify if your backup has been completed or if your backup failed. It sends an alert to either your Discord or your Slack channel. I haven't set up notifications on mine yet, but I plan to do that this week.

So that's all about this blog post. If you enjoyed it, thank you so much for reading. Have a good day and don't forget to back up.

Information consumption and Management

Thu, 01 Jan 2026 00:00:00 GMT

I started my morning creating my calendar for the weeks ahead this year. I used to avoid calendars, but they've been helping me keep my focus lately. I always had this fear of managing two calendars since I also use one for work that contains mainly work-related stuff. I can put personal events on the work calendar, but I want to give having separate ones a shot. It shouldn't be that draining to manage two calendars, and this personal one connects to my phone so I'll get reminders before any task occurs. This year I'm giving calendar notifications a real try to see how useful they can be for me.

Here's how I plan to consume and manage information this year. I have a now.txt.md file which is what I'm currently using to write this. Its main usefulness is basically capturing what I just worked on or what I'm currently working on... anything happening or that happened in the moment. In short, it's like work daily journals but I don't want to call it daily journal since it can end up being really long sometimes and sometimes contains code snippets for my debugging process when I don't want to create new notes for debugging.

I do have a daily journal but I mainly use this for work. I write basically everything going on at work, my todos and other things. Later I'll write about how I organize my daily journal for work and how I use it.

I also have a now-work.txt.md file. Don't mind the name... it's just a way to trick my brain to just write whatever right now. I use this just like my personal now.txt.md. I write whatever is going on at the moment at work. You might be wondering why I don't just write it in my work journal. I did try that, but I always want to make sure my work journal is short and detailed so I can easily read up on it when I have stand-ups. I want to make sure it doesn't contain unnecessary information that should be in the now-work.txt.md like my debugging process, plans for work-related projects, workflows, code snippets and more. All these go into the now-work.txt.md.

You might be thinking that's too much, but it's really not once you get used to it. I realized that work-related stuff can sometimes conflict with personal things and I needed a better way to create that separation, especially when you're keeping work and personal notes on the same laptop. Having two different laptops for writing moments of your day is just draining.

In general, here's the breakdown. Now.txt for personal stuff, now-work.txt for work stuff, and a daily journal specifically for work.

Now.txt is a really powerful technique to trick your brain into writing a lot more and keep your thoughts flowing. You don't have to keep creating new notes and folders each time you get an idea or want to quickly jot down something. Once you get used to it, your brain knows that for everything, it should remind you to use now.txt. Then later when you have time, you can separate them into new notes.

Now.txt is also useful when you want to know what you did the previous day or the day before or maybe weeks before. You don't have to worry about opening a lot of folders and finding the exact notes. Just open your now.txt and navigate to the date. I'll write later on how I organize my now.txt, which I think is the best way since it helps a lot with information retrieval.

So yeah, that's still my plan for consuming and managing information this year.

Optimizing todo for AI workflow

Sat, 27 Dec 2025 00:00:00 GMT

I maintain a now.txt.md note in Obsidian where I capture all my daily ideas and tasks. I built an n8n workflow that reads this note and uses GitHub Copilot CLI to automatically create tickets from my TODOs. The problem was that I was sending the entire note every time, which sometimes contains hundreds of words of context that wasn't needed. This approach meant higher API costs and, worse, creating duplicate tickets when Copilot encountered the same tasks it had already processed.

You might be wondering why I even want to automate this process. I think automating ticket creation from notes removes the friction between having an idea and getting it tracked in my project management system. But I had some concerns. Sending large notes repeatedly to AI services was getting expensive. Without tracking what had been processed, I kept getting duplicate tickets. And sometimes I wanted to reprocess old dates or extract specific days, but my workflow wasn't flexible enough for that.

My Initial Solution

I needed a bash script that could extract just the ## Tasks section from my note instead of passing everything. Simple enough... but the real challenge was preventing duplicates while maintaining flexibility.

What I Built

The solution evolved into a smart extraction script with state tracking. Here's how it works:

#!/usr/bin/env zsh

# Extract specific date
./extract_todos.sh now.txt.md --date 2025-12-27

# Extract only new dates (default)
./extract_todos.sh now.txt.md

# Extract everything
./extract_todos.sh now.txt.md --all

# Reset state
./extract_todos.sh now.txt.md --reset

The script identifies dates in YYYY-MM-DD format and extracts everything under each date until the next date appears. So if I have a note structured like this:

## Tasks

2025-12-11

- [x] Completed task
- [ ] Incomplete task

2025-12-22

- [ ] Another task
  > Additional context

The script tracks which dates have been processed in a .processed file to avoid duplicates. The first time I run it, it processes all dates. The second time, it only processes new dates and won't reprocess the dates from December 11th and 22nd:

# First run: processes all dates
./extract_todos.sh now.txt.md | gh copilot suggest

# Second run: only processes new dates
./extract_todos.sh now.txt.md | gh copilot suggest

If I need to reprocess an old date, I can use the --date flag:

./extract_todos.sh now.txt.md --date 2025-12-11

What Didn't Work

My first attempt didn't go too well. I only extracted incomplete tasks and filtered out completed ones along with their notes. I quickly realized this wasn't giving me the full picture. I wanted the complete context of each day, including what I'd accomplished and any notes I'd attached to tasks. The incomplete tasks by themselves didn't tell the whole story.

What Did Work

The final approach extracts entire date sections while maintaining a simple state file. The script uses AWK to parse the markdown structure:

awk '
/^## Tasks/ { in_tasks=1; next }
/^## / && in_tasks { exit }
in_tasks && /^[0-9]{4}-[0-9]{2}-[0-9]{2}/ {
    if (current_date && content) {
        print current_date
        print content
    }
    current_date=$0
    content=""
    next
}
in_tasks && current_date {
    if (content) content = content "\n" $0
    else content = $0
}
' now.txt.md

Now my workflow feels much more natural. I jot down ideas in now.txt.md throughout the day, run the extraction script when I'm ready to create tickets, and only the new date sections get sent to GitHub Copilot CLI. No more duplicate tickets, much lower API costs, and I can still go back and reprocess specific dates when I need to. The friction between capturing an idea and having it tracked properly is almost gone. 4. Tickets are created without duplicates 5. API costs stay minimal

The script respects my note format (which I didn't have to change), tracks state automatically, and gives me control when I need to reprocess specific dates. Simple, effective, and cost-efficient.

jnix

Fri, 07 Nov 2025 00:00:00 GMT

A few nights ago, I was going through a git repository when I came across a CLI program called njust. Like jnix, it's a command-line tool built using just.

Just is a command-line runner similar to make. Make is a command-line tool similar to just 🤣. Just kidding, it never ends...haha.

Make is a command-line interface software tool that performs actions ordered by configured dependencies as defined in a configuration file called a makefile.

Commands run using Just are called recipes and are usually stored in a file called Justfile that has a similar syntax to make.

In order to run a command, we can simply run:

just <RECIPE>

There are plenty of use cases for using this tool, but in my case I just wanted to experiment with it and I wanted a way to use it to run some common commands I use daily on my NixOS homelab like for example:

Rebuilding my NixOS config
Deploying config changes to remote hosts
Sending files over to remote hosts
Garbage cleaning my system
and more.

Obviously there are commands that do these things already, but I just think it'd be cool to have my own CLI tool that acts as a wrapper around these commands.

The Nix Way

The simpler way to do this is to create a Justfile anywhere inside a folder, but I decided to do it the Nix way... being that it will be created as a module and can be shared between all my hosts.

Also, Nix offers a function called writeShellApplication which is a higher-level helper used for creating a shell script or CLI program from a bash script. We can also specify the dependencies needed by these scripts. Nix pulls the dependencies from the Nix repository during runtime and creates a Nix derivation with it alongside the script, which in this case is our Justfile.

Merging Recipes

First, I created a Nix variable called mergeContentIntoJustFile, responsible for concatenating all the recipes (Just commands) that I will be creating and merging them into a Justfile:

mergeContentIntoJustFile = ''
  _default:
    @printf '\033[1;36mjnix\033[0m\n'
    @printf 'Just-based recipe runner for NixOS.\n\n'
    @printf '\033[1;33mUsage:\033[0m jnix <recipe> [args...]\n\n'
    @jnix --list --list-heading $'Available recipes:\n\n'

  ${concatenateString "\n" (attributeValues cfg.recipes)}
'';

Then comes a new variable for validating the Justfile syntax. This validation will be done during build time so I can catch errors early. Saves me time from having to debug after the build.

validatedJustfile =
  pkgs.runCommand "jnix-justfile-validated"
    {
      nativeBuildInputs = [ pkgs.just ];
      preferLocalBuild = true;
    }
    ''
      # Write the merged justfile content to a temporary file
      echo ${escapeShellArgument mergeContentIntoJustFile} > justfile

      # Validate justfile syntax using 'just --summary'
      echo "Validating jnix cli justfile syntax..."
      just --justfile justfile --summary >/dev/null || {
          echo "ERROR: jnix justfile has syntax errors!"
          echo "justfile content:"
          cat justfile
          exit 1
        }
      # Copy validated justfile to the nix store output path
      cp justfile $out
      echo "jnix justfile validation successful"
    '';

Nix also offers a function called pkgs.runCommand which is a low-level Nix function for creating a derivation by running arbitrary shell commands. You give it:

A name for the derivation
A set of environment variables
A shell script to run

So we will pass into the function a Just package as a dependency which it will use to validate the syntax during runtime.

Creating the CLI Application

Using the pkgs.writeShellApplication function, I created a shell application used with the merged Justfile containing all the gathered recipes:

jnixScript = pkgs.writeShellApplication {
  name = "jnix";
  runtimeInputs = [
    pkgs.jq
    pkgs.just
  ];
  text = ''
    # Execute 'just' with the merged justfile, preserving current directory
    exec just --working-directory "$PWD" --justfile ${mergedJustfile} "$@"
  '';
};

Example Recipe

Here is an example of a recipe I have in my created Justfile:

system = ''
  # Show system info
  [group('system')]
  info:
    @echo "Hostname: $(hostname)"
    @echo "Nixos Version: $(nixos-version)"
    @echo "Kernel: $(uname -r)"
    @echo "Generation: $(sudo nix-env --list-generations -p /nix/var/nix/profiles/system | tail -1 | awk '{print $1}')"
    @echo "Revison: $(nixos-version --json | jq -r '.configurationRevision // "unknown"')"
'';

It's used to check for Nix system information when I run the command jnix info:

 jnix info
Hostname: nixos
Nixos Version: 25.11.20250924.e643668 (Xantusia)
Kernel: 6.12.48
Generation: 74
Revison: unknown

Taking back my attention

Sat, 01 Nov 2025 00:00:00 GMT

A few months ago, I set up an RSS feed while going through a period of intentional consumption and a social media detox.
I don’t even remember exactly what drove me to it, but I’m sure I was simply fed up.. tired of how drained and sad I felt after just 30 minutes of scrolling through social media.

Before I talk about how RSS changed my habits, here’s a quick glimpse of what my mornings used to look like.

Before the Detox

6:00 a.m.
Wake up. Turn off my alarm. Navigate to the clock app to silence the next few alarms..because they love to scream while I’m still in the bathroom, soaked in bubbles and soap 😂.

And right there, shining on my lock screen: a notification.

“Someone just liked your photo.”

Of course, I tap it, just to see which post it was. Somehow, ten minutes later, I’ve watched 20 reels. I can’t even remember the last 15, but I know I laughed, cried, and felt sad, all in that short time.

Ten minutes, and I’ve gone through a rollercoaster of emotions.
That’s not normal. It’s like my brain’s being controlled by a remote...and the remote is the Reels algorithm.

Discovering RSS

I wanted to take back control of my attention, you know.. to be my own remote.

So I started researching healthier ways to consume content. That’s when I came across RSS.
It’s been around for decades, though not many people use it anymore. Still, it was exactly what I needed.

I gathered blogs, newsletters, and creators I genuinely enjoy, added them to my feed, and started reading them whenever I felt the urge to scroll.
The result? I began to enjoy reading again, without the noise.
Over time, I noticed real changes in myself:
My attention span improved.
I became more patient.
My days were a bit more boring, but a lot less sad.
I felt… human.

Maybe I’ll write a separate post on the full benefits of a social media detox later, but for now, I want to share how I organized my RSS feed...and why you should too.

Setting Up My RSS Feed

I started by identifying my main interests: technology, philosophy, academia, photography, podcasts, and a few others.

One thing I quickly learned is not to add too many sources.
Even though RSS gives you full control, too much content can make you indecisive again.
So I kept my feed simple and intentional.

Here’s how I categorized it:

Technology → YouTube, Reddit, Medium, tech blogs
Philosophy → Email newsletters, personal blogs
Photography → Favorite creators’ sites and photo journals
Podcasts → RSS-enabled audio feeds

Under Technology, for example, I looked through my YouTube history and wrote down the creators I truly enjoy. I tagged each one so I could easily organize them later.

For blogs, many of my favorites already had RSS feeds... so instead of saving them in my linkding bookmarks, I added them directly to RSS. That way, I’d know the moment they published something new.

I’m also working on a separate post where I’ll share the blogs, creators, and newsletters I follow..so if you find any interesting, you can add them to your feed too.

Most newsletters go straight to email... which means they either get lost in spam or buried under other messages.
And since I’ve turned off email notifications (they can be very distracting), I use a tool called Kill the Newsletter.
It gives you a unique email address to subscribe to newsletters. Every email sent there is converted into an Atom feed that you can add to your RSS reader.
It’s simple, and it keeps your inbox clean.

Within my categories, I use labels for my interests: infrastructure, homelab, Nix, NixOS, web development, and networking.
That way, every item, whether it’s a video, blog, podcast, or newsletter, can be filtered by topic whenever I want.

It’s like having a calm, curated version of the internet that I control.

Final Thoughts

After setting everything up, I can confidently say:
The remote to my attention and consumption is finally in my hands.. for now.

If something new comes along, I’ll adapt and share the journey here.

Until then, stay intentional.
Bye for now!

Clan

Mon, 20 Oct 2025 00:00:00 GMT

Background: Discovering Clan at NixCon 2025

Last month, I had the opportunity to attend NixCon 2025 online (unfortunately couldn't make it in person). It was an incredible experience learning about the latest developments in the Nix ecosystem. One of the talks that particularly caught my attention was about Clan - a tool for managing NixOS machines declaratively - presented by Qubae and Kenji Berthold.

You can watch their presentation here: NixCon 2025 - Clan Talk

The talk really resonated with me. I've been managing my homelab infrastructure with NixOS for a while now, using Colmena for deployments, but I was intrigued by Clan's approach to machine management. While I wasn't planning to immediately migrate my entire infrastructure, the idea of being able to explore new tools and potentially improve my setup was too tempting to resist.

Today, I decided to take Clan for a spin - just for tinkering purposes, really. This blog post documents that journey, including the bumps along the way.

The Original Plan: Testing on Demo

My initial plan was simple: integrate Clan into my demo host as a test case. This seemed like the perfect candidate - it's a non-critical machine in my homelab specifically set up for experimentation.

However, reality had other plans. When I went to check on the demo host, I discovered it had been down for months due to an SSD failure I'd forgotten about. That old Kingston drive finally gave up the ghost sometime back, and I hadn't gotten around to replacing it.

So, pivot time.

Plan B: Meet Octavia

Enter Octavia - a new node I recently spun up as a test server. Fresh installation, working hardware, and perfect for experimentation. Octavia would be my guinea pig for Clan integration.

My Existing Flake Structure

Before diving into Clan, let me show you what my infrastructure looked like. I'm managing 5 NixOS hosts using a flake-based setup with flake-parts:

nixos - My main workstation
demo - Test server (currently deceased)
vps-het-1 - Production VPS
wellsjaha - Prod environment
octavia - New Prod server (our hero today)

Here's the relevant part of my original flake.nix:

{
  description = ''
    This is a configuration for managing multiple nixos machines
  '';

  inputs = {
    home-manager = {
      url = "github:nix-community/home-manager";
      inputs.nixpkgs.follows = "nixpkgs";
    };

  outputs = { self, nixpkgs, flake-parts, ... }@inputs:
    flake-parts.lib.mkFlake { inherit inputs; } {
      systems = [ "aarch64-linux" "x86_64-linux" "aarch64-darwin" "x86_64-darwin" ];

      imports = [ ./modules/flake ];

      flake = let
        forAllLinuxHosts = self.inputs.nixpkgs.lib.genAttrs [
          "nixos" "demo" "vps-het-1" "wellsjaha" "octavia"
        ];
      in {
        nixosConfigurations = forAllLinuxHosts (
          host: self.inputs.nixpkgs.lib.nixosSystem {
            specialArgs = { inherit self inputs; };
            modules = [
              ./hosts/${host}
              # ... various modules
            ];
          }
        );

        # Colmena deployment configuration
        colmenaHive = colmena.lib.makeHive {
          # ... deployment configs for all hosts
        };
      };
    };
}

This setup worked well. I could deploy using Colmena, rebuild individual machines with nixos-rebuild, and everything was nicely organized. But I wanted to see what Clan could bring to the table.

Adding Clan: The Integration Process

Step 1: Adding the Clan Input

First, I needed to add clan-core as a flake input:

inputs = {
  # ... existing inputs ...

  clan-core = {
    url = "https://git.clan.lol/clan/clan-core/archive/main.tar.gz";
    inputs.nixpkgs.follows = "nixpkgs";
  };
};

Step 2: Creating the Clan Configuration

The key insight here was that I didn't want to convert all my hosts to Clan immediately - just Octavia for testing. So I created a Clan configuration that only included one machine:

clan = clan-core.lib.clan {
  self = self;
  specialArgs = {
    inherit self inputs nix-colors colmena nixpkgs-unstable-small;
  };
  meta.name = "octavia-clan-test";

  machines = {
    octavia = {
      nixpkgs.hostPlatform = "x86_64-linux";
      imports = [
        ./hosts/octavia
        # Clan networking configuration
        {
          clan.core.networking.targetHost = "10.20.0.2";
        }
      ];
    };
  };
};

Step 3: Merging Configurations

Here's the clever bit: I kept my existing nixosConfigurations for all hosts, then overrode just Octavia with the Clan version:

nixosConfigurations =
  (forAllLinuxHosts (
    host: self.inputs.nixpkgs.lib.nixosSystem {
      # ... regular configuration ...
    }
  ))
  // {
    # Override octavia with Clan configuration
    octavia = clan.config.nixosConfigurations.octavia;
  };

# Expose Clan outputs
inherit (clan.config) clanInternals;
clan = clan.config;

This approach meant:

My other 4 hosts remained completely unchanged
Octavia got the Clan treatment
I could still use Colmena for the non-Clan hosts
Everything coexisted peacefully

Step 4: Adding the Clan CLI

To interact with Clan, I enabled my development shell and added the CLI:

devShells = forAllSystems ({ pkgs }: {
  default = pkgs.mkShell {
    packages = [
      # ... existing tools ...
      clan-core.packages.${pkgs.system}.clan-cli
    ];
  };
});

The Bumps in the Road

Of course, it wasn't all smooth sailing. I hit a couple of issues that needed fixing.

Issue 1: Duplicate Disko Imports

My first attempt included all module imports in the Clan configuration:

imports = [
  ./hosts/octavia
  agenix.nixosModules.default
  inputs.disko.nixosModules.disko  # ← This was the problem!
  self.nixosModules.users
  # ... etc
];

This caused an error:

error: The option `_module.args.diskoLib' is defined multiple times

The issue? My ./hosts/octavia configuration already imported disko! I was importing it twice, causing a conflict. The fix was simple - just import the host configuration and let it handle the rest:

imports = [
  ./hosts/octavia
  {
    clan.core.networking.targetHost = "10.20.0.2";
  }
];

Issue 2: Missing Network Interface

The second issue was more subtle:

error: Failed assertions:
- networking.defaultGateway.interface is not optional when using networkd.

In my Octavia configuration, I had:

networking.defaultGateway = "10.20.0.254";

But when using systemd-networkd (which Clan expects), you need to specify the interface:

networking.defaultGateway = {
  address = "10.20.0.254";
  interface = "enp1s0";
};

I added this as an override in the Clan configuration for now, but the proper fix is to update the host configuration directly.

The Final Result

After working through these issues, here's my complete integrated flake:

{
  description = ''
    This is a configuration for managing multiple nixos machines
  '';

  inputs = {
    home-manager = {
      url = "github:nix-community/home-manager";
      inputs.nixpkgs.follows = "nixpkgs";
    };
    clan-core = {
      url = "https://git.clan.lol/clan/clan-core/archive/main.tar.gz";
      inputs.nixpkgs.follows = "nixpkgs";
    };
  };

  outputs = {
    self,
    home-manager,
    nixpkgs,
    flake-parts,
    nixpkgs-unstable-small,
    clan-core,
    ...
  }@inputs:
    flake-parts.lib.mkFlake { inherit inputs; } {
      systems = [
        "aarch64-linux"
        "x86_64-linux"
        "aarch64-darwin"
        "x86_64-darwin"
      ];

      imports = [ ./modules/flake ];

      flake = let
        inherit (self) outputs;

        allSystems = [
          "aarch64-linux"
          "x86_64-linux"
          "aarch64-darwin"
          "x86_64-darwin"
        ];

        forAllSystems = f:
          self.inputs.nixpkgs.lib.genAttrs allSystems (
            system: f {
              pkgs = import self.inputs.nixpkgs {
                inherit system;
                config.allowUnfree = true;
              };
            }
          );

        forAllLinuxHosts = self.inputs.nixpkgs.lib.genAttrs [
          "nixos"
          "demo"
          "vps-het-1"
          "wellsjaha"
          "octavia"
        ];

        # Clan configuration for Octavia only
        clan = clan-core.lib.clan {
          self = self;
          specialArgs = {
            inherit self inputs nix-colors colmena nixpkgs-unstable-small;
          };
          meta.name = "octavia-clan-test";

          machines = {
            octavia = {
              nixpkgs.hostPlatform = "x86_64-linux";
              imports = [
                ./hosts/octavia
                {
                  clan.core.networking.targetHost = "10.20.0.2";
                }
                {
                  networking.defaultGateway = {
                    address = "10.20.0.254";
                    interface = "enp1s0";
                  };
                }
              ];
            };
          };
        };
      in {
        # NixOS Configurations - regular for most, Clan for Octavia
        nixosConfigurations =
          (forAllLinuxHosts (
            host: self.inputs.nixpkgs.lib.nixosSystem {
              specialArgs = {
                inherit self inputs nix-colors colmena nixpkgs-unstable-small;
              };
              modules = [
                ./hosts/${host}
                self.inputs.home-manager.nixosModules.home-manager
                agenix.nixosModules.default
                inputs.disko.nixosModules.disko
                self.nixosModules.users
                self.nixosModules.nixosOs
                self.nixosModules.hardware
                self.nixosModules.core
                self.nixosModules.containers
                {
                  nixpkgs.overlays = [ self.overlays.default ];
                }
                {
                  environment.systemPackages = [
                    ghostty.packages.x86_64-linux.default
                  ];
                }
                {
                  home-manager = {
                    backupFileExtension = "backup";
                    extraSpecialArgs = { inherit self; };
                    useGlobalPkgs = true;
                    useUserPackages = true;
                  };
                  nixpkgs.config.allowUnfree = true;
                }
              ];
            }
          ))
          // {
            # Override octavia with Clan configuration
            octavia = clan.config.nixosConfigurations.octavia;
          };

        # Expose Clan outputs
        inherit (clan.config) clanInternals;
        clan = clan.config;

        # Development shell with Clan CLI
        devShells = forAllSystems ({ pkgs }: {
          default = pkgs.mkShell {
            packages = (with pkgs; [
              alejandra
              nixd
              nil
              bash-language-server
              shellcheck
              shfmt
              nix-update
              git
              ripgrep
              sd
              fd
              pv
              fzf
              bat
              nmap
              python3
              python3Packages.wcwidth
            ]) ++ [
              self.inputs.agenix.packages.${pkgs.system}.default
              clan-core.packages.${pkgs.system}.clan-cli
            ];
          };
        });

        # NixOS Modules
        nixosModules = {
          users = ./modules/nixos/users;
          nixosOs = ./modules/nixos/os;
          locale-en-uk = ./modules/nixos/locale/en-uk;
          hardware = ./modules/hardware;
          core = ./modules/core;
          containers = ./modules/nixos/containers;
        };
}

Testing It Out

With everything configured, it was time to test:

# Update flake inputs
nix flake update

# Verify the flake structure
nix flake show

# Enter development shell
nix develop

# List Clan machines
clan machines list
# Output: octavia

# Deploy to Octavia using Clan
clan machines update octavia

And it worked! Octavia was now being managed through Clan while my other hosts continued to work normally with their existing setup.

Reflections and Next Steps

This experiment was exactly what I hoped for - a chance to explore Clan without disrupting my existing infrastructure. Here are my key takeaways:

Incremental adoption is possible - You can integrate Clan alongside existing tools
Configuration coexistence - Clan and traditional NixOS configs can live together
Good documentation - The Clan docs were helpful for troubleshooting

Resources

Clan Documentation
NixCon 2025 Clan Talk by Qubae and Kenji Berthold
Clan Core GitHub
Converting Existing NixOS Configurations Guide

From Simple to Modular

Sat, 18 Oct 2025 00:00:00 GMT

My NixOS Nginx Configuration Journey

When I first started configuring Nginx on NixOS, I did what most people do. I followed the NixOS Wiki and created a straightforward, working configuration. It served my needs perfectly... until I realized I had multiple hosts to manage, and copying the same configuration with minor tweaks wasn't just tedious—it felt wrong in the declarative world of Nix.

This is the story of how I transformed a simple Nginx configuration into a reusable, modular system. It's a journey that taught me more about Nix than any tutorial could, and if you're learning NixOS, I hope it helps you too.

The Beginning: A Simple Nginx Setup

My initial configuration was straightforward and looked something like this:

{ config, lib, ... }:
let
  inherit (lib) mkIf mkEnableOption;
  if-nginx-enable = mkIf config.nixosSetup.services.nginx.enable;
in
{
  options.nixosSetup.services.nginx = {
    enable = mkEnableOption "Nginx Server";
  };

  config = if-nginx-enable {
    services.nginx = {
      enable = true;
      virtualHosts."localhost" = {
        root = "/var/www/localhost";
        listen = [
          {
            addr = "0.0.0.0";
            port = 80;
          }
        ];
        locations."/" = {
          index = "index.html";
        };
      };
    };

    systemd.tmpfiles.rules = [
      "d /var/www/localhost 0755 root root -"
      "L+ /var/www/localhost/index.html - - - - ${builtins.toFile "index.html" ''
        <!DOCTYPE html>
        <html>
          <head><title>Hello from thein3rovert</title></head>
          <body>
            <h1>Hello from the in3rovert Nginx on Nixos!</h1>
            <p>Served from a nixos declarative config 😎</p>
          </body>
        </html>
      ''}"
    ];
  };
}

This worked beautifully! I had a basic enable option, a hardcoded virtual host, and a simple HTML page served from the Nix store. Everything was declarative, and I felt pretty good about it.
![[From Simple to Modular - Nginx-1760748694607.png]]

The Nix Store Symlink Discovery

One interesting challenge I encountered early on was getting the HTML content to actually appear in /var/www/localhost/index.html. Initially, I tried using C! (force copy) with systemd-tmpfiles, but I kept getting a file that just contained the Nix store path instead of the actual HTML content.

The solution? Use L+ instead, which creates a symlink to the Nix store. This is actually more "Nix-like" anyway—instead of copying files around, we point to immutable content in the store. It's elegant and exactly how NixOS is meant to work.

The "Wait, I Need This Everywhere" Moment

Then came the moment every NixOS user experiences: I needed to configure Nginx on another host. And then another. Each time, I found myself copying the configuration and manually changing:

The server name
The IP addresses
The ports
The HTML content
The root directory

It felt... wrong. I was repeating myself, and if there's one thing Nix teaches you, it's that repetition is a code smell. I could already feel the maintenance burden building up. What if I wanted to add SSL to all hosts? What if I needed to change the default port? I'd be hunting through multiple files making the same change over and over.

Plus, let's be honest—sometimes I can just be a bit crazy about optimization and making things "proper." 😄

The Transformation: Building a Reusable Module

I decided to take the plunge and create a proper, reusable module. This wasn't just about solving my immediate problem—it was about learning Nix more deeply. Here's what I wanted to achieve:

Multiple virtual hosts: Support any number of sites per server
Flexible configuration: Make everything configurable with sensible defaults
Type safety: Leverage Nix's type system to catch errors early
Reusability: Share the module across all my hosts with minimal duplication

Understanding the Building Blocks

First, I needed to understand the NixOS module system better. Here are the key concepts I learned:

Options Define the Interface

Options are how you expose configuration to users (including future you). Each option needs:

A type - What kind of data it accepts
A default - A sensible fallback value
A description - Documentation for what it does

Submodules for Complex Structures

When you need nested configuration (like listen addresses within a virtual host), you use submodules. They're like mini-modules within your module.

mapAttrs for Transformation

The mapAttrs function is your friend for transforming your custom options into the format that services.nginx expects.

The Implementation

Here's the modular configuration I built:

{ config, lib, ... }:
let
  inherit (lib)
    mkIf
    mkEnableOption
    types
    mkOption
    ;

  createOption = mkOption;
  mapAttribute = lib.mapAttrs;
  if-nginx-enable = mkIf config.nixosSetup.services.nginx.enable;
  cfg = config.nixosSetup.services.nginx;

  # Type aliases for readability
  attributeSetOf = types.attrsOf;
  subModule = types.submodule;
  string = types.str;
  list = types.listOf;
  boolean = types.bool;
  port = types.port;

  # Configurable defaults
  serverName = "localhost";
  baseListenAddress = "0.0.0.0";
  basePort = 80;
in
{
  options.nixosSetup.services.nginx = {
    enable = mkEnableOption "Nginx Server";

    virtualHosts = mkOption {
      type = attributeSetOf (subModule {
        options = {
          root = createOption {
            type = string;
            default = "/var/www/${config.networking.hostName}";
            description = "Root directory for virtual host";
          };

          serverName = createOption {
            type = string;
            default = "${serverName}";
            description = "Server name from virtual host";
          };

          listenAddresses = createOption {
            type = list (subModule {
              options = {
                addr = createOption {
                  type = string;
                  default = "${baseListenAddress}";
                  description = "IP address to listen on";
                };

                port = createOption {
                  type = port;
                  default = basePort;
                  description = "Port to listen on";
                };

                ssl = mkOption {
                  type = boolean;
                  default = false;
                  description = "Enable SSL for this listener";
                };
              };
            });

            default = [
              {
                addr = "${baseListenAddress}";
                port = basePort;
                ssl = false;
              }
            ];
            description = "List of address and ports to listen on";
          };

          webPage = createOption {
            type = string;
            default = "index.html";
            description = "Simple Webpage";
          };

          webPageContent = createOption {
            type = string;
            default = ''
              <!DOCTYPE html>
              <html>
                <head><title>Welcome to ${config.networking.hostName}</title></head>
                <body>
                  <h1>Hello from ${config.networking.hostName}!</h1>
                  <p>Served from Nixos declarative config</p>
                </body>
              </html>
            '';
            description = "My Simple HomePage";
          };
        };
      });
      default = { };
      description = "Virtual Host Configuration";
    };
  };

  config = if-nginx-enable {
    services.nginx = {
      enable = true;

      virtualHosts = mapAttribute (name: vhostName: {
        serverName = vhostName.serverName;
        root = vhostName.root;
        listen = vhostName.listenAddresses;
        locations."/" = {
          index = vhostName.webPage;
        };
      }) cfg.virtualHosts;
    };

    # Create directories and symlink HTML files for each virtual host
    systemd.tmpfiles.rules = lib.flatten (
      lib.mapAttrsToList (name: vhost: [
        "d ${vhost.root} 0755 root root -"
        "L+ ${vhost.root}/${vhost.webPage} - - - - ${builtins.toFile "${name}-${vhost.webPage}" vhost.webPageContent}"
      ]) cfg.virtualHosts
    );
  };
}

Key Design Decisions

Let me break down some of the choices I made:

1. Type Aliases for Readability

attributeSetOf = types.attrsOf;
subModule = types.submodule;
string = types.str;

I created these aliases to make the code more readable. Yes, they're just wrappers, but attributeSetOf is more self-documenting than types.attrsOf.

2. Smart Defaults

default = "/var/www/${config.networking.hostName}";

The default root directory uses the hostname, which means each host automatically gets a unique path without manual configuration. Small touches like this reduce the cognitive load when setting up new hosts.

3. Nested Submodules for Listen Addresses

listenAddresses = createOption {
  type = list (subModule {
    options = {
      addr = createOption { ... };
      port = createOption { ... };
      ssl = mkOption { ... };
    };
  });

This allows for multiple listen addresses per virtual host, each with its own IP, port, and SSL settings. It's flexible without being complicated.

4. Transformation with mapAttrs

virtualHosts = mapAttribute (name: vhostName: {
  serverName = vhostName.serverName;
  root = vhostName.root;
  listen = vhostName.listenAddresses;
  locations."/" = {
    index = vhostName.webPage;
  };
}) cfg.virtualHosts;

This is where the magic happens. I take my custom options and transform them into the format that services.nginx.virtualHosts expects. It's a clean separation between the interface I want to provide and the underlying NixOS options.

Using the Module Across Hosts

Now here's where it all pays off. On any host, I can configure Nginx with minimal code:

Host `WellsJaha` Simple Setup

{
  nixosSetup.services.nginx = {
    enable = true;
    virtualHosts.default = {
      serverName = "localhost";
    };
  };
}

That's it! Everything else uses smart defaults.

Host `Octavia` Multiple Virtual Hosts

{
  nixosSetup.services.nginx = {
    enable = true;

    virtualHosts = {
      main = {
        serverName = "example.com";
        root = "/var/www/example";
        listenAddresses = [
          { addr = "0.0.0.0"; port = 80; }
          { addr = "0.0.0.0"; port = 443; ssl = true; }
        ];
      };

      api = {
        serverName = "api.example.com";
        root = "/var/www/api";
        listenAddresses = [
          { addr = "10.10.10.6"; port = 443; ssl = true; }
        ];
        webPageContent = ''
          <!DOCTYPE html>
          <html>
            <head><title>API Server</title></head>
            <body><h1>API Documentation</h1></body>
          </html>
        '';
      };
    };
  };
}

Host `Bellamy` Custom Everything

{
  nixosSetup.services.nginx = {
    enable = true;
    virtualHosts.custom = {
      serverName = "custom.local";
      root = "/srv/www/custom";
      webPage = "home.html";
      listenAddresses = [
        { addr = "192.168.1.100"; port = 8080; }
      ];
      webPageContent = builtins.readFile ./custom-page.html;
    };
  };
}

What I Learned

This journey taught me several important lessons about NixOS and Nix:

Start Simple, Refactor When Needed

My simple configuration wasn't wrong—it was the right solution for that moment. Refactoring came naturally when I hit a real need. Don't over-engineer from the start.

The Module System is Powerful

NixOS modules aren't just about organizing code—they're about creating interfaces. Good modules hide complexity and expose just what's needed.

Types Are Your Friend

The type system caught several bugs during development. When you declare type = types.port, Nix validates the input. This is huge for maintainability.

Defaults Matter

Thoughtful defaults reduce configuration burden. The ${config.networking.hostName} trick means I rarely need to specify the root directory explicitly.

The Nix Store is Central

Understanding how to work with the Nix store (like using L+ for symlinks) is fundamental to writing good Nix code. Fight with it and you'll suffer; work with it and everything becomes elegant.

Conclusion

Refactoring my Nginx configuration from a simple, hardcoded setup to a flexible, reusable module wasn't just about making my life easier (though it definitely did). It was about learning to think in Nix about understanding options, types, submodules, and the art of creating good abstractions.

If you're learning NixOS, I encourage you to try something similar. Take a simple configuration you've written, identify the parts you'd want to reuse, and try making it modular. You'll learn more in the process than you would from any tutorial.

And remember: sometimes being a bit crazy about optimization is exactly what pushes you to learn something new. 😄

Worrying Not the Enemy

Tue, 07 Oct 2025 00:00:00 GMT

Worrying: Maybe It’s Not the Enemy?

I am currently reading a book on worry because I thought it was a very important thing for me to address, especially for myself. I know other people also worry. When I refer to worry, I mean being always constantly worried about the future. It involves ending up creating scenarios that are bad for you. You overthink that scenario to the extent that you feel there is always going to be a bad outcome from it.

I do not know if anyone else feels this way, but I certainly do. I worry too much. I think this is because I am a very overthinking person. I am unsure if that is a good thing or a bad thing. Maybe in some cases it is good, but honestly, not in all cases. My entire day is spent thinking about future things that might not go the way I expect.

I create these scenarios, such as:

"What if I get to this place and this happens?"
"What if this person actually does this, and this bad thing happens?"
"What if I actually get what I want, but something comes up again, and I lost it all?"

I constantly worry about everything, and my brain just does not stop. Sometimes this overwhelming feeling makes me feel really sick. I realize I spent my entire day worried about something, but those worries did not turn out to be true. That worry is only in my thought; that is not reality. When the actual event happens in the next few days, it is completely different from what I imagined it would be. It goes completely well, and what I thought would happen actually goes right.

A Shift in Perspective

I have decided now to stop, not to stop worrying but to stop creating these negative scenarios whenever I feel worried. Although I haven't finished the book I am reading yet, I was able to pick up a few key things. The book states that worrying is good. It is very good to worry, which sounds weird, but the book states this. It says that when you worry, it is a sign. It specifies worrying as a means to solving problems.

The book explains that the reason we worry is because our mind wants us to solve a particular problem. It wants us to find the solution. There is no way for us to find a solution to a problem if we do not worry about it. Therefore, worrying means we need to find a solution. It is quite funny, but true: if we decide to remove our worries, how would we solve our problems? We would not worry about the problem, and thus it would not be solved.

I usually think of worrying as a bad thing. I believe this interpretation comes from culture. When I translate the English word 'worry' into a word in my culture, it carries a totally different meaning. I associated 'worry' with a word in my culture called ironu. Ironu is defined as overthinking. Although overthinking and worrying are two completely different things, I tend to see them as the same, because my mind overthinks and worries simultaneously.

The Real Issue: Overthinking the Worry

Worrying is good. It is the overthinking that is not good. You cannot completely take worrying out of your life because it is necessary. I need to be able to worry about things because I need to find solutions for them. What I must stop doing is overthinking the worry. Overthinking leads to creating fake scenarios in my head, resulting in a lot of anxiety and nauseousness. I feel sick, and my entire day does not go well. The haunting scenarios created in my mind based on my worries are what cause me to have a bad day eventually.

To clarify: Overthinking is not a good thing to do. Worrying is good because it helps us solve our problems, but overthinking is a very different thing.

That is all I have for today. I am going for a walk, and I just wanted to share this insight. I plan to continue reading the book because I feel like I will learn a lot from it that would help me. As I discover new things, I will share them.

agenix -> ragenix

Mon, 08 Sep 2025 00:00:00 GMT

Recently, I made the switch from agenix to ragenix. Ragenix is essentially an improved version of agenix, and, interestingly, it’s written in Rust. The transition felt pretty smooth overall.

To be honest, I didn’t have to change much to get things working. The main thing I did was update the URL path in my flake.nix:

agenix = {
  inputs.nixpkgs.follows = "nixpkgs";
- url = "github:ryantm/agenix";
+ url = "github:yaxitech/ragenix";
};

That was pretty much it for the migration. I appreciated how straightforward it was.

However, I did notice a couple of differences. With agenix, whenever I added a new secret to my secret.nix file and specified a path, running the secret creation command would automatically create the directory structure for me. Ragenix doesn’t do this yet, so I have to make sure the directories exist beforehand. It’s a small thing, but it stood out to me.

Another thing I observed is that the --rekey command in ragenix only works on all secrets at once, not on individual secrets. I’m hoping this will change in the future, as it would be nice to have more granular control.

Here are the updated commands I’m using for creating and rekeying secrets:

# Using nix run
nix run github:yaxitech/ragenix -- -e <path-to-secret.age> --identity <path-to-ssh-key>
nix run github:yaxitech/ragenix -- --rekey --identity <path-to-ssh-key>

# If installed as CLI
agenix -e <path-to-secret.age> --identity <path-to-ssh-key>
agenix --rekey --identity <path-to-ssh-key>

The move to ragenix has been pretty painless, and I’m looking forward to seeing how it evolves. I’ll keep an eye out for updates, especially around secret path creation and more flexible rekeying.

Issue with Colmena

Mon, 21 Jul 2025 10:55:00 GMT

So, I’ve been having this issue with Colmena. I added the Colmena input to my flake.nix for my system and also exposed it as an output so both my flake and NixOS can make use of it. But here’s the problem—it’s not visible to my system. When I try to use it, it’s just not there.

At first, I thought maybe I messed up the configuration or missed an update in the documentation. For now, I’ve been using it via nix-shell, which works, but I have to pass the --impure flag, and honestly, I’m not a fan of that. Let’s fix this.

Step 1: Adding Colmena Input to Flake

First, I added Colmena as an input in my flake.nix:

    # ADDED: Colmena input
    colmena.url = "github:zhaofengli/colmena";

Then, I added it to the outputs:

  outputs =
    {
      self,
      home-manager,
      nixpkgs,
      nix-colors,
      ghostty,
      agenix,
      disko,
      colmena,
      ...
  };

Step 2: Running `nix flake check`

When I ran nix flake check, I got these warnings:

warning: unknown flake output 'colmena'
warning: unknown flake output 'colmenaHive'

This confused me because I followed the exact setup from the official Colmena documentation on using flakes: Colmena Using Flakes.

Here’s my current Colmena config in the flake:

  colmenaHive = colmena.lib.makeHive self.outputs.colmena;
      colmena = {
        meta = {
          nixpkgs = import nixpkgs {
            system = "x86_64-linux";
          };
        };

        # Deployment Nodes
        demo = {
          deployment = {
            targetHost = "demo";
            targetPort = 22;
            targetUser = "thein3rovert";
            buildOnTarget = true;
            tags = [ "homelab" ]; # TODO: Change tag later
          };
          imports = [
            ./hosts/demo
            inputs.disko.nixosModules.disko
          ];
          time.timeZone = "Europe/London";
        };
      };

The issue is that my flake isn’t detecting the colmena output. It says Colmena now uses a new output called colmenaHive, which I already exposed. For now, I’ll hold off on using Colmena from the input flake and try it with nix-shell instead:

nix shell github:zhaofengli/colmena

Second Issue: Infinite Recursion in Shell

When I tried running Colmena commands from the shell, I hit another error:

error: infinite recursion encountered
       at /nix/store/126fp22lvqmnfv1p290vcpmbf8yab4a5-source/lib/modules.nix:652:66:
          651|       extraArgs = mapAttrs (
          652|         name: _: addErrorContext (context name) (args.${name} or config._module.args.${name})
             |                                                                  ^
          653|       ) (functionArgs f);
[ERROR] -----
[ERROR] Operation failed with error: Child process exited with error code: 1
Hint: Backtrace available - Use `RUST_BACKTRACE=1` environment variable to display a backtrace

I wasn’t sure where this recursion was coming from, but based on the error, I suspected it was caused by excessive use of:

specialArgs = { inherit inputs outputs nix-colors; };

The infinite recursion error was likely caused by passing the inputs argument to modules that were already declared elsewhere. Since I have a common folder shared between hosts, this was creating conflicts.

Using --show-trace, I traced the issue to this part of my config:

 from call site
         at /nix/store/wnj1d9ysl3k95rpajdkdm8a5igl7ywa7-source/hosts/common/default.nix:12:5:
           11|     ./users
           12|     inputs.home-manager.nixosModules.home-manager
             |     ^
           13|   ];
...
   … while evaluating the module argument `inputs' in "/nix/store/wnj1d9ysl3k95rpajdkdm8a5igl7ywa7-source/hosts/common":

       error: infinite recursion encountered

To troubleshoot, I removed the Colmena config from my flake.nix input and the hive config entirely. Using only the Colmena shell, I ran colmena apply again and got this error:

[INFO ] Using flake: git+file:///home/thein3rovert/thein3rovert-flake
error: flake 'git+file:///home/thein3rovert/thein3rovert-flake' does not provide attribute 'packages.x86_64-linux.colmenaHive', 'legacyPackages.x86_64-linux.colmenaHive' or 'colmenaHive'
[ERROR] -----
[ERROR] Operation failed with error: Child process exited with error code: 1
Hint: Backtrace available - Use `RUST_BACKTRACE=1` environment variable to display a backtrace

Turns out, Colmena expects the colmenaHive output to be present. To fix this, I stopped adding the common config to the new VM, so it doesn’t contain the conflicting home-manager configuration.

The Fix

I finally figured out the issue. Colmena behaves differently from nixos-rebuild when it comes to passing flake inputs. With nixos-rebuild, flake inputs are automatically passed to all modules. With Colmena, you need to explicitly pass them.

Initially, I was doing this:

{
  inputs = {
    # ... existing inputs

    # Uncomment and fix Colmena input
    colmena = {
      url = "github:zhaofengli/colmena";
    };
  };

  # ...
}

But this only passes the Colmena GitHub URL without including the flake inputs. Here’s the correct way:

{
  inputs = {
    # ... existing inputs

    # Uncomment and fix Colmena input
    colmena = {
      url = "github:zhaofengli/colmena";
      inputs.nixpkgs.follows = "nixpkgs"; # Pass in the flake input
    };
  };

  # ...
}

Then, in the Colmena configuration within the flake, I needed to pass the inputs to all nodes using the specialArgs function:

colmena = {
  meta = {
    nixpkgs = import nixpkgs {
      system = "x86_64-linux";
    };
    # Pass inputs to all nodes
    specialArgs = { inherit inputs outputs; };
  };
};

According to the latest Colmena release, if you’re using the newest version, the colmenaHive output must be present in your flake. As stated in the documentation:

Colmena reads the colmenaHive output in your Flake, generated with colmena.lib.makeHive.

You can read more about it in their official documentation here.

Since I’m running the older version of Colmena via nix-shell, I don’t need to worry about the colmenaHive output. However, when deploying a new node, I still have to add the --impure flag:

colmena apply --on <nodename> --impure

And it should deploy successfully:

INFO ] Selected all 1 nodes.
      🕑 4s 1 running
 demo 🕑 4s     'github:nixos/nixpkgs/77b584d61ff80b4cef9245829a6f1dfad5afdfa3?narHash=sha256-bmEPmSjJakAp/JojZRrUvNcDX2R5/nuX6b

Key Insights and Takeaways

Explicit Input Passing: Unlike nixos-rebuild, Colmena requires you to explicitly pass flake inputs to all modules using specialArgs.
ColmenaHive Requirement: If you’re using the latest version of Colmena, ensure your flake exposes the colmenaHive output.
Avoid Infinite Recursion: Be cautious when sharing configurations between hosts. Conflicts in specialArgs or overlapping inputs can lead to infinite recursion errors.
Use --show-trace: This flag is invaluable for debugging issues in your configuration.

What I’d Do Differently

Read the Docs Thoroughly: I would double-check the latest Colmena documentation before diving into implementation.
Test Incrementally: Instead of adding everything at once, I’d test each part of the configuration step-by-step to catch issues early.
Avoid Legacy Methods: While using nix-shell worked as a temporary fix, I’d aim to transition fully to the latest Colmena features and workflows.

Manual to Bash

Sat, 21 Jun 2025 00:00:00 GMT

I've been manually deploying my blog for way too long, and honestly, it was getting tedious. After reading this great article about From bash to github action, I got inspired to finally automate my deployment process. My plan is simple: start with bash scripting to learn the fundamentals, then eventually graduate to proper CI/CD pipelines.

Starting Simple: My First Deployment Script

I'm currently using zsh, so my script will likely have some zsh syntax initially, but I'll make sure to keep it bash-compatible as I go. Here's what I came up with for my first attempt:

#!/bin/bash

# deploy.sh - This script is using for automating my personal blog deployment which is built with astro

set -e # Exit script on fail command  TODO: Print out a message on failed command

echo "Deployment Starting..."

git pull origin master # TODO: Add steps to choose branch types or automatically detect if its master or main

npm ci # Install dependencies ( Clean install )

npm run test #  Run test to make sure everything is good

# TODO: Check if the container is currently running
# and if it is terminate and build again

npm run build # Build the application by running the build script in the package.json

# Run database migration by running the migration script in the package.json ( I dont have one now so)
# Add option to select of migration script exit and if not echo a message
npm run migrate

pm2 restart all # Restart all application managed by Node process manager

Writing this script was actually pretty enlightening. I found myself adding TODO comments as ideas popped up - things like giving developers feedback on what's happening, handling different branch types, and checking if containers are already running. It felt natural to think through these edge cases as I was coding.

I also learned a few things while writing this. The ci in npm ci stands for "clean install" - I've probably used this command before but never really thought about what it meant. And pm2 is a Node process manager, which was completely new to me.

Reality Check: First Deployment Attempt

Of course, nothing ever works on the first try. I immediately hit this error:

zsh: ./deploy.sh: bad interpreter: /bin/bash: no such file or directory

Had to change the shebang to work with my system. Then the build failed because I don't actually have test scripts set up yet - there should definitely be a conditional check for that. Next, pm2 wasn't installed, which made me realize I need better dependency checking.

But here's the thing that really clicked for me: my site is static! I'm doing static hosting with Docker, so I don't need pm2 at all - that's only for SSR or custom Node servers. The Docker container handles serving my static dist folder just fine.

Iteration 2: Docker-Focused Approach

This realization led me to completely rethink my approach. Here's the updated script:

#!/usr/bin/env bash

# deploy.sh - This script is using for automating my personal blog deployment which is built with astro

set -e # Exit script on fail command  TODO: Print out a message on failed command

echo "Deployment Starting..."

git pull origin master # TODO: Add steps to choose branch types or automatically detect if its master or main

npm ci # Install dependencies ( Clean install )

# npm run test #  Run test to make sure everything is good

# TODO: Check if the container is currently running
# and if it is terminate and build again

npm run build # Build the application by running the build script in the package.json

# Run database migration by running the migration script in the package.json ( I dont have one now so)
# Add option to select of migration script exit and if not echo a message
# npm run migrate

# pm2 restart all # Restart all application managed by Node process manager ( Not needed for static files )

echo "Building application completed successfully"

echo "Stoping the running application..."

# Confirm is using sudo or user
sudo podman compose down

sudo podman compose up --build -d

echo "Deployment completed successfully"

Much cleaner! I commented out the parts I don't need and focused on what actually matters for my setup. But I still couldn't run this on my server because I needed more safety checks.

Adding Safety and Flexibility

Running deployment scripts can be dangerous if you're not careful. I realized I needed two important safety measures:

Branch verification - Make sure I'm deploying from the right branch
Root user safety - Avoid running everything as root

Here's my final version with these improvements:

#!/usr/bin/env bash

# deploy.sh - Deploy Astro project with Docker Compose

set -e # Exit script on fail command  TODO: Print out a message on failed command

ALLOWED_BRANCH="master" # Branch used for deplyoment ( main or master)

# Get the current branch
CURRENT_BRANCH=$(git rev-parse --abbrev-ref HEAD)

# Check the correct branch
if [ "$CURRENT_BRANCH" != "$ALLOWED_BRANCH" ]; then
  echo "You are on the branch '$CURRENT_BRANCH'. Please switch to '$ALLOWED_BRANCH' before deploying."
  exit 1
fi

echo "Now on the correct branch: $CURRENT_BRANCH"

echo "Deployment Starting..."

git pull origin "$ALLOWED_BRANCH"

npm ci # Install dependencies ( Clean install )

npm run build # Build the application by running the build script in the package.json

echo "Building application completed successfully"

echo "Stoping the running application..."

read -p "Use sudo for Docker Compose? (y/N): " USE_SUDO
COMPOSE_CMD="podman compose"
if [[ "$USE_SUDO" == [yY] ]]; then
  COMPOSE_CMD="sudo $COMPOSE_CMD"
fi

echo "Now using '$COMPOSE_CMD' "

$COMPOSE_CMD down
$COMPOSE_CMD up --build -d

echo "🚀 Deployment completed successfully"

The branch check is straightforward - it gets the current branch and compares it to what's allowed. If you're on the wrong branch, it stops you right there. No accidental deployments from feature branches!

The sudo prompt gives me flexibility. Sometimes I need root permissions for Docker operations, sometimes I don't. Rather than hardcoding it, I can decide at runtime.

Success! First Automated Deployment

Finally ran the script on my server and got this satisfying output:

Stoping the running application...
Use sudo for Docker Compose? (y/N): y
Now using 'sudo podman compose'
🚀 Deployment completed successfully

That little rocket emoji at the end felt like such a win!

What I Learned and What's Next

This whole process taught me a few things:

Start simple - My first script shouldn't way more complex than needed
Understand your stack - Realizing I needed Docker commands instead of pm2 was a game-changer
Safety first - Branch checks and user prompts prevent costly mistakes
Iterate quickly - Each failure taught me something valuable

I know this script is pretty basic, but I'm enjoying the learning process and don't want to overcomplicate things yet. There's obviously a lot more I could add but my goal is to learn gradually and understand each piece.

Next up, I want to explore some improvements to this script. Maybe add some logging, better error messages, or even a simple configuration file. Then eventually, I'll take what I've learned here and apply it to a proper CI/CD pipeline with GitHub Actions.

The journey from manual deployment to automation is pretty satisfying, even in these small steps. Every time I run ./deploy.sh instead of remembering all those commands manually, I feel like I'm becoming a slightly better developer.

My first nix package

Sat, 12 Apr 2025 00:00:00 GMT

Creating Nix Packages

What is nix-init?

nixinit is a cli tool for initialising a package, from my own understanding.

[!cite]
My workflow involves using nix-init to create the package file and then the nix build command for make sure the pacakge file works. --li yang

Project Goal

My goal was to package the gruvbox factory CLI tool for NixOS. After checking the nixos packages website and finding no existing package for the gruvbox tool, I decided to build it myself to learn the package creation process while working with something I wanted to use. I'm fond of the gruvbox theme for its eye-friendly colors, and while I ultimately want to apply this theme across all my applications, my immediate goal was to create a package that would let me convert images to use the gruvbox color palette. This would allow me to create custom gruvbox-themed images.

Source: https://github.com/paulopacitti/gruvbox-factory

Steps to Create the Package

1. Install nix-init

Using a nix shell to access it without polluting my system just in case:

nix shell nixpkgs#nix-init

2. Run nix-init

nix-init

Follow the prompts:

Enter url
❯ https://github.com/paulopacitti/gruvbox-factory
Enter tag or revision (defaults to v2.0.0)
❯ v2.0.0
Enter version
❯ 2.0.0
Enter pname
❯ gruvbox-factory
How should this package be built?
❯ buildPythonApplication
Enter output path (leave as empty for the current directory)
❯ .

I kept pressing enter for the other options until I reached How should this package be built? where you get to select how you want the package built. I selected buildPythonApplication since I am following the documentation "My Nix Journey - How to Use Nix to Setup a Dev Environment" by Li Yang.

3. Get Flake Template

nix flake init --template github:liyangau/flake-templates#local

4. Spawn Shell with Nix File

nix develop -c $SHELL

Troubleshooting Dependencies

Initial Error

After running the nix develop command, I ran into package dependencies issues with some dependencies versions not matching due to the fact that the package from the source might have hardcoded or pinned some dependencies version and nix is trying to use an updated version or a different version of that dependencies.
![[Creating my first nix packages-1744460587273.png]]

nix develop -c $SHELL
warning: creating lock file '/home/thein3rovert/Documents/01_Project/Builds/default/flake.lock':
• Added input 'nixpkgs':
    'github:nixos/nixpkgs/d19cf9dfc633816a437204555afeb9e722386b76?narHash=sha256-lzFCg/1C39pyY2hMB2gcuHV79ozpOz/Vu15hdjiFOfI%3D'(2025-04-10)
• Added input 'systems':
    'github:nix-systems/default/da67096a3b9bf56a91d16901293e51ba5b49a27e?narHash=sha256-Vy1rq5AaRuLzOxct8nz4T6wlgyUR7zLU309k9mBC768%3D' (2023-04-09)
error: builder for '/nix/store/l576pwlj50bhngb87fk8qdrm2aazzffs-gruvbox-factory-2.0.0.drv' failed with exit code 1;
       last 25 log lines:
       > copying build/lib/factory/__main__.py -> build/bdist.linux-x86_64/wheel/./factory
       > running install_egg_info
       > Copying gruvbox_factory.egg-info to build/bdist.linux-x86_64/wheel/./gruvbox_factory-2.0.0-py3.12.egg-info
       > running install_scripts
       > creating build/bdist.linux-x86_64/wheel/gruvbox_factory-2.0.0.dist-info/WHEEL
       > creating '/build/source/dist/.tmp-a1x6ri75/gruvbox_factory-2.0.0-py3-none-any.whl' and adding 'build/bdist.linux-x86_64/wheel' to it
       > adding 'factory/__main__.py'
       > adding 'factory/gruvbox-mix.txt'
       > adding 'factory/gruvbox-pink.txt'
       > adding 'factory/gruvbox-white.txt'
       > adding 'gruvbox_factory-2.0.0.dist-info/LICENSE'
       > adding 'gruvbox_factory-2.0.0.dist-info/METADATA'
       > adding 'gruvbox_factory-2.0.0.dist-info/WHEEL'
       > adding 'gruvbox_factory-2.0.0.dist-info/entry_points.txt'
       > adding 'gruvbox_factory-2.0.0.dist-info/top_level.txt'
       > adding 'gruvbox_factory-2.0.0.dist-info/RECORD'
       > removing build/bdist.linux-x86_64/wheel
       > Successfully built gruvbox_factory-2.0.0-py3-none-any.whl
       > Finished creating a wheel...
       > Finished executing pypaBuildPhase
       > Running phase: pythonRuntimeDepsCheckHook
       > Executing pythonRuntimeDepsCheck
       > Checking runtime dependencies for gruvbox_factory-2.0.0-py3-none-any.whl
       >   - numpy==2.2.2 not satisfied by version 2.2.3
       >   - setuptools==75.8.0 not satisfied by version 75.8.2.post0
       For full logs, run 'nix log /nix/store/l576pwlj50bhngb87fk8qdrm2aazzffs-gruvbox-factory-2.0.0.drv'.
error: 1 dependencies of derivation '/nix/store/10wqs24cswkfzqgsshgax6x6p16clm5p-nix-shell-env.drv' failed to build

Debugging Process

I added the following code to patch the version for the affected dependencies in my default.nix file:

postPatch = ''
  substituteInPlace pyproject.toml \
    --replace 'numpy == 2.2.2' 'numpy >= 2.2.2' \
    --replace 'setuptools == 75.8.0' 'setuptools >= 75.8.0'
'';

This code checks the pyproject.toml file for the package versions and updates them to accept any version higher than the specified version.

Running nix develop -c $SHELL again produced the same error. I checked the pyproject.toml file to verify dependencies and their location, confirming it was in the root directory as expected.

Upon reviewing the default.nix file again, I noticed an issue with the postPatch code. The original pyproject.toml had the dependencies written without spaces:

"numpy==2.2.2",
"setuptools==75.8.0",

But my patch code had spaces:

"numpy == 2.2.2",
"setuptools == 75.8.0",

After fixing the spacing, I ran nix develop again but encountered a new error message complaining that it couldn't find the module 'gruvbox-factory' during the pythonImportsCheckPhase.

nix develop -c $SHELL
error: builder for '/nix/store/w9wfy7wp88mr8grz8vgmcdbdfqmv9hfj-gruvbox-factory-2.0.0.drv' failed with exit code 1;
       last 25 log lines:
       > stripping (with command strip and flags -S -p) in  /nix/store/8v353k03iyxfkp0hlclidzh5ywzzys5j-gruvbox-factory-2.0.0/lib/nix/store/8v353k03iyxfkp0hlclidzh5ywzzys5j-gruvbox-factory-2.0.0/bin
       > shrinking RPATHs of ELF executables and libraries in /nix/store/xdxwy3ajnwyqpllkizb3wzga6vnpg3w4-gruvbox-factory-2.0.0-dist
       > checking for references to /build/ in /nix/store/xdxwy3ajnwyqpllkizb3wzga6vnpg3w4-gruvbox-factory-2.0.0-dist...
       > patching script interpreter paths in /nix/store/xdxwy3ajnwyqpllkizb3wzga6vnpg3w4-gruvbox-factory-2.0.0-dist
       > Rewriting #!/nix/store/f2krmq3iv5nibcvn4rw7nrnrciqprdkh-python3-3.12.9/bin/python3.12 to #!/nix/store/f2krmq3iv5nibcvn4rw7nrnrciqprdkh-python3-3.12.9
       > wrapping `/nix/store/8v353k03iyxfkp0hlclidzh5ywzzys5j-gruvbox-factory-2.0.0/bin/gruvbox-factory'...
       > Executing pythonRemoveTestsDir
       > Finished executing pythonRemoveTestsDir
       > Running phase: installCheckPhase
       > no Makefile or custom installCheckPhase, doing nothing
       > Running phase: pythonCatchConflictsPhase
       > Running phase: pythonRemoveBinBytecodePhase
       > Running phase: pythonImportsCheckPhase
       > Executing pythonImportsCheckPhase
       > Check whether the following modules can be imported: gruvbox-factory
       > Traceback (most recent call last):
       >   File "<string>", line 1, in <module>
       >   File "<string>", line 1, in <lambda>
       >   File "/nix/store/f2krmq3iv5nibcvn4rw7nrnrciqprdkh-python3-3.12.9/lib/python3.12/importlib/__init__.py", line 90, in import_module
       >     return _bootstrap._gcd_import(name[level:], package, level)
       >            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
       >   File "<frozen importlib._bootstrap>", line 1387, in _gcd_import
       >   File "<frozen importlib._bootstrap>", line 1360, in _find_and_load
       >   File "<frozen importlib._bootstrap>", line 1324, in _find_and_load_unlocked
       > ModuleNotFoundError: No module named 'gruvbox-factory'
       For full logs, run 'nix log /nix/store/w9wfy7wp88mr8grz8vgmcdbdfqmv9hfj-gruvbox-factory-2.0.0.drv'.
error: 1 dependencies of derivation '/nix/store/i8rvnijpg9b9vg9z7czds5h5rqwmzacp-nix-shell-env.drv' failed to build

The Nix logs can be difficult to parse, but in this case the error was clear: when trying to develop the package, Nix could not find the module named gruvbox-factory. This occurred during the pythonImportCheckPhase. Upon checking my default.nix file, I noticed the pythonImportsCheck was configured to look for "gruvbox_factory" as the module name.

     > wrapping `/nix/store/8v353k03iyxfkp0hlclidzh5ywzzys5j-gruvbox-factory-2.0.0/bin/gruvbox-factory'...
       > Executing pythonRemoveTestsDir
       > Finished executing pythonRemoveTestsDir
       > Running phase: installCheckPhase
       > no Makefile or custom installCheckPhase, doing nothing
       > Running phase: pythonCatchConflictsPhase
       > Running phase: pythonRemoveBinBytecodePhase
       > Running phase: pythonImportsCheckPhase
       > Executing pythonImportsCheckPhase
       > Check whether the following modules can be imported: gruvbox-factory
       > Traceback (most recent call last):
       >   File "<string>", line 1, in <module>
       >   File "<string>", line 1, in <lambda>
       >   File "/nix/store/f2krmq3iv5nibcvn4rw7nrnrciqprdkh-python3-3.12.9/lib/python3.12/importlib/__init__.py", line 90, in import_module

  pythonImportsCheck = [
    "gruvbox-factory"
  ];

Initially, I assumed the module name would match the package name ("gruvbox-factory"), since that seemed logical. However, upon checking the pyproject.toml file when the error occurred, I discovered that the actual module name defined in the setuptools configuration was different. The package used a different module name internally than what was exposed in the package name.

Checking the pyproject.toml revealed the actual module name:

[tool.setuptools.packages.find]
include = ["factory"]

I updated the pythonImportsCheck in default.nix accordingly:

pythonImportsCheck = [
    "factory"  # Changed from "gruvbox-factory"
];

After this change, running nix develop succeeded. I proceeded to run nix build to create the package and make it accessible in my shell.

Building the Package

nix build \
  --impure --expr \
  'let pkgs = import <nixpkgs> { }; in pkgs.callPackage ./default.nix {}'

Successful Build Result

~/Documents/01_Project/Builds/default  ls
.rw-r--r-- 1.2k thein3rovert 12 Apr 11:45  default.nix
.rw-r--r-- 1.0k thein3rovert 12 Apr 11:17  flake.lock
.rw-r--r--  586 thein3rovert 12 Apr 11:10  flake.nix
lrwxrwxrwx    - thein3rovert 12 Apr 11:48  result -> /nix/store/1wjcirbfks8xp2svp4qd9q2snq4j1j7i-gruvbox-factory-2.0.0

Testing the Package

~/Documents/01_Project/Builds/default  gruvbox-factory
usage: gruvbox-factory [-h] [-p [{white,pink,mix}]] [-i IMAGES [IMAGES ...]]
A simple cli to manufacture Gruvbox themed wallpapers.
options:
  -h, --help            show this help message and exit
  -p [{white,pink,mix}], --palette [{white,pink,mix}]
                        choose your palette, panther 'pink' (default), snoopy 'white' or smooth 'mix'
  -i IMAGES [IMAGES ...], --images IMAGES [IMAGES ...]
                        path(s) to the image(s).

Note: This is only available through the shell when I exit the shell the built package will not be available. While I didn't try other options to fix the issue with the dependencies, I might try the options some other time when I run into similar issues regarding dependencies and I will be sure to make a blog about how I used it so stay tuned... and have a great day.

Resources

https://tech.aufomm.com/my-nix-journey-how-to-use-nix-to-set-up-dev-environment/
https://github.com/paulopacitti/gruvbox-factory

No Space Left on Device

Mon, 12 Aug 2024 00:00:00 GMT

Recently, I encountered a "No space left on device" error while trying to install IntelliJ on my NixOS system. Despite having 70 GB of available space, the issue persisted. As a newcomer to NixOS, dual-booting with Windows, I was puzzled by this problem.

Understanding the Issue:
The error wasn't due to a lack of total disk space but was likely related to the temporary directory (/tmp) or the Nix store (/nix/store) running out of space. This is a common issue in NixOS, especially with large package installations. I suspected the Nix store was full, so I tried the following commands to free up space:

nix store --optimize
nix store --gc

Unfortunately, these didn't resolve the issue.
I turned to Reddit and other online resources, hoping to find others who faced similar issues. However, documentation was sparse, and solutions were not clearly explained.
Solutions Tried:
Here are some options I explored:

Checking /tmp Directory: Ensured it wasn't full.
Increasing Nix Store Size: Considered adjusting the Nix store size.
Clearing Cache: Attempted to clear any unnecessary cache files.
Increase the tmpfs size: You can try increasing the tmpfs size by adding the following line to your /etc/nixos/configuration.nix file:

boot.runSize = "10G";  # adjust the size as needed

Then, restart your system and try installing the package again.

Use a larger swap partition: If you have a swap partition, ensure it's large enough to accommodate the temporary build process. You can check the current swap size using swapon -s.
Mount the Nix store with a larger size: You can remount the Nix store with a larger size using the following command:

mount -o remount,size=10G,noatime /nix/.rw-store

Adjust the size as needed.

Clear temporary files: Try clearing temporary files and directories, including /tmp and /var/tmp, to free up space.

None of those solution seem to solve the problem i was having each time i build a package I keep getting the no space left on device error. Then i came across a blog post that solve the issue i was having.
Solutions Explored:

Increase tmpfs Size:
- Explanation: tmpfs stores files in volatile memory. Increasing its size allows more files to be stored in memory.
- How to Apply:
  - Add the following line to /etc/nixos/configuration.nix:
```
boot.tmpfsSize = "4G";  # Adjust this size as needed
```
  - Apply the changes with:
```
sudo nixos-rebuild switch
```
- Consideration: Ensure enough free RAM or swap to support the increased size.
Increase Swap Space:
- Explanation: Swap space acts as overflow memory when RAM is full, supporting resource-heavy operations.
Check Temporary File Storage:
- Use the following command to check current tmpfs usage:
```
df -h | grep tmpfs
```
- If low, increase /tmp size by setting boot.tmpfsSize in the NixOS configuration.

Conclusion:
After adjusting the tmpfs size, the error was resolved. This experience taught me valuable lessons about managing disk space on NixOS, and I hope it helps others facing similar issues.

Resources

https://nixos.wiki/wiki/Storage_optimization

ddutils on Nixos

Sun, 04 Aug 2024 00:00:00 GMT

Installation and Configuration

Search nix search for ddcutil package or simple add this command to your nix-configuration pkg config.

 environment.systemPackages = with pkgs; [
	ddcutil
];

Add it to configuration.nix and sudo rebuild

sudo rebuild switch

Verify it its installed by running ddcutil detect command, if you get an error like unable to find /ddc/dev/12c. directory.

sudo ddcutil detect

You should get something like this:

   I2C bus:  /dev/i2c-4
   DRM connector:           card1-HDMI-A-1
   EDID synopsis:
      Mfg id:               SEM - Samsung Electronics Company Ltd
      Model:                DM700A-H
      Product code:         804  (0x0324)
      Serial number:
      Binary serial number: 0 (0x00000000)
      Manufacture year:     2012,  Week: 0

Invalid display
   I2C bus:  /dev/i2c-12
   DRM connector:           card1-eDP-1
   EDID synopsis:
      Mfg id:               BOE - BOE
      Model:
      Product code:         2449  (0x0991)
      Serial number:
      Binary serial number: 0 (0x00000000)
      Manufacture year:     2020,  Week: 33
   This is a laptop display.  Laptop displays support DDC/CI

If you get that error that says you dont have the i2c kernel modules ,we need to load it manually by using the following command

sudo modprobe i2c-dev

you should get an i2c kernel modules 1 - 16 .

You can verify your i2c by usng this command this will list all the i2c needed.

`lc /dev/12c-*`

Then run the i2c detect again, you should get information about all the monitor you're connected to.

Before setting the brightness, make sure that you know the current brightness you are currently i so make sure you run the command below, this will show you the current brightness if your monitors.

sudo ddcutil getvpc 10`

After that then try increase and decrease the brightness by running the

sudo ddcutil setvcp 10 +100 #Higher number

for increased brightness.

Then

sudo ddcutil setvcp 10 +10 # lower number

or increase brightness.

You can also verify if your monitor supports brightness control by running the

sudo ddcutil capabilities | grep "Feature: 10"

The next thing to DO is to create a udev rules, this gives i2c groups the read and writer permissions so non-root users can access and control the I2C devices and using the tools like ddcutil without having to use sudo everytime. We can do that by using this command.

sudo cp /usr/share/ddcutil/data/60-ddcutil-i2c.rules /etc/udev/rules.d

If you encounter an error in this process it because nixos has a different way of handling file systems and package management so we need to find the share directory. Basically it cannot find the share folder that contains the data we want to copy so we have to find the share folder. After a successful research..ha foufn out the if the share folder is not in the /usr/share/ then it can be found in the /run/current-system/sw/share/ddcutil son then we can run this command again with the correct path.

sudo cp /run/current-system/sw/share/ddcutil/data/60-ddcutil-i2c.rules /etc/udev/rules.d

On other linux distro this approach will work but as we all know as a nix user every thing got to be declarative so what we will have to do in other to solve the error.

sudo cp /run/current-system/sw/share/ddcutil/data/60-ddcutil-i2c.rules /etc/udev/rules.d
cp: cannot create regular file '/etc/udev/rules.d/60-ddcutil-i2c.rules': Read-only file system

We need to add the following line to our configuration.nix files.

services.udev.packages = [ (pkgs.runCommand "custom-udev-rules" { buildInputs = [ pkgs.coreutils ]; } '' mkdir -p $out/lib/udev/rules.d cp ${pkgs.ddcutil}/share/ddcutil/data/60-ddcutil-i2c.rules $out/lib/udev/rules.d/ '') ];

This will add the 60-ddcutil-i2c.rules directly to our udev rule to your NixOS system.
After doing that save the changes and run the following command:

sudo nixos-rebuild switch

After rebuilding in other to apply the changes we need to reboot our system but there is a better way to reload the i2c without rebooting out system.

sudo groupadd --system i2c

sudo usermod $USER -aG i2c

You might be wondering why its important to creating i2c group or groups in general, this is because creating groups are important steps that should be taken for managing permissions perfectly on devices and their resources. In relation to the i2c, some devices require group permission in other to access i2c devices, ddcutil
needed access to i/dev/i2c-* devices in other to interact with monitor settings.

Now that we have created a group for ic2 we need to verify the group we can do that use the command:

groups $USER

You can also check the i2c group file to see if the user is listed in the group:

grep i2c /etc/group

You should get a result like this:

i2c:x:544:$USER

Next we need to also make sure we can load the i2c-dev automatically, we can do that using this command:

sudo touch /etc/modules-load.d/i2c.conf

sudo sh -c 'echo "i2c-dev" >> /etc/modules-load.d/i2c.conf'

Then we reboot for the changes to take full effect

sudo reboot

Resources

https://www.ddcutil.com/i2c_permissions_using_group_i2c/
https://discourse.nixos.org/t/proper-way-to-access-share-folder/20495
https://github.com/daitj/gnome-display-brightness-ddcutil/blob/master/README.md
https://search.nixos.org/packages?channel=24.05&show=gnomeExtensions.brightness-control-using-ddcutil&from=0&size=50&sort=relevance&type=packages&query=ddcutil
https://github.com/NixOS/nixpkgs/issues/292049