n-install solves the bootstrap problem of installing a Node version manager

The bootstrap deadlock it exists to break

n is a Node.js version manager. n-install is a shell script that installs it on Unix-like platforms without needing to install Node.js first, and the README is explicit that this is the entire point of the project.

The problem it solves is small and real. Most Node version managers are distributed through npm, because that is how the JavaScript ecosystem distributes things. But npm ships with Node.js. So a machine with no Node.js has no npm, so it cannot install the version manager that would install Node.js. The usual workarounds are a manual download, a package manager entry, or a third party install script, and each of those is a separate thing to learn and to get wrong.

n-install is that third party script, done carefully. Alongside n itself it installs two more scripts, n-update for updating n on demand later, and n-uninstall for removing it.

The simplest invocation is the one line in the repository description.

curl -L https://bit.ly/n-install | bash

The shortened address is documented rather than hidden. The README says the bit.ly URL resolves to the raw GitHub URL of the n-install script in the stable branch of the repository, so you can check exactly what the short link points at before you pipe it into a shell.

The last push to the repository was on 2026-10-12, and the project publishes no GitHub releases, so the script on the stable branch is the artefact, not a tag.

Everything lands in one directory, and that is the uninstall plan

The installation target is a dedicated directory that defaults to ~/n and can be overridden with the N_PREFIX environment variable. Both n itself and the active Node.js version are placed inside it.

The README explains the choice of location carefully, and the reasoning is worth repeating because it decides whether you need sudo. When you override the default, it is advisable to choose a user location, typically a subfolder of your home directory at any level, so that installing global npm packages later does not require elevated privileges. Either way, the target directory must either not exist yet or be empty, so the script will refuse to install over an existing directory rather than merge into it.

The payoff is stated plainly: using a dedicated directory to hold both n and the Node.js versions greatly simplifies later uninstallation. There is no guessing which files a package manager scattered across /usr/local, because there are none outside the one directory you chose.

That property is also what makes the tool scriptable. A CI image can set N_PREFIX to a path it controls, install, and delete the directory to get back to a clean state, without needing to know anything about how n stores its versions.

It edits your shell file, and it tells you which one

This is the part of the installation that deserves a careful read, because it modifies a file you did not ask it to touch.

If your shell, taken from the $SHELL environment variable, is bash, ksh, zsh, fish or pwsh, the installer modifies the relevant shell initialisation file. It defines N_PREFIX to point at the installation directory and appends $N_PREFIX/bin to the PATH, unless it is already there. For any other shell, the modification has to be done by hand, and the installer prints instructions during the run.

Two escape hatches exist. The -n option suppresses the shell file modification entirely, and the README notes you can also choose which shell's file is updated by setting the SHELL environment variable to that shell's file name before calling the installer, giving the example of running it with SHELL=fish. The same applies on uninstallation, where the matching SHELL=fish n-uninstall is needed to target the same file.

Afterwards you must open a new terminal tab or reload the shell initialisation file before n or Node.js will be found. The README gives the concrete commands for the common cases, sourcing .bashrc on Linux and .bash_profile on macOS, and says the installer will tell you the specific file to reload when it succeeds.

The one thing worth flagging is that a shell file edited by an installer is a file your other tools also read. If you already manage PATH through a version manager of your own, or through a dotfiles repository, a second writer is a source of conflicts that shows up as a version that should not be resolving.

Flags for automation, quiet runs and specific versions

The script is designed to be usable from a provisioning script as well as by hand, and the documented options cover the cases that matter.

The default run is interactive, with a confirmation prompt, and installs the latest LTS Node.js version. The -y flag skips the prompt, and -q makes the run quiet with no status information at all.

curl -L https://bit.ly/n-install | bash -s -- -y

curl -sL https://bit.ly/n-install | bash -s -- -q

Versions can be given as arguments, so you can ask for the latest LTS and a specific major in one run.

curl -L https://bit.ly/n-install | bash -s -- -y lts 22

And the installation directory can be set inline with the N_PREFIX environment variable.

curl -L https://bit.ly/n-install | N_PREFIX=~/util/n bash -s -- -y

The general form, given in the README, is this.

curl -L https://bit.ly/n-install | [N_PREFIX=<dir>] bash [-s -- [-y] [<version>...]]

