Noogle: a search engine for Nix functions and their types

Search built for function names, not prose

Noogle is a search engine for the Nix API, and the design decisions are visible in the feature list. The first item is a beginners-friendly search for Nix and Nix-related functions, with documentation comments rendered for readability rather than as raw source, and with the search itself optimized for the English language and for Nix function names. That last point is the difference from a general documentation search. A function name in Nix is a dotted path such as lib.strings.hasPrefix, and searching for a phrase in a paragraph of documentation will not find it. Noogle inverts the approach, treating the name as the primary key. The site is published at noogle.dev, the repository description names the maintainer, and the project is MIT licensed with the default branch on main and a last push on 2026-10-20.

Type signatures are a filter, not decoration

The second feature is filtering by type signatures, and the mechanism is that function types are parsed and interpreted. That is more than display, because it means you can narrow a search to the functions whose arguments and return value match what you are trying to write, which is exactly the situation where a name-based search fails. You know the shape of the thing you want, a string to string predicate, a list to a list mapper, but not the name, and a text search over documentation rarely finds it. The search over types is also where the topic tags of the repository, explore, functions, nix, nixos, nixpkgs, search and types, line up. The type data comes from the same indexing pipeline as the documentation, and the type of the builtins including builtins.derivation is handled as part of the extra data rather than being scraped from the manual.

Pasta indexes, salt carries the rest

The repository is a Nix project with a Rust core, and the division of labour between directories is the interesting part. All indexing is done through the pasta module, which is where the extra data such as the types of the builtins lives in the salt directory. Contributing to the index is deliberately easy. A pull request or an issue is enough, and indexed data can be added in the file ./pasta/src/eval.nix, with the single rule stated in bold in the documentation: indexed data must evaluate. That constraint is the design. Because the index is produced by evaluating Nix code rather than by parsing text, an entry that does not evaluate cannot be included, which keeps the type information honest. The Rust workspace in Cargo.toml holds two crates, pesto and noogle-types, and the repository also carries a nixPlugin directory and a projects.toml file, with a flake and a devShell for the toolchain.

Static pages, one per function, indexed by other engines

Noogle outputs pre-rendered static HTML, one page per API function, and those pages include meta tags for other search engines such as Google or Bing. That last point changes how the tool is discovered. A search engine that indexes noogle.dev can send a user to the page for a specific function, so the tool works both as an app you query and as a source that feeds the search results you were already using. The site is built with a Nix build expression that produces the UI output, and the build is the first thing to run if you want to host your own copy:

nix build .#ui

Searching within the page is done with pagefind, and the documentation notes that this is only available in the production build, which is a detail worth knowing before you conclude that in-page search is broken in a development checkout. The search itself is described as Wasm based and performant, which explains why a static site can offer interactive search without a server.

Documentation that follows nixpkgs the next day

The most valuable property of Noogle is that it does not go stale in the way a manual does. Nix and nixpkgs are updated daily, and all documentation changes are picked up the next day, and the site always shows the latest documentation based on the main branch of Nixpkgs. For a package ecosystem where the function set changes with every commit, that is the whole argument for a search index over a static reference. The nice features list explains how the index stays accurate without a human editing a page. It detects aliases of most lib and builtins functions, so searching for an alias surfaces the canonical function. And it can override the builtins documentation by documenting the alias in nixpkgs.lib, which means a documentation improvement no longer requires a change and a rebuild of the C++ implementation of Nix, a specific point for anyone who has tried to document a builtin before.

A dev shell and a prototype release tag

Working on the site means two commands. The development environment is created with:

nix develop

which creates the node_modules directory with all the needed dependencies based on dream2nix, the tool that turns a package lock file into a Nix expression. The repository layout supports that workflow with an .envrc for direnv, a devShell.nix, a flake.nix and flake.lock, a website directory for the pages, a tests directory, and CI configuration in .github along with a mergify configuration. The version picture is where the project looks least finished. The only tagged release is 0.1.0-alpha, named as a prototype from the OceanSprint and dated 2022-11-26, while the site itself serves current nixpkgs documentation. There is no published version scheme to pin, so if you depend on the service rather than hosting it yourself, the thing to watch is whether the daily indexing job keeps running, not which release you are on.

Editorial conclusion

Adopt Noogle as the reference when you cannot remember the name of a nixpkgs library function or the shape of its arguments, since the type filter and alias detection answer both questions. Do not treat it as documentation you can cite offline, since the pages are regenerated from the nixpkgs main branch each day, and note the only tagged release is the 0.1.0-alpha prototype from 2022.

Frequently asked questions

Official sources

1. License: MIT
2. nix-community/noogle on GitHub
3. Project website
4. README
5. Releases