I’m happy to announce flakestry.dev - a registry for flakes. GitHub repo
It is intended as a replacement for the existing search.nixos.org/flakes. We are fully committed to making Flakestry an official Nix project, thus replacing the existing registry.
The project was spearheaded by Domen and Sander over the past weeks, with the input of various community members like @RaitoBezarius, @roberth, @srid, @zimbatm, @infinisil, @Kranzes and @garbas.
The initial version allows publishing of flakes via GitHub actions, although other sources can be added later on.
It enforces semantic versioning and does not currently act as a proxy.
It’s deployed via fly.io, with backend written in FastAPI and frontend in elm.land. There’s staging.flakestry.dev that’s deployed directly from
If you want to help out, it would be interesting to see someone play with flake output JSON and display the outputs alongside the README.
A note on flakehub.com/mynixos.com: these heroic efforts demonstrated that people liked the idea of having a central flake registry. We wanted to avoid the issues that are caused when a company controls the registry (eg: NPM) so we built a flake registry that is part of the Nix community in similar spirit like PyPi, Hackage, etc.
Glad to see that this one is FOSS and that non-github flakes are planned
This is so cool to see. I’m glad to see an open source implementation of flakehub, and am excited to see validation of the core value proposition of semantic versioning being relevant and important to the nix ecosystem. Well done, congratulations. Congrats on the launch!
I would be interested in contributing code to make regular backups. Ideally those backups could be also made public because than we could start archiving all flakes.
By the way – I’m a bit surprised to see flakestry.dev isn’t itself a flake – is that in the cards?
I think multiple competing registries, including people hosting their own, is even better than a single community registry, so this is good.
The notion of centralization that registries imply is what makes them iffy — centralized human readable names is in opposition to the general nix philosophy of trustlessness and things being freely combinable (no collisions, no conflicts, etc.). Having multiple registries re-decentralizes things — unhappy someone is squatting a name? Just create your own registry! This is unambigiously good.
Also, I hope eventually at least one things don’t care about flakes at all. As we’ve discussed on the Nix Team, registries are a fetching concept, and fetching is conceptually prior to flakes (see WIP: Generalize the fetcher registry to not be flake specific by Ericson2314 · Pull Request #9085 · NixOS/nix · GitHub). Of course, I imagine it is good for registries to enforce additional structure — otherwise they are just a glorified bad version control — but there are many ways one might want to do that.
Looks good! Also nice to hear it will replace
search.nixos.org/flakes. I was a bit worried seeing the title that there would be 3 different similar services for flake discovery
It enforces semantic versioning and does not currently act as a proxy .
What should be done with versions? For instance,
nixpkgs-ruby: they all do not have versioned releases. Will Redirect flake pins to github tarballs · Issue #17 · flakestry/flakestry.dev · GitHub allow adding flakes without versioned releases? Are there future plans for versioned flakes?
Edit: thinking about this a bit more, since semantic versioning was mentioned. So it might be to refer to some stable x.x.y version range. However, we already can refer to branches which seems more powerful than versions? An vx.x branch might already be just as useful? But a beta/staging branch is also possible (something that can be inconvient using version numbers). Am I overlooking something?
I think it’s just that not all projects (especially small ones) necessarily use a branch structure that exactly mimics their semantic versioning / release structure, or use a consistent structure between or even within each other.
That is certainly the case with rust crates, and likely many similar things in other languages, where the semantic versioning is resolved from metadata within the package content.
I’ve implemented outputs and inputs representation:
See an example for nixpkgs-python.
Now with pagination for bigger flakes:
I’ve added a badge for each flake and since yesterday, finally, all flake outputs should render in the sidebar. Enjoy an example
We also have a matrix room if you’re looking to contribute.