Skip to content

Using Nix Day-to-Day

This page focuses on how Nix fits into everyday development work.

You don’t need to “go all in” on Nix to get value. Many teams start by using Nix as:

  • a tool installer
  • a dev environment manager
  • a way to make workflows predictable

We’ll explore common patterns and commands you can use immediately.


Mental Model: Nix as a Tool, Not a Lifestyle

Section titled “Mental Model: Nix as a Tool, Not a Lifestyle”

You can think of Nix as:

  • a package runner (nix run)
  • a temporary environment (nix shell)
  • a build orchestrator (nix build)

All of these can coexist with your existing tools.


One of the fastest wins with Nix is running tools without modifying your system.

Terminal window
nix run nixpkgs#ripgrep -- --version

This:

  • downloads the tool if needed
  • runs it
  • leaves your system unchanged
Terminal window
nix run nixpkgs/nixos-23.11#ripgrep -- --version
Terminal window
rg --version || echo "ripgrep not installed globally"

This is especially useful for CI parity and trying tools safely.


Temporary shells are a common daily workflow.

Terminal window
nix shell nixpkgs#git nixpkgs#jq nixpkgs#curl

Now check what’s available:

Terminal window
which git
which jq
which curl

Exit the shell:

Terminal window
exit
Terminal window
nix shell nixpkgs#nodejs -c node --version

Why nix shell Is Different from Virtualenvs or Containers

Section titled “Why nix shell Is Different from Virtualenvs or Containers”
  • Tools are explicitly declared
  • No activation scripts
  • No mutation of global state
  • Fast to enter and exit

If it breaks, you exit the shell and you’re back to normal.


For projects, you usually want the same tools every time.

Terminal window
nix shell nixpkgs#nodejs nixpkgs#pnpm nixpkgs#jq

Later, this becomes:

Terminal window
nix develop

(with configuration living in the repo)

We’ll cover this more in Dev Environments and Flakes.


Nix works well with existing ecosystems.

Terminal window
nix shell nixpkgs#jdk17 nixpkgs#maven -c mvn test
Terminal window
nix shell nixpkgs#nodejs nixpkgs#npm -c npm test
Terminal window
nix shell nixpkgs#python3 -c python --version

The important thing: the toolchain becomes reproducible, even if the build system stays the same.

Working with Multiple Versions Side by Side

Section titled “Working with Multiple Versions Side by Side”

Nix makes it easy to compare versions.

Terminal window
nix shell nixpkgs/nixos-23.11#nodejs -c node --version
nix shell nixpkgs/nixos-24.05#nodejs -c node --version

Use different versions in different projects

Section titled “Use different versions in different projects”

No global installs. No conflicts.


Many teams first adopt Nix by matching CI locally.

Terminal window
nix shell nixpkgs#jdk17 nixpkgs#maven nixpkgs#git -c bash

Then run the same commands CI runs.

“Works in this shell” becomes meaningful.


When Things Go Wrong (Normalizing Failure)

Section titled “When Things Go Wrong (Normalizing Failure)”

Nix failures often feel abrupt at first.

  • missing dependency
  • build blocked from accessing something
  • wrong version pinned

These are signals, not random breakage.

  • read the error
  • identify what input is missing
  • add it explicitly

Nix failures usually mean “you forgot to declare something.”


These patterns tend to work across teams:

  • Use nix run for one-off tools
  • Use nix shell for ad-hoc environments
  • Use nix develop for project environments
  • Keep Nix usage near the edges at first

You do not need to:

  • package everything
  • write complex Nix code
  • adopt NixOS
  • replace your build system

Early success comes from using Nix as a helper, not a replacement.


Terminal window
nix run nixpkgs#terraform -- version

B) Create a shell and inspect PATH differences

Section titled “B) Create a shell and inspect PATH differences”
Terminal window
env | grep PATH
nix shell nixpkgs#jq -c 'env | grep PATH'
Terminal window
which git
nix shell nixpkgs#git -c which git

  • Nix can be useful without full adoption
  • Day-to-day workflows focus on run, shell, and develop
  • Explicit environments reduce surprise
  • You can add structure gradually