Shellbit: a tool to manage remote nix-shell derivations

In order to version-control the nix-shells I use for several projects (without committing nix files to the projects themselves), I created a separate repo to reference in nix-shell invocations:

cd /path/to/use-db
nix-shell -A use-db \

nixels is just a minimal working example of such a repo. The examples within are not real-world projects.

cd /path/to/use-queue
nix-shell -A use-queue \

Tagging git revisions like <project>-<version> allows me to specify which version of the project I want an environment for:

cd /path/to/use-db
nix-shell -A use-db \

Ideally though, I wanted a simpler interface, like:

$ cd /path/to/use-db
$ somecommand

where somecommand detects the current project and version, and selects the right nix-shell derivation automatically.

So I wrote a CLI to do just that: shellbit. I’ve seen similar ideas floated in past threads. This was my take on it.

nix-env -iE '_:
    url =;
    (import "${builtins.fetchTarball url}/nix" { }).minimal

The first time it’s used, it prompts for the url where it can find your nix-shell recipes.

$ cd use-db
$ shellbit

SHELLBIT_URL not found in environment or config.
It should identify a git repo where we can find nix derivations
for your project shells. E.g.
Please enter SHELLBIT_URL:

Config can be saved to /home/ivan/.config/shellbit/config.dhall
Save config? [Y/n] y


If you choose to save the config, subsequent uses will work without prompting.

$ cd use-queue
$ shellbit

I’m curious for feedback, and I’d like to submit it to nixpkgs.

Maybe setting up a repo of nix-shell recipes is more work than some users will want to invest, but I’m getting good mileage out of this approach so far.

I put up a minimal example of such a repo at so all the examples above will work.


Have you seen @Mic92’s already? I haven’t looked at either projects in detail but they seem to be related.

Yes! I saw that. I was actually inspired by this comment you made about a potential CLI interface.

I needed a configurable CLI in order to point it at a private repo holding the environments for work projects.

Aside from the version-tagging scheme, the structure of the target repos is the same.