Nixpkgs is massive with the largest, most up-to-date collection of Nix packages, powering reproducible systems and forming the backbone of many projects. But there's a problem: Nix packages' license metadata is a mess.
Nix's license tracking uses a custom license ID system that doesn't match the best practice of using SPDX license expressions standards, inconsistently referencing SPDX or ScanCode LicenseDB. The metadata often falls out of sync with the actual code or misrepresents what's really licensed, and packagers typically only check the top-level declared license and skip the file-level details where the real complexity hides. For an ecosystem built on correctness and reproducibility, this is a gap we need to close.
Nixpkgs Clarity fixes this with state-of-the-art automated license detection. We're correcting and standardizing license metadata across the entire Nixpkgs collection, aligning with SPDX best practices, and making sure what we declare actually matches what's in the code. This matters because accurate license data is critical for software supply chain security, CRA compliance, and anyone who needs to responsibly reuse Nixpkgs packages in production.
This talk shows how we're detecting and correcting license metadata across Nixpkgs, and what changes when you finally have accurate license data. We'll share how we are tackling the unique challenges of Nixpkgs at scale, with tens of thousands of packages, Nix's functional approach to package definitions, and automated detection in a way that maintainers can trust and verify.
If you care about making Nixpkgs even more reliable and supply chain ready, come see how we're bringing Nix's correctness principles to Nix packages' license metadata.
Since 2015, IndieHosters has specialized in hosting and making accessible free software as a service, from blogs and forums to wikis and online collaboration tools, with a core mission to enable people and organizations to always keep control over their data and privacy in order to achieve data sovereignty.
To support this mission, we created libre.sh, a framework of tools that enables us to host free software at scale. It has evolved quite a bit since our initial talk at FOSDEM 2017. We progressively changed many of the tools and software we have been using, for instance, transitionning from Docker Compose to kubernetes. In more recent time, we are progressively using Nix and NixOS in various part of our work. In this talk, we wish to show what this change actually looks like in our processes.
As a demonstration, we are gonna deploy an instance of LaSuite.coop, a fully-fledged application suite, starting from a fresh environment. Along the way we'll cover how our provisionning is done with nixos-anywhere and disko, how declarative Nix environments impacted our workflow, how we build reproducible container images using Nix, and more. Basically, if it uses Nix at IndieHosters, we will discuss it! We can't wait to discuss, share our experiences with the Nix community and receive valuable feedback from you!
Our digital lives are increasingly fragmented across numerous centralised online services. This model concentrates power, leaving us with minimal technical control over our personal data and online identities. The long-term permanence of these platforms is uncertain, and their commercial incentives are often misaligned with user interests. We propose inverting this model: instead of centralising our data in proprietary silos, let’s centralise our presence under our own control using open, federated services. We introduce the concept of ‘digital islands’, or Eileans – self-hosted hubs for an individual’s or community’s online presence. By hosting services ourselves, we regain autonomy and control. Eilean is a project designed to simplify the creation and management of these digital islands. The core idea is to parameterise a complete operating system deployment by a domain name and a desired set of services. This allows users to easily deploy their own instances of federated services like Matrix, Mastodon, and E-Mail. We utilise NixOS to enable declarative, reproducible configuration and deployment of these services. This provides strong guarantees about the system’s state.
https://github.com/RyanGibb/eilean-nix
With TAPPaaS we are building a small, composable private cloud for homes, communities and small organisations. It should feel like an enterprise‑grade packaged solution, but be built fully with FOSS and declarative Nix/NixOS tooling. Our current design is a 2‑node cluster with a third backup node, using Proxmox as cluster manager, NixOS and flakes for all VMs running platform services. All changes go through GitOps workflows, and services are packaged as NixOS modules that share central identity, secrets, backup and monitoring. We will show the architecture, NixOS/Flake deployment structure and CI/CD pipeline, and how declarative configuration helps with upgrades, failures and restores. This talk is for Nix/NixOS users and operators who want to turn homelab ideas into robust platforms for real organisations. We will share what works and where we struggle, and invite experienced nixers to challenge our choices and point us to patterns and tools we should adopt.
Reproducibility remains one of the largest challenges in benchmarking distributed systems, especially when hardware, kernel settings, and dependency versions vary between tests. This talk presents a NixOS-based approach for constructing deterministic, portable benchmark environments for large-scale data infrastructure. We show how Nix’s declarative system configuration, content-addressed builds, and reproducible packaging model allow engineers to isolate performance variables and eliminate configuration drift entirely. Using Apache Cassandra as the primary case study, the talk demonstrates how NixOS can define and reproduce complete cluster environments—from OS images to JVM parameters and custom benchmarking tools—across both cloud and on-prem setups. Attendees will learn practical patterns for packaging workloads, pinning dependencies, and generating ephemeral benchmark nodes. The session concludes with a discussion of how Nix abstractions can support multi-architecture testing, including cross-compiling workloads for ARM and RISC targets, enabling more transparent and repeatable performance comparisons.
NixOS reproducibility monitoring has historically been limited to the ISO images we ship, because they are a package set small enough to be rebuilt on a single machine. In this talk, we introduce LILA, a decentralized reproducibility monitoring infrastructure for the NixOS community, aimed at removing this limit and allowing a collaborative monitoring of the entirety of nixpkgs!
The OCaml language package manager, Opam, has support for interfacing with system package mangers to provide dependencies external to the language. Supporting Nix required re-thinking the abstractions used to interface with traditional package managers, but enables using Opam for development easy whilst benefitting from Nix's reproducible system dependencies. This provides one example of how Nix interfaces with other software development and deployment technologies.
All the big cloud providers provide your machines with a unique cryptographic identity that can be used to talk to their cloud services securely without having to manage or rotate any cryptographic secrets yourself. For example GCP has Service accounts and AWS has IAM roles. This ubiquity of cloud identity and the seamless integration with all the the services of these cloud providers is one of the reasons why they are so successful.
SPIFFE (Secure Production Identity Framework For Everyone) tries to unify these concepts of workload identity in a vendor neutral framework. But how do we bootstrap our cryptographic identity securely when we are running things on our own hardware as opposed to on cloud? What is our bottom turtle?
In this talk, I will show how I use Nix OSin combination with the swiss-army knife of tools provided by systemd (ukify, systemd-measure, systemd-repart, systemd-veritysetup-generator) to create reproducible images for which we can predict TPM measurements.
Paired with a custom attestation plugin for SPIRE (the reference CA server for SPIFFE) that uses TPM remote attestation I can give each of my servers a unique identity encoded in a TLS certificate if and only if they were booted up with the software that I intended them to boot up with.
This then allows me to have workloads talk to each other with mutual TLS without having to manage any keys or certificates myself.
Have you ever felt the need for a virtual machine in your NixOS server environment? Maybe the functionality you want is not available in NixOS? Maybe there’s a custom OS image for a service you want to provide? Maybe you just want to securely isolate your workload? NixOS promises reproducible and declarative systems, but for VMs it just wasn’t there yet. To close this gap we built the ctrl-os.vms NixOS module, a solution to define generic virtual machines directly in your NixOS configuration. It works just like virtualisation.oci-containers, but for VMs instead of containers. 20 lines of Nix make it possible to run any Linux distribution you want as a VM on your NixOS host. To put a cherry on top you can use cloud-init, from our NixOS configuration to configure your guests declaratively, too!
ctrl-os.vms is part of the ctrl-os-modules repository.
I'll present my story of building a machine-readable inventory of computing equipment of my employer. It collects information such as: “This computer is located in this room with this network configuration, these software requirements and is connected to this port of this switch” so that I can easily develop scripts that configure the machine, the switch, monitoring of both and many other things including a physical map.
I went through many iterations of this project–codenamed AR–and settled on NixOS modules for their balance between how easy it is to write new records and how easy it is to use them. Let me share the joy it brought to my job and present curated code snippets so you can build your own inventory with ease.
Nix and Nixpkgs are gaining ever-broader adoption at the same time that SBOMs (Software Bills of Materials) are emerging as a standard format for demonstrating provenance. This talk will argue that bridging the gap is imperative for the Nix ecosystem, illustrate a fleshed-out approach to SBOM generation. This will suggest some improvements to Nixpkgs that I believe could unlock further progress.
Nixss (pronounced "nix" like you're a snake) is a Nix library for making static sites. It's not a static site generator, rather, it provides tools to build your own. Nixss comes with several pre-processors and combinators that will turn whatever files you throw at it into a tree of Nix derivations, which builds into a static site. It also has its own Nix-based templating system, if you'd rather not use more conventional ones.
NixOS, with its ability to centrally manage multiple devices, is an ideal way to maintain a network infrastructure that consists of multiple devices (routers, switches, access points). This presentation will provide an overview of how NixOS can be utilized on routers. This will include configuration based on systemd-networkd for routing and switching, as well as hostapd for Wi-Fi. It aims to provide you with tips on setting up your network infrastructure on NixOS itself.
My personal NixOS configuration with three different home networks backed by NixOS: https://gitlab.com/Cynerd/nixos-personal/
Project providing support for running NixOS on Turris routers: https://gitlab.com/Cynerd/nixturris/
Introducing sphinxcontrib-nixdomain! A plugin for the Sphinx documentation generator that takes your Nix code, and generates documentation for NixOS options, Nix packages, and Nix functions.
This talk shows how to setup Sphinx and sphinxcontrib-nixdomain for your project, how to generate documentation for Nix objects, and how to add cross-references to those Nix objects.
We'll also go into some documentation architecture best practices and personal advice, to hopefully make your documentation easy to use, browse, and understand.
Resources:
sphinxcontrib-nixdomain documentationsphinxcontrib-nixdomain source codesphinxcontrib-nixdomainNima, the Nix Manipulator, is a new Python library and collection of tools for parsing, manipulating and reconstructing Nix source code.
This presentation will introduce the project, its original goals, key features, and practical applications. It will explore the tradeoffs and decisions made during development and demonstrate how to use its various features.
Started during SaltSprint 2025, Nima aims to fill the absence of tools for easily updating and editing Nix code. Popular tools such as nix-update rely on simple string replacement or regular expressions for updating Nix code.
Eccentric formatting that does not respect RFC-166 and would add unnecessary complexity may not be preserved.
Nima builds on tree‑sitter, a multilingual concrete‑syntax AST, with the tree‑sitter‑nix grammar providing lossless parsing of Nix files.
The project is still in early‑stage:
Source: https://github.com/hoh/nix-manipulator Announcement: https://discourse.nixos.org/t/announcing-nix-manipulator-nima-structured-edits-for-nix-that-keep-formatting/68513/11
Nix Forge is an attempt to lower the barrier and learning curve required for packaging and deploying software with Nix, enforce best practices and unlock the superpowers of Nix.
By providing a human-readable packaging recipe format (inspired by conda-forge), Nix Forge abstracts away the need for advanced Nix packaging knowledge and experience without sacrificing its powers. Users can define packages and multi-component applications running in shell environments, containers, or inside a NixOS system using simple declarative configurations instead of writing Nix expressions. The NixOS-style module system guides users through the packaging process, enforces best practices, and provides type checking for recipes—ensuring quality and correctness from the start. On the other hand, the web user interface provides an attractive catalog of packages and applications with copy-paste instructions for end users.
This presentation will demonstrate how this approach significantly benefits developers in the era of LLMs. With its simplified, structured format, LLMs can now effectively help users create and modify Nix packages—a task that previously required deep Nix expertise. The human-readable recipes allow developers to easily verify LLM-generated configurations, while built-in type checking enforces correctness automatically.
Source code - https://github.com/imincik/nix-forge Web UI - https://imincik.github.io/nix-forge
This talk details our personal journey of creating a setup for video streaming at conferences, called mixos. We explain the challenges we faced and how Nix and NixOS helped us get the work done in a robust and efficient way. We do not consider ourselves extremely proficient in Nix, so any feedback from the community would be greatly appreciated.
In addition, we (as part of the FOSDEM video team) demonstrate how the same Nix-based setup can run on a FOSDEM video box.
Debugging Nix can be frustrating: poor error reporting, non-incremental builds, and cryptic stack traces make fixing a derivation a pain. This talk presents practical tools and techniques to make working with Nix expressions and builds more fun. A significant portion of this talk is a live coding demo, targeted at somewhat beginner-intermediate Nix users.