How to set up and run a Nixpkgs team
Just do it – it’s simpler than you’d think!
Motivation and background
Nixpkgs is the largest open source software distribution in the world, maintained by an ever-growing global community with almost a thousand active contributors every month. In Nixpkgs, a package maintainer ensures that the latest version of a given piece of software is packaged and operational. Most people contributing to Nixpkgs are volunteers, and if you meet some of them at NixCon or any of the numerous meetups, you can tell they’re passionate about building a healthy software ecosystem.
But volunteering obviously has limits. As a result, there is usually only one committer who ever looks at a pull request, including those touching critical packages, such as programs in the NixOS boot chain. And for an outside observer, it can be hard to gauge whether the software distributed is trustworthy. Without peer review, there is a constant risk that changes might introduce security vulnerabilities – or simply degrade code quality and add friction to the next person’s contribution.
I’m part of a group at Tweag that has been working on targeted improvements of supply chain security for Nixpkgs since mid-2025. That naturally involves reviewing pull requests. At some point it seemed sensible to establish a Tweag-branded team directly inside Nixpkgs, to get notified of package updates. That way, we thought, users and other maintainers would know who’s taking care of those packages.
However, when we raised the request with the then-newly-founded Nixpkgs core team, it prompted a thoughtful re-evaluation of the team policy: corporate-affiliated teams are no longer permitted, and team members must be individuals, with or without corporate affiliation. From a distance, such a turn of events may appear annoying at best. But actually, it was the opposite: everyone involved immediately agreed that it was the right course of action. Still, I ended up positively surprised by the outcome.
Setting up the team
To kick it off, we drafted an outline of objectives and procedures and posted it as a Nixpkgs issue. Our primary goal was straightforward: prevent malicious changes from reaching the repository. We wouldn’t merge anything ourselves, but would block merging in case of problems.
Fortunately, any Nixpkgs committer has permission to create GitHub teams under the Nixpkgs organisation. So we did exactly that, leveraging the fact that the in-code team definitions sync automatically from GitHub—a piece of automation built by my former colleague Silvan Mosberger (@infinisil) in 2025.
To manage daily reviews transparently, we set up a project board alongside a custom script to keep it updated. This allows others to track what we’re reviewing and step in to help. We maintain a public list of tracked packages, while keeping our internal review checklist in a private location to make it ever so slightly harder for bad actors to game our checks. The only thing left to do was adding the new team as maintainers of the relevant packages.
An open, topic-oriented team means anyone can join. We decided to require commit access for team membership, since that already entails substantial community reputation and a high level of trust. And we’ve learned that people are genuinely keen to help improve Nixpkgs if given the opportunity! One volunteer joined the team right away, and another a few months later. Team members regularly post feedback, and we established a dedicated Matrix channel to discuss best practices and review standards.
Since then we’ve rotated some members, but keep going at a steady pace. Between March and September 2026, we reviewed more than 250 pull requests, that is, everything that touched the packages in question.
Is Nixpkgs more secure now? We haven’t discovered outright malicious code or active zero-day vulnerabilities. That said, we did catch some genuine mistakes (such as an incorrectly applied patch) and corrected some code quality issues. And we’re on the watch.
Things to keep in mind
Starting a team in Nixpkgs proved surprisingly straightforward. I was initially hesitant about opening the team to everyone, as I expected that the work – reading through code and checking details – might be too boring or mundane for volunteers to do in their free time. To my surprise, some individuals were eager to join and contribute.
When running a community team, I recommend keeping a few practical considerations in mind:
-
People you don’t know may want to join, so be prepared to welcome outside interest and integrate new reviewers.
Exercise judgement, but lean on existing trust networks and procedures.
-
Volunteer availability fluctuates, so expect that you will need to send gentle reminders to get things moving forward.
Try to find out early on what works best for the team.
-
Everyone is at their best if they can focus on one thing at a time.
Be ready to provide support: organise tasks, facilitate exchange, and keep everyone in the loop.
Take responsibility!
If you want to contribute public good to Nixpkgs, setting up a team is one of the most effective steps you can take. It is easy to start, fosters constructive discussions, and brings in fresh ideas from passionate people facing the same challenges. If you are interested in security reviews specifically or want to see how we operate, take a look at our Nixpkgs issue and consider joining the effort.