# Nix Nix is a functional package manager and system-configuration tool for reproducible, declarative builds and development environments. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Cargo-dyndrv: A new way of building Cargo packages with Nix DevFeed: [Cargo-dyndrv: A new way of building Cargo packages with Nix]() Original publisher: [Read original article]() Author: Ericson2314 Published: 2026-09-16T20:13:36Z Content type: article Language: en Sources: [Announcements - NixOS Discourse]() Topics: [Nix](), [Rust](), [systems]() Tags: [announcements](), [blog-post](), [declarative](), [rust]() ### AI overview The article introduces cargo-dyndrv, a new way to build Cargo projects with Nix. It uses dynamic derivations for per-crate incrementality and Cargo's unit graph to align operations with Cargo, while trading some flexibility for fidelity and forward compatibility. ### Source excerpt Obsidian Systems - 16 Sep 26 cargo-dyndrv: A Beginning Building Rust within Nix has always been somewhat of an annoying problem. Nixpkgs includes tools like buildRustCrate to build a single crate and buildRustPackage to build an entire project with all its dependencies, but both have substantial issues:... We have a new way way of building Cargo projects! As the blog post describes, what distinguishes this from all the other ways of building Cargo project in Nix is this combination of methods: Uses dynamic derivations, so no eval time penalty for per-crate incrementality Uses Cargo's unit graph, so we automatically match to how Cargo performs operations Both cargo-dyndrv itself and this blog post about it are all @artemist's work; I am only the one posting it because she has already left for NixCon (see you all there!) and I haven't left yet, so my internet connection is better. Finally, thank you for Saronic for collaborating with us on this project. 6 posts - 5 participants Read full topic ## Any Nix package, live in your browser DevFeed: [Any Nix package, live in your browser]() Original publisher: [Read original article]() Author: Simon Willison Published: 2026-09-10T23:44:15Z Content type: article Language: en Sources: [Simon Willison's Weblog]() Topics: [Nix](), [WebAssembly](), [qemu](), [x86](), [GitHub Actions](), [Pull Request]() Tags: [browser](), [code-review](), [code-review-16](), [github-actions](), [github-actions-72](), [linux](), [linux-54](), [qemu](), [webassembly](), [webassembly-131](), [x86]() ### AI overview The article describes trynix.dev, which runs an x86_64 Linux virtual machine in the browser using qemu-wasm and WebAssembly. It can boot Nix packages from the past 13 years, including Python 3.6.2, and supports URL-addressable interactive shells. It also highlights trynix-preview, a GitHub Action that links pull requests to browser-based builds without servers. ### Source excerpt Any Nix package, live in your browser Farid Zakaria calls this his "magnum opus of Nix work", and I can see why. trynix.dev provides a qemu-wasm powered x86_64 Linux virtual machine running entirely in your browser through WebAssembly. That VM can then be booted with any Nix package from the past 13 years. They are URL addressable, so you can navigate to this page: https://trynix.dev/?pkg=python3%403.6.2 Then click "Load" and get an interactive shell against a virtual machine running Python 3.6.2 from 2017. Farid is building all sorts of neat things on top of this. One recent example: Review a pull request by booting it introduces trynix-preview, described like this: GitHub action that comments a link on a pull request which lets you boot the PR's build in the browser using https://trynix.dev. No servers, just browsers. Via Lobste.rs Tags: code-review, linux, webassembly, github-actions ## Devenv 2.3: Portless and TUI configuration DevFeed: [Devenv 2.3: Portless and TUI configuration]() Original publisher: [Read original article]() Author: domenkozar Published: 2026-09-07T13:59:38Z Content type: release Language: en Sources: [Announcements - NixOS Discourse]() Topics: [Nix](), [Pingora](), [Text-based user interface](), [proxy](), [Processes](), [configuration]() Tags: [announcements](), [configuration](), [docker](), [llms](), [localhost](), [open](), [pingora](), [processes](), [proxy](), [python]() ### AI overview Devenv 2.3 introduces an opt-in localhost proxy using Pingora for stable process URLs, configurable TUI settings, a dotenv parser, improved process cleanup, credential helpers in SecretSpec 0.20, and a smaller devenv closure. ### Source excerpt The new opt-in localhost proxy (using Pingora) gives your processes stable URLs, even when automatic port allocation changes the underlying port: { pkgs, config, ... }: { process.proxy.enable = true; processes.web = { exec = "${pkgs.python3}/bin/python -m http.server $PORT"; ports.http.allocate = 8000; env.PORT = builtins.toString config.processes.web.ports.http.value; }; } Run devenv up and open http://web..localhost. You can override hostnames per process or port and enable HTTPS per process. The TUI now has a personal configuration file for statusline placement, colors, keybindings, and log behavior. You can also hide the statusline or disable the (devenv) prompt prefix. Other highlights: multiverse.pins resolves multiple package versions through the fewest nixpkgs revisions. A new dotenv parser supports quotes, multiline values, variable substitution, and ordered files. SecretSpec 0.20 adds Git and Docker credential helpers and five new providers. Process shutdown and cleanup are more reliable. The devenv closure shrank from 528 MB to 376 MB. nixpkgs PR devenv devenv 2.3: Portless and TUI configuration Fast, Declarative, Reproducible, and Composable Developer Environments using Nix. LLMs have been used 1 post - 1 participant Read full topic ## Secretspec 0.20 DevFeed: [Secretspec 0.20]() Original publisher: [Read original article]() Author: domenkozar Published: 2026-08-31T19:28:39Z Content type: release Language: en Sources: [Announcements - NixOS Discourse]() Topics: [Nix](), [Git](), [Docker]() Tags: [announcements](), [dependencies](), [docker](), [git](), [refactoring](), [security](), [split]() ### AI overview SecretSpec 0.20 was released with five new providers, Git and Docker credential helpers, planned resolver IPC for Nix without introducing new dependencies, and separated secrets-handling refactoring in Nix. ### Source excerpt We've released secretspec 0.20, which includes 5 new providers, git and Docker credential helpers. Most importantly we're working towards releasing resolver IPC that Nix will be able to use without introducing new dependencies, which was the main review objection to existing PR. We've also split out secrets handling refactoring in Nix (PR). Disclaimer: LLMs have been used 5 posts - 2 participants Read full topic ## AWS Extends NixOS Infrastructure Credits for 2026-27 DevFeed: [AWS Extends NixOS Infrastructure Credits for 2026-27]() Original publisher: [Read original article]() Author: ron Published: 2026-08-24T16:22:07Z Content type: news Language: en Sources: [Announcements - NixOS Discourse]() Topics: [Amazon Web Services](), [Nix](), [Resilience](), [Amazon S3]() Tags: [announcements](), [aws](), [partnership](), [resilience](), [s3]() ### AI overview AWS has committed $20,000 per month in credits for 2026-27 to support cache.nixos.org and releases.nixos.org. The announcement describes this as a continuation of a multi-year partnership with the NixOS Foundation and Community. ### Source excerpt Happy Monday, and hopefully a good 4 weeks before NixCon week to everyone! Some very good news for us today. AWS has committed the next chapter of its support for the NixOS Foundation & Community: $20,000 per month in AWS credits for the 2026-27 period, nearly a quarter of a million dollars, to help keep cache.nixos.org and releases.nixos.org running. A few years ago, this partnership started as an urgent effort to close an immediate infrastructure funding gap. Today, it has grown into a durable multi-year partnership, with AWS making its largest financial commitment to date. Huge thank you to the AWS Open Source and Open Data teams, the Nix Infra team, and everyone who shared their Nix + AWS stories with us over the last few months (y'all know who you are!). Your experiences genuinely helped us make the case. Some of your stories appeared in the initial thread and a lot more came in via DMs! Looking for Nix + AWS usage stories We still have important work ahead on cost efficiency, resilience, and the long-term sustainability of this infrastructure. Lots of progress has been made by the infra team over the last 12 months! More to come here as well! Steve (Staff Writer @ Flox) has been volunteering with the Infra & AWS teams and will publish a much deeper blog very soon covering the scale, technical work, and what comes next. I don't want to steal his thunder, so more on that shortly. For now: big heart to everyone who helped get this over the line. Lots of Nixy Love, Ron & The Foundation Our incredible Infrastructure Team - @hexa @vcunat @jfly @arianvp @Mic92 @ra33it0 @Infinisil @ryantrinkle @lassulus @ethancedwards @bme 2 posts - 2 participants Read full topic ## Nixifest: Generate Kubernetes manifests from Nix DevFeed: [Nixifest: Generate Kubernetes manifests from Nix]() Original publisher: [Read original article]() Author: bitbloxhub Published: 2026-08-21T18:33:07Z Content type: article Language: en Sources: [Announcements - NixOS Discourse]() Topics: [Nix](), [Kubernetes](), [GitOps]() Tags: [announcements](), [gitops](), [kubernetes]() ### AI overview A Nixifest project announcement and discussion describes generating typed Kubernetes manifests with Nix. The supplied evidence highlights claimed CRD support improvements over Kubenix and independence from a single GitOps solution, while later posts discuss related Nix, Terraform, container, and evaluation-performance work. ### Source excerpt LLM DISCLOSURE: I used GPT-5.6-Luna in Pi for much of the code and documentation, and GPT-5.6-Sol via ChatGPT for much of the planning and help with some architecture decisions Nixifest Nixifest Typed Kubernetes manifests generated with Nix. Better CRD support than Kubenix. Not tied to a single GitOps solution like Nixidy. 15 posts - 6 participants Read full topic ## The New Default Nix Flake Template Explained DevFeed: [The New Default Nix Flake Template Explained]() Original publisher: [Read original article]() Author: Jacek Galowicz Published: 2026-08-17T00:00:00Z Content type: tutorial Language: en Sources: [Nixcademy Blog]() Topics: [Nix](), [Template](), [Development](), [Tooling]() Tags: [architecture](), [how-to](), [learn](), [packages](), [patterns](), [shell](), [standard](), [template]() ### AI overview An explanation of the new default Nix flake template, which supports multiple platforms without flake-utils. The article describes the underlying pattern, how to extend it for real projects, and its limitations and advanced cases. ### Source excerpt The default Nix flake template is now multi-platform without flake-utils. Learn how the new pattern works and how to extend it for real projects. ## Super-comma-nix: A Rust helper for Nix shell and run commands with sandboxing DevFeed: [Super-comma-nix: A Rust helper for Nix shell and run commands with sandboxing]() Original publisher: [Read original article]() Author: ksvivek Published: 2026-08-14T08:01:27Z Content type: article Language: en Sources: [Announcements - NixOS Discourse]() Topics: [Nix](), [Rust](), [Command-line interface](), [Shell](), [ci]() Tags: [announcements](), [ci](), [code](), [command](), [commands](), [config](), [dependencies](), [developer-experience](), [environments](), [integrations](), [runner](), [rust](), [shell]() ### AI overview Super-comma-nix is a Rust command-runner helper for Nix that shortens common nix shell, nix run, and version-checking commands. It integrates with nix-output-monitor and landrun, supports configurable environment variables, and can produce commands without running them. ### Source excerpt Hi All super-comma is an ultra-fast, zero-dependency Nix command runner helper written in Rust and powered directly by nixpkgs-multiverse. It is inspired by the project comma nix. But my project is loaded with batteries and much more DX(Developer eXperience). You'll love it. This project makes the consumption easier for nix shell, nix run commands and versions list all with simple handy commands like ,(nix run) ,s(nix shell) ,v(versions checking) . The project have some cool flags and also integrations like nix-output-monitor and landrun for sandboxing all with just few flags. Dont want to type these nom and sandboxing flags verbose? U can add it to env variable for session or globally as like config. Go read the README, you'll love it. Though plenty of features, I sticked to this principle: Simple by default and powerful when needed So learn as u go. Want more integrations? Please feel free to raise an issue Sandboxing is pretty cool, u want to try a software but dont want it to connect to inernet? This project enables some real adhoc shell environments and with the sandboxing etc figure out the possibilities for everyday usage, CI etc The project has zero dependencies for rust. Coz this project just makes u type short commands and the program just does some splitting and joining of strings. So please feel free to unslop some logic written by the LLM there if u think it can be simplified. Skeptic coz LLM(though it'll change in future)? just use the program with -o flag and u can just use the program to give you the final command without running. The Github README is carefully crafted to explain all the features, so take your time there. I'm a nix and nixos user since 2024, so I know some nix and the project design and integration of nom and landrun etc purely my design and idea and instructed the llm with my knowledge. But i'm not having good rust knowledge, so that part is covered by LLM. I wanted to write it with PF languages like haskell etc, but I wanted to qui ## 2.5x Faster x86\_64 Linux Builds on macOS with Rosetta DevFeed: [2.5x Faster x86\_64 Linux Builds on macOS with Rosetta]() Original publisher: [Read original article]() Author: Jacek Galowicz Published: 2026-08-10T00:00:00Z Content type: article Language: en Sources: [Nixcademy Blog]() Topics: [macOS](), [Nix](), [virtualization](), [qemu](), [x86](), [Linux]() Tags: [apple-silicon](), [install](), [macos](), [qemu](), [rosetta](), [run](), [virtualization](), [x86-64]() ### AI overview The article explains a new nix-darwin Linux builder backend that uses Apple's Virtualization.framework and exposes Rosetta to guest VMs. On Apple Silicon Macs, it supports x86_64 Linux builds and is reported to be roughly 2.5 times faster than QEMU-based emulation. ### Source excerpt Build x86_64 Linux packages 2.5x faster on your Apple Silicon Mac with the new Rosetta-based linux-builder, a drop-in replacement in nix-darwin. ## Nix-grove: Configuration framework for flake-parts DevFeed: [Nix-grove: Configuration framework for flake-parts]() Original publisher: [Read original article]() Author: bitbloxhub Published: 2026-08-08T18:32:05Z Content type: comparison Language: en Sources: [Announcements - NixOS Discourse]() Topics: [Nix](), [configuration](), [modules](), [Framework]() Tags: [announcements](), [configuration](), [framework](), [modules]() ### AI overview A forum discussion introduces Nix-grove, a configuration framework for flake-parts. It describes using the Nix module system to define typed classes and instances, project them into module systems, and override individual results instead of relying primarily on an import=enable pattern. ### Source excerpt AI USAGE: I used ChatGPT (GPT-5.6-Sol) to assist with design and planning, and Pi with GPT-5.6-Luna via openai-codex to help with implementation github.com GitHub - bitbloxhub/nix-grove: Configuration framework for flake-parts: define... Configuration framework for flake-parts: define typed classes and instances, project them into Nix module systems, and override individual results. Sort of an "alternative" to the Dendritic pattern. Still is about importing a bunch of flake-parts modules, but uses the module system for more, instead of import=enable. 6 posts - 3 participants Read full topic ## Dynamic Derivations + Dynamic build graphs: next steps DevFeed: [Dynamic Derivations + Dynamic build graphs: next steps]() Original publisher: [Read original article]() Author: tomberek Published: 2026-08-07T18:58:35Z Content type: opinion Language: en Sources: [Announcements - NixOS Discourse]() Topics: [Nix](), [build performance](), [systems](), [build times](), [bazel]() Tags: [announcements](), [bazel](), [build](), [ci](), [incremental](), [performant](), [ux]() ### AI overview A proposal for a Dynamic Derivations working group in the Nix ecosystem outlines collaboration goals, user-experience refinement, infrastructure needs, and adoption efforts. The post also summarizes the feature's development history and discusses potential benefits such as faster rebuilds and fine-grained incremental builds. ### Source excerpt After the long-history (see below) of Dynamic Derivations we are at a point where there are many groups exploring the feature and I am proposing a working group to: share the experiences of the implementors refine the user experience based on usage of the various PoCs determine infrastructure needs deduplicate work raise awareness build momentum for adoption ... anything else relevant I believe this feature has the potential to be a game-changer. Faster rebuilds, easier development, reduced pressure on CI systems, cacheable and alternative forms of instantiation, less need for "lang2nix", close the gap with Bazel, and fine-grained incremental builds. Along with the existing work on better schedulers, RBE-style remote builders, bytecode evaluation, parallel eval, memory optimizations (thanks @xokdvium !), and so much more - this is an exciting time for Nix and I can see DynDrvs as a way to fix some of the outstanding UX issues Nix has in day-to-day usage. There is even work to make IFD more performant, there is lots of design space to explore here. This should be a part of what Nix has to offer the world. @Ericson2314 has devoted years to this, and it deserves the payoff of becoming a mature feature. This is a call to action. Let's consider collaboration and a semimonthly meeting to at least say hello + consider next steps: Dynamic Derivations Working Group - Crab Fit History Dynamic Derivations have been in-progress for a long time. This has much of the history that I can put together. Let me know if this can be more complete. (and if anyone can help move/migrate into the wiki?) Build Systems à la Carte : 2018 RFC started Apr 2021 by @Ericson2314 and @L-as with [RFC 0092] Computed derivations by Ericson2314 - Pull Request #92 - NixOS/rfcs - GitHub (after reworking RFC 0040). Based on Initial example PoC by @L-as GitHub - L-as/nix-build.nix: nix-build.nix with RFC 92 - GitHub Content-addressed Nix Dec 2021: Implementing a content-addressed Nix by @thufschmitt. RFC Shep ## Substituter proxy \`selector4nix\` 0.9.0: various new features and optimizations DevFeed: [Substituter proxy \`selector4nix\` 0.9.0: various new features and optimizations]() Original publisher: [Read original article]() Author: oo-infty Published: 2026-08-06T14:36:51Z Content type: release Language: en Sources: [Announcements - NixOS Discourse]() Topics: [Nix](), [proxy](), [Caching](), [Latency](), [Streaming]() Tags: [announcements](), [caching](), [features](), [latency](), [network](), [proxy](), [releases]() ### AI overview A forum release announcement for selector4nix 0.9.0, a Nix substituter proxy with parallel cache queries and latency-aware selection. It describes private substituter support, persistent disk caching, a dashboard, and concurrent chunked NAR streaming to improve throughput on high-latency links. ### Source excerpt selector4nix is a Nix substituter proxy with parallel cache queries and latency-aware selection. The last time I shared this project in this forum was about 3 months ago. From then on, selector4nix has gained more features, improvements and optimizations. The notable features included in these new versions are: Private substituter support: Accessing private substituter servers is possible with additional credentials. AFAIK it worked well with Cachix, Garnix and attic. Persistent caching: NAR info and other queried data can be persisted to disk cache and then be retrieved again after the process restarts. Dashboard: It started from a minimal static page, and gradually evolved into its current form. Now it has several pages and shows each substituter's availability, statistics of the server's cache and storage, realtime information of NARs being trasferred currently, and so on. Chunked NAR streaming: Since selector4nix intercepts NAR requests, it can any optimization for its client transparently. the proxy tries to request multiple NAR chunks from the selected upstream substituter concurrently, and forwards chunks to clients. This feature helps improve the throughput on high-latency network links, which is especially useful for myself. etc. Compared to its alternative, ncro, selector4nix is not that popular, but I still gained supports from some of my friends and users of this project. I'm very appreciated of your acknowledgement. This is my first project that managed to address other people's real problems and made a difference, and I also learnt a lot when polishing it. I'll continue to work on selector4nix and enjoy getting involved in the Nix community. Please refer to the following links for more information: Homepage: https://github.com/StarryReverie/selector4nix/ v0.9.0 release: https://github.com/StarryReverie/selector4nix/releases/tag/v0.9.0 v0.9.0 changelog: https://github.com/StarryReverie/selector4nix/blob/8c28a663078b97eaa6c125f2c7db0d9e75b22311/CHANGELOG ## Ron Efroni on giving agents a deterministic place to run DevFeed: [Ron Efroni on giving agents a deterministic place to run]() Original publisher: [Read original article]() Author: WorkOS Published: 2026-08-05T23:26:44Z Content type: article Language: en Sources: [WorkOS Blog]() Topics: [Nix](), [Deployment](), [Software](), [Shell](), [Docker](), [Meta]() Tags: [architecture](), [declarative](), [deployment](), [developer](), [docker](), [product](), [sandboxes](), [software]() ### AI overview Flox CEO Ron Efroni discusses using Nix-based, hermetic environments to give software agents deterministic places to run. The article explains Flox's declarative manifests, cryptographically pinned inputs, reproducible package resolution, and relationship to containers and Docker. ### Source excerpt Flox CEO Ron Efroni talks to Michael Grinich at the AI Engineer World's Fair about Nix, hermetic agent sandboxes, and shipping code to a conviction bar. ## Native auto-activate in Flox DevFeed: [Native auto-activate in Flox]() Original publisher: [Read original article]() Author: garbas Published: 2026-08-03T20:37:51Z Content type: opinion Language: en Sources: [Announcements - NixOS Discourse]() Topics: [Nix](), [Development]() Tags: [announcements](), [environment](), [environments](), [functionality](), [services](), [setup](), [using]() ### AI overview The post discusses Flox 1.14.0, which adds native auto-activation for development environments. It compares this functionality with direnv and nix-direnv, noting that Flox also supports services, layered environments, shell aliases, and functions. ### Source excerpt So: if you are using nix and use it to setup your development environments you are probably using direnv. most of nixers I know use it. you change the directory and it automagically enters your development environment. at flox we call this auto activation. We released Flox 1.14.0 and we made this functionality native. Steve even wrote about it in detail: Flox | Auto-Activation Is Now Native in Flox. First question I would have as a Nix user would be: "Why didn't you just use direnv and extend like nix does it with nix-direnv?". In short: we would love to, but our activation includes deeper features like services, layered environments, shell aliases and functions. If nothing what you should take from this post is that you give direnv a try if using nix. and with flox this functionality comes out of the box. Do you also wish this functionality would come OOTB with nix? 3 posts - 2 participants Read full topic ## Nix flake check + JUnit = Junix DevFeed: [Nix flake check + JUnit = Junix]() Original publisher: [Read original article]() Author: Yajo Published: 2026-07-23T12:35:46Z Content type: release Language: en Sources: [Announcements - NixOS Discourse]() Topics: [Nix](), [ci](), [GitHub](), [GitHub Actions](), [GitLab](), [Jenkins]() Tags: [announcements](), [build](), [ci](), [github](), [github-actions](), [gitlab-ci](), [jenkins]() ### AI overview Junix converts Nix JSON output into standard JUnit XML reports, allowing Nix builds and checks to integrate with JUnit-compatible CI systems such as GitLab CI, Jenkins, and GitHub Actions. It can evaluate system checks, repeat failed evaluations for full tracebacks, build local checks, include logs, and print a human-readable summary. ### Source excerpt Hi all! I'd like to share Junix, a small tool that converts Nix @nix JSON output into standard JUnit XML so you can integrate Nix builds with any JUnit-compatible CI (GitLab CI, Jenkins, GitHub Actions, etc.). Try it: cd your/flake nix run gitlab:moduon/junix check -o result.xml This will: Eval all systems checks in one shot If any eval fails, repeat that check's eval to get full traceback Build local system checks Write the JUnit XML report in result.xml with check build logs and eval failure logs, if any Print a colorful human-readable summary 9 posts - 6 participants Read full topic ## \[no-LLM\] \`nix-weather-hs\` - analyzing un-built derivation graphs for cache availablility DevFeed: [\[no-LLM\] \`nix-weather-hs\` - analyzing un-built derivation graphs for cache availablility]() Original publisher: [Read original article]() Author: MagicRB Published: 2026-07-22T18:52:23Z Content type: article Language: en Sources: [Announcements - NixOS Discourse]() Topics: [Nix](), [Caching](), [Graphs](), [configuration]() Tags: [announcements](), [build](), [cache](), [configuration](), [graphs]() ### AI overview A forum post announces the first functional version of nix-weather-hs, a Nix project that checks cache availability across a derivation closure, builds an in-memory graph, and exports it in multiple formats. It is designed to help debug derivations that cannot be built because of resource limits or other reasons. ### Source excerpt no artificial intelligence, only human stupidity (specifically mine) Hey everyone, I am hereby announcing the first functional version of nix-weather-hs. This project is inspired and based on nix-weather by @cafkafk. For details see the README.org, but the brief version is that nix-weather-hs will check cache availability for a whole closure, build a graph in memory and then it allows you to export said graph into multiple formats. Before export there are a few filters available, which make the resulting graphs more readable. As an example you can use the following command to check the availability of a NixOS configuration, reduce the graph to the 2nd level leaves of the uncached portion. nix-weather-hs graph --filter 'uncached' --filter 'leaves@2' --output dot $(nix eval --raw .#nixosConfigurations.nixos.config.system.build.toplevel.drvPath) As you can see, nix-weather-hs currently works with derivations, which is a defining feature compared to nix-weather. My version was specifically built to debug cases, where you are unable to even built the derivation, due to resource limits or other reasons. If you want to contribute, open issues, you should be able to log into my Forgejo with GitHub (codeberg planned). If any issues arise, please ping me. If you want to reach out privately, to talk about, well anything, please don't hesitate to contact me here, on matrix @magic_rb:matrix.redalder.org or Signal magic_rb.01. If you're considering asking an LLM a question about this project, please ask me instead. Thank you for your time and hopefully nix-weather-hs is useful to you. 27 posts - 4 participants Read full topic ## Npb: Nixpkgs PR build diff CLI inspired by nixpkgs-review DevFeed: [Npb: Nixpkgs PR build diff CLI inspired by nixpkgs-review]() Original publisher: [Read original article]() Author: samestep Published: 2026-07-21T21:09:29Z Content type: article Language: en Sources: [Announcements - NixOS Discourse]() Topics: [Nix](), [Development](), [Command-line interface]() Tags: [announcements](), [caching](), [cli](), [memory](), [parallelism](), [text]() ### AI overview A developer introduces npb, a Nixpkgs pull-request build outcome diff CLI inspired by nixpkgs-review. It compares build results before and after a change, and adds features including passthru.test inclusion, cached failures, lower memory usage, parallel Nix evaluations, reproducible report commands, and progress indicators. ### Source excerpt Hello! While reviewing Nixpkgs PRs written by myself and others, I've found it difficult to keep track of which build failures were preexisting and which are regressions introduced by the PR itself. So I built a tool called npb which produces reports that are similar to nixpkgs-review, but show both before and after, instead of just after. github.com GitHub - samestep/npb: Nixpkgs build outcome diff CLI Nixpkgs build outcome diff CLI While building this, I also included some other features I had found myself wanting previously, such as: automatically including passthru.tests caching build failures in a local database reducing memory usage of Nix evaluations speeding up Nix evaluations via parallelism giving each report a command that reproduces the same report providing progress indicators during long-running operations I hope you find it useful! Disclosure, quoting the project's README: The development of this project was AI-assisted. There is no AI-generated text in this README, npb --help, or npb's generated reports. 7 posts - 4 participants Read full topic ## Pedantix - the pedantic nix formatter DevFeed: [Pedantix - the pedantic nix formatter]() Original publisher: [Read original article]() Author: Swarsel Published: 2026-07-18T21:25:52Z Content type: release Language: en Sources: [Announcements - NixOS Discourse]() Topics: [Nix](), [Development]() Tags: [announcements](), [development](), [release]() ### AI overview This discussion announces the first stable release of pedantix, a customizable formatter for Nix files. It builds on a formatter of the user's choice and applies uniform ordering and structure across Nix files. The author reports that their configuration migrated without issues and that nixpkgs still evaluated fully after testing. ### Source excerpt So over the last years, it constantly bothered me that expressions in my nix files were never sorted enough to my liking even after using the available formatters like nixfmt; examples would be module arguments ({lib, config ...} vs {config, lib, ...}) but also the attribute sets themselves. Since nix does not work line-by-line, it makes in my mind not a lot of sense to apply custom ordering to attributes rather than a uniform one (except for maybe let and rec). For the last one or so weeks, I was working on a solution to this "problem", which I coined "the pedantic Nix formatter", or pedantix in short. It builds on top of your base formatter of choice (and stays in compliance with it) and is basically fully customizable to your liking. It ensures a fully uniform structure between all of your nix files After migrating my own config to it without any issues arising, I decided today that this marks the first stable release. Also, I threw it against nixpkgs to see how the future could look like when using pedantix you can find that result here. Nixpkgs still fully evaluated after that, so I guess it is safe for you to trust it with your own config I thought this might be useful for other people as well, so here you go! You can check it out at: GitHub - Swarsel/pedantix: The pedantic nix formatter - GitHub. 14 posts - 5 participants Read full topic ## Nix 2.35.0 released DevFeed: [Nix 2.35.0 released]() Original publisher: [Read original article]() Author: lisanna Published: 2026-07-13T20:36:40Z Content type: release Language: en Sources: [Announcements - NixOS Discourse]() Topics: [Nix](), [releases](), [content addressed store](), [Security](), [hashing](), [integrity]() Tags: [bugfixes](), [content-addressed-store](), [hashing](), [improvements](), [integrity](), [new-features](), [nix-releases](), [releases](), [security]() ### AI overview Nix 2.35.0 is released with new features, bug fixes, performance improvements, and a security fix for recursive-nix. A highlighted change makes source copying to the Nix store more lazy, reducing unnecessary work for typical flake evaluations while preserving the evaluator's existing behavior. ### Source excerpt On behalf of the Nix team, I am pleased to finally announce the release of Nix 2.35.0. This release contains a good number of new features, bugfixes, and performance improvements, and is available at releases.nixos.org. This release also fixes a security issue with recursive-nix: https://github.com/NixOS/nix/security/advisories/GHSA-6h4g-g5j9-fm5f Release Notes Highlights Sources are copied to the store more lazily #3121 #15711 #15920 Historically, flakes source trees have been eagerly fetched to and evaluated from the Nix store to ensure deterministic and hermetic evaluation, even if the resulting store object is not used as a derivation input. This made the implementation simpler, yet made flakes unusable in large repositories and performed unnecessary writes to the store on each change to the source tree. Since Nix 2.32, all I/O (excluding path: and hg+:-style inputs) for reading sources during evaluation has been funneled to their original filesystem location (or to the ~/.cache/nix/tarball-cache-v2 bare git repository for tarball-based inputs). However, the source tree was still fetched to the store - primarily for computing the resulting content-addressed store path. In most cases, (such as importing the nixpkgs package set) this is not necessary. Touching (and hashing the NAR serialisation of) the whole source tree is unavoidable, since: In case of flake inputs, narHash integrity must be checked eagerly. The outPath attribute of a flake must be known in advance, and for backwards compatibility must be a content-addressed store path string with constant string context representing the flake source tree. Even within the constraints imposed by backwards compatibility requirements, there are several improvements that are achievable. To reduce the number of copies performed, Nix now hashes the input without copying first, assuming that the .outPath will not end up in a derivation attribute and thus would never have to be actually fetched to the store. This comes a ## Mikrotik.nix: Declaratively manage RouterOS configuration DevFeed: [Mikrotik.nix: Declaratively manage RouterOS configuration]() Original publisher: [Read original article]() Author: nrabulinski Published: 2026-07-13T00:14:48Z Content type: article Language: en Sources: [Announcements - NixOS Discourse]() Topics: [MikroTik](), [Nix](), [configuration](), [Network]() Tags: [announcements](), [commands](), [configuration](), [feature](), [forgejo](), [github](), [mikrotik]() ### AI overview The author announces mikrotik.nix, an early project for declaratively managing MikroTik RouterOS configuration with Nix. The project is being tested at home, remains rough around the edges, and uses the RouterOS API for activation and cleanup of resources managed by Nix. ### Source excerpt Having just applied my home router configuration, I'm happy to announce my latest project: mikrotik.nix. As the README says, it's very early still, and I'm very much looking for feedback if someone is feeling adventurous enough to try it. So far I'm just converting the output of /export compact from my router to put into my config repo, fixing whatever comes up, and extending the feature-set as I go. The canonical repo can be found here: nrabulinski/mikrotik.nix - Forgejo: Beyond coding. We Forge. and this is also what I recommend depending on, as it has higher uptime than GitHub. There is also a GitHub mirror though, for the purpose of creating issues and PRs GitHub - nrabulinski/mikrotik.nix: Mirror of https://git.rab.lol/nrabulinski/mikrotik.nix - GitHub And finally here's the commit where I add mikrotik.nix to my config: net/home/router: init - fc9c489c6d - nrabulinski/settei - Forgejo: Beyond coding. We Forge. 3 posts - 2 participants Read full topic ## Documentation team funding 2026 DevFeed: [Documentation team funding 2026]() Original publisher: [Read original article]() Author: Infinisil Published: 2026-07-11T14:11:06Z Content type: news Language: en Sources: [Announcements - NixOS Discourse]() Topics: [Documentation](), [Nix](), [Deployment](), [CI/CD](), [Framework](), [navigation]() Tags: [2026](), [announcement](), [announcements](), [documentation](), [funding]() ### AI overview The NixOS Foundation announces renewed fundraising for its documentation team. The effort aims to improve onboarding, discovery, framework evaluation, the docs.nixos.org cutover, continuous deployment, feedback times, navigation, and redirects. It also invites non-monetary support through community channels and meetings. ### Source excerpt tl;dr: There is a renewed effort to improve documentation, head to Documentation team - Open Collective or contact foundation@nixos.org to chip in with funding! With the 2023 crowd-funding in documentation funding, we've seen some improvements, but a lot more is needed to make significant progress towards improving the overall experience with Nix documentation, including onboarding and discovery. Especially newcomers frequently struggle with our documentation, get frustrated and notice gaps, and have a hard time adopting Nix. In addition, in the Nix community survey 2025 we see that most people want excess funding to be allocated to improving documentation. While the NixOS Foundation doesn't have that much excess funding, @hsjobeki has stepped up to pick up leadership of the documentation team with support by @friedow. While they're volunteering their own time to lead the team, they'd like to have access to funding for not just ensuring that stuff gets done, but also maintained over time. They've collaborated to agree on a documentation vision (initial announcement) to work towards. For that reason, we're asking individuals and companies to donate to the renewed documentation team OpenCollective, so that we can reach the funding goals (more details on OpenCollective): (1.000 EUR /month) Paid documentation maintainer (4.000 EUR ) Framework evaluation (15.000 EUR ) Prepare docs.nixos.org cutover (8.000 EUR ) Continuous deployment & Reduce feedback times (8.000 EUR ) Navigation & redirects If a company is interested in providing a significant amount of funding and would like a contract and invoice, please reach out to foundation@nixos.org. Furthermore, if you'd like to support documentation in non-monetary ways, feel free to join the Matrix channel and/or bi-weekly meetings (see "Nix documentation meeting" in the NixOS Calendar), or see where you can help from updates in the discourse category. -- NixOS Foundation board 8 posts - 5 participants Read full topic ## CTRL-OS 26.05 Released! DevFeed: [CTRL-OS 26.05 Released!]() Original publisher: [Read original article]() Author: blitz Published: 2026-07-10T12:35:43Z Content type: release Language: en Sources: [Announcements - NixOS Discourse]() Topics: [Nix](), [Linux](), [maintenance](), [Security](), [cyber resilience act]() Tags: [announcements](), [cyber-resilience-act](), [infrastructure](), [linux](), [maintenance](), [release](), [sboms](), [security]() ### AI overview CTRL-OS 26.05, a downstream distribution of NixOS, has been released. The release provides a five-year lifecycle model, beginning with co-maintenance while NixOS has community support and moving to stability maintenance afterward. CTRL-OS monitors and backports security fixes for a core package set, with commercial subscriptions supporting SLAs and custom package sets. The project also describes its role in helping embedded Linux products address long-term vulnerability patching and EU Cyber Resilience Act requirements. ### Source excerpt Welcome to the latest CTRL-OS update! Find the last update from April here. If you don't know yet, CTRL-OS is a downstream distribution of NixOS designed to extend the release lifecycle to 5 years. It gives you a stable foundation with commercial support so you can build your products without having to maintain the packages you depend on. CTRL-OS 26.05 Released! The CTRL-OS 26.05 release is finally out. You can find the release blog post on our website. Or head over to our technical documentation and try it out. As long as NixOS 26.05 has community support, CTRL-OS 26.05 will be in the co-maintenance phase. In this phase, we will monitor our supported package set and contribute any security fixes back to NixOS. After community support ends, we enter the stability phase, and maintenance shifts completely to us. We've detailed this model on our blog. As of now, we support a small but useful package set. We'll share more details here soon, but our goal is to cover the usual packages you deploy on a server or embedded system, i.e., that dusty plastic box in the corner that quietly does its job for years. We actively monitor and backport CVEs for a core set of packages. To fund this work, commercial subscriptions provide SLA guarantees and cover custom package sets. While we aim to stay very close to NixOS 26.05, we will pull in important security fixes quickly to keep our SLAs. This creates a divergence that will automatically resolve itself once the security fixes make it to the NixOS release branch as well. Finally, to avoid a maintenance burden for the community, our CTRL-OS 26.05 release is lightly branded. By making it easy to identify a CTRL-OS system via nix-env -m, we ensure that bug reports originating from CTRL-OS users don't accidentally get filed against upstream NixOS, respecting the time and effort of upstream maintainers. No Cyber Resilience Act (CRA) Worries With the EU's CRA requirements taking effect this September, shipping embedded Linux products is ## Documentation team funding DevFeed: [Documentation team funding]() Original publisher: [Read original article]() Author: NixOS Published: 2026-07-10T12:00:00Z Content type: news Language: en Sources: [NixOS Announcements]() Topics: [Documentation](), [Nix](), [Deployment](), [navigation]() Tags: [2025](), [announcement](), [community](), [continuous-deployment](), [deployment](), [documentation](), [funding](), [improvements](), [navigation](), [nix](), [onboarding](), [team]() ### AI overview The NixOS Foundation is renewing its effort to improve Nix documentation and is seeking donations for a documentation team. Proposed funding would support a paid maintainer, framework evaluation, page splitting, continuous deployment, faster feedback, navigation, and redirects. ### Source excerpt tl;dr: There is a renewed effort to improve documentation, head to https://opencollective.com/nixos/projects/nix-documentation or contact foundation@nixos.org to chip in with funding! With the 2023 crowd-funding in documentation funding, we've seen some improvements, but a lot more is needed to make significant progress towards improving the overall experience with Nix documentation, including onboarding and discovery. Especially newcomers frequently struggle with our documentation, get frustrated and notice gaps, and have a hard time adopting Nix. In addition, in the Nix community survey 2025 we see that most people want excess funding to be allocated to improving documentation. While the NixOS Foundation doesn't have that much excess funding, @hsjobeki has stepped up to pick up leadership of the documentation team with support by @friedow. While they're volunteering their own time to lead the team, they'd like to have access to funding for not just ensuring that stuff gets done, but also maintained over time. They've collaborated to agree on a documentation vision (initial announcement) to work towards. For that reason, we're asking individuals and companies to donate to the renewed documentation team OpenCollective, so that we can reach the funding goals (more details on OpenCollective): (1.000 EUR /month) Paid documentation maintainer (4.000 EUR ) Framework evaluation (15.000 EUR ) Page splitting in nixos-render-docs (8.000 EUR ) Continuous deployment & Reduce feedback times (8.000 EUR ) Navigation & redirects If a company is interested in providing a significant amount of funding and would like a contract and invoice, please reach out to foundation@nixos.org. Furthermore, if you'd like to support documentation in non-monetary ways, feel free to join the Matrix channel and/or bi-weekly meetings (see "Nix documentation meeting" in the NixOS Calendar), or see where you can help from updates in the discourse category. You can also read and discuss this announcement on Discourse. ## 2025 NixOS Community Survey Report DevFeed: [2025 NixOS Community Survey Report]() Original publisher: [Read original article]() Author: djacu Published: 2026-07-08T15:13:37Z Content type: news Language: en Sources: [Announcements - NixOS Discourse]() Topics: [Nix](), [datasets](), [Astro](), [GitHub]() Tags: [2025](), [announcements](), [astro](), [community](), [data](), [report](), [survey]() ### AI overview The 2025 NixOS Community Survey collected 3,399 complete responses from September 1 to December 15, 2025, a 48% increase over 2024. Its report presents aggregated, anonymized results through interactive charts covering community demographics, technology use, experience, contribution, and information seeking. NixOS was the main entry point for most respondents, while flakes and the new nix CLI were the most-used experimental features; flakes were also the most requested area for improvement. ### Source excerpt Hello everyone! On behalf of the NixOS Marketing Team, we're happy to announce that survey results now have a permanent home on the NixOS website: NixOS Surveys First up: the full report for the 2025 NixOS Community Survey at 2025 Community Survey Results The survey ran from September 1 to December 15, 2025 and drew 3,399 complete responses, a 48% increase over the 2,290 we received in 2024. Thank you to everyone who took the time to respond! What's in the report The report turns the responses into interactive charts across seven sections: People, Technology, Experience, Workplace, Contribution, Foundation, and Information seeking. A few highlights to get you started: The community is new and growing. 28.9% of respondents started using Nix within the past year, and 82.5% have under four years of experience. NixOS is the front door to the ecosystem. 70.8% heard of NixOS before Nix itself, 78.4% first installed Nix through NixOS, and YouTube is the single largest discovery channel (28.3%). Flakes are everywhere, in both senses. Flakes (78.9%) and the new nix CLI (66.7%) are by far the most-used experimental features, and flakes also top the list of areas respondents most want improved (50.3%), alongside error messages (47.6%) and the reference manual (41.5%). There's much more in the full report: demographics, hardware and platform targets, contribution patterns, upgrade experiences, and how people find help. About the data We take respondent privacy seriously: only aggregated and anonymized results are published, and raw responses are never released. The data pipeline, chart code, and the site itself are available at GitHub - NixOS/surveys - GitHub. Issues and pull requests are welcome, and you can build and hack on the site locally without access to any raw data. We could use your help This survey is put together by a handful of volunteers on the NixOS Marketing Team, and it's a lot of work for a small group: designing the questions, running and promoting the survey [Next page]()