The -s -- part is required by Bash itself rather than by the script, since it is how options are passed through to a script that arrives on standard input. A detail worth knowing if you ever adapt these commands.

The README also notes that the examples use curl for brevity, and that a given command can be run with wget instead by replacing curl -L with wget -qO-, with a comment in the source indicating that this should be activated once n itself supports wget.

Prerequisites you need before the script can help you

The listed requirements for the platforms n supports are bash, curl, git and GNU make. The README says these are met by default on macOS and on at least some Linux platforms, and that what is usually missing on Linux is git and curl, which can be installed from the platform package managers, giving the Debian and Fedora examples.

There is a small irony here that the README does not dwell on. A script whose job is to install a Node.js tool without needing Node.js still needs curl and git, which on a minimal container image or a locked down workstation are often exactly the packages that are not present. The README notes that bash and curl are required by n itself as well, so they are not optional extras for the installer alone.

Two more constraints are stated. Any preexisting n or Node.js installation must be removed before using this installation method, which is a hard requirement rather than a warning, and because the script modifies your shell initialisation file you need a new terminal or a reload before n and Node.js are usable.

On the sourcing question, the README is direct about the trade-off in the licence section of the project notes: the script is fetched over the network and executed immediately, so the sensible habit is to read the script first. The README helps here by documenting exactly what the shortened URL resolves to, so you can fetch the raw file, read it, and then run it.

The npm package is private, the scripts are the product

The package.json for the repository is worth reading because it explains how the project is built and released rather than distributed.

The package is marked private and its version is 0.6.5, so it is not something you install from a registry. The bin map lists the three artefacts, n-install, n-update and n-uninstall, each pointing at a file in bin/, and the os array restricts the package to darwin and linux. The license field says MIT, and the repository also ships a LICENSE.md file, although GitHub's own classification of the repository licence is recorded as one it cannot categorise, so the file in the tree is the one to read.

The devDependencies reveal the tooling. doctoc generates the table of contents that sits at the top of the README, json is used by the Makefile to handle JSON files, replace performs text substitutions, semver does version comparison, tap is the test runner and urchin is a test framework. The test script simply delegates to make test, so the Makefile is the real entry point for development.

That Makefile is unusual in a way that reflects the constraint of a project whose own build needs Node.js. It aborts if make is not run from the directory the Makefile lives in, because the paths are relative to it, it forces SHELL to bash, and it extends PATH with both ./node_modules/.bin and $N_PREFIX/bin so that helper npm modules and node itself are found. There are sanity checks that refuse to continue without a git repository or without node_modules installed, with a message that reminds you that Node.js must be installed first.

So the project has a mild irony: you install it to avoid needing Node.js, but to develop it you need Node.js.

Where n-install is the wrong choice

Three situations rule it out.

The first is Windows. The os array in package.json lists darwin and linux only, and the shell initialisation logic covers bash, ksh, zsh, fish and pwsh, which is a Unix-shaped world. On Windows you want the version manager's own installer rather than this one.

The second is a reproducible build environment. The whole mechanism is a network fetch of a script from a URL that changes over time, resolved through a shortened link to the stable branch of the repository. For a container image you want to build again in six months, a pinned version of Node.js installed from your own artifact store is a better answer, because the n-install route makes your image depend on whatever the stable branch contains that day.

The third is a policy environment that forbids piping a downloaded script into a shell. That is a reasonable rule in many organisations, and no amount of documentation in the README changes it.

Even where n-install fits, there is a smaller operational point. The install writes to your shell initialisation file, so a machine managed by a dotfiles repository will see two writers of the same PATH line, and the fix for that is to use the -n option and add the PATH entry yourself, or to accept the conflict.

Within its narrow purpose, though, the script does what it says and says what it does, which is more than most installers manage.

Editorial conclusion

n-install is the right choice for a Unix-like machine that has no Node.js yet and needs one, since it solves exactly the bootstrap deadlock and leaves a single directory to delete later. It is the wrong choice on Windows, in a container image you want reproducible, or in any environment where piping a script from a URL into a shell is not acceptable, and it requires bash, curl, git and GNU make to be present first. Before running it, decide on your N_PREFIX location, check whether an existing n or Node.js installation has to be removed first, and note that the default install writes to your shell initialisation file, which is the part of the process most likely to surprise you.

Frequently asked questions

Official sources

1. Issues
2. mklement0/n-install on GitHub
3. README