Nix is currently supported on the following platforms: Linux (particularly on x86, x86_64, and PowerPC). Mac OS X. FreeBSD (only tested on Intel). Nix is pretty portable, so it should work on most other Unix platforms as well.

The easiest way to install Nix is to use a binary package. Binary packages of the latest stable release are available for Fedora, Debian, Ubuntu, Mac OS X and various other systems from the Nix homepage. You can also get builds of the latest development release from our continuous build system. For Fedora, RPM packages are available. These can be installed or upgraded using rpm -U. For example, $ rpm -U nix-1.0-1.i386.rpm For Debian and Ubuntu, you can download a Deb package and install it like this: $ dpkg -i nix_1.0-1_amd64.deb For other platforms, including Mac OS X (Darwin), FreeBSD and other Linux distributions, you can download a binary tarball. It contains Nix and all its dependencies. You should unpack it in the root directory, then run nix-finish-install: $ cd / $ tar xfj nix-1.1-x86_64-darwin.tar.bz2 $ nix-finish-install After this you can delete /usr/bin/nix-finish-install. If you plan to use Nix from a single non-root user account, it’s probably convenient to change the ownership of the entire Nix store and database to that user account. In that case, install as follows: alice$ cd / alice$ sudo tar xfj nix-1.1-x86_64-darwin.tar.bz2 alice$ sudo chown -R alice /nix alice$ nix-finish-install Nix can be uninstalled using rpm -e nix or dpkg -r nix on RPM- and Dpkg-based systems, respectively. After this you should manually remove the Nix store and other auxiliary data, if desired: $ rm -rf /nix

If no binary package is available, you can download and compile a source distribution.

A fairly recent version of GCC/G++. Version 2.95 and higher should work. Clang will also work. Perl 5.8 or higher. pkg-config to locate dependencies. If your distribution does not provide it, you can get it from . The bzip2 compressor program and the libbz2 library. Thus you must have bzip2 installed, including development headers and libraries. If your distribution does not provide these, you can obtain bzip2 from . The SQLite embedded database library, version 3.6.19 or higher. If your distribution does not provide it, please install it from . The Perl DBI and DBD::SQLite libraries, which are available from CPAN if your distribution does not provide them. The Boehm garbage collector to reduce the evaluator’s memory consumption (optional). To enable it, install pkgconfig and the Boehm garbage collector, and pass the flag --enable-gc to configure. The xmllint and xsltproc programs to build this manual and the man-pages. These are part of the libxml2 and libxslt packages, respectively. You also need the DocBook XSL stylesheets and optionally the DocBook 5.0 RELAX NG schemas. Note that these are only required if you modify the manual sources or when you are building from the Git repository. Recent versions of Bison and Flex to build the parser. (This is because Nix needs GLR support in Bison and reentrancy support in Flex.) For Bison, you need version 2.3 or higher (1.875 does not work), which can be obtained from the GNU FTP server. For Flex, you need version 2.5.33, which is available on SourceForge. Slightly older versions may also work, but ancient versions like the ubiquitous 2.5.4a won't. Note that these are only required if you modify the parser or when you are building from the Git repository.

The source tarball of the most recent stable release can be downloaded from the Nix homepage. You can also grab the most recent development release. Alternatively, the most recent sources of Nix can be obtained from its Git repository. For example, the following command will check out the latest revision into a directory called nix: $ git clone https://github.com/NixOS/nix Likewise, specific releases can be obtained from the tags of the repository.

After unpacking or checking out the Nix sources, issue the following commands: $ ./configure options... $ make $ make install When building from the Git repository, these should be preceded by the command: $ ./bootstrap.sh The installation path can be specified by passing the --prefix=prefix to configure. The default installation directory is /usr/local. You can change this to any location you like. You must have write permission to the prefix path. Nix keeps its store (the place where packages are stored) in /nix/store by default. This can be changed using --with-store-dir=path. It is best not to change the Nix store from its default, since doing so makes it impossible to use pre-built binaries from the standard Nixpkgs channels — that is, all packages will need to be built from source. Nix keeps state (such as its database and log files) in /nix/var by default. This can be changed using --localstatedir=path. If you want to rebuild the documentation, pass the full path to the DocBook RELAX NG schemas and to the DocBook XSL stylesheets using the --with-docbook-rng=path and --with-docbook-xsl=path options.

Nix has two basic security models. First, it can be used in “single-user mode”, which is similar to what most other package management tools do: there is a single user (typically root) who performs all package management operations. All other users can then use the installed packages, but they cannot perform package management operations themselves. Alternatively, you can configure Nix in “multi-user mode”. In this model, all users can perform package management operations — for instance, every user can install software without requiring root privileges. Nix ensures that this is secure. For instance, it’s not possible for one user to overwrite a package used by another user with a Trojan horse.

In single-user mode, all Nix operations that access the database in prefix/var/nix/db or modify the Nix store in prefix/store must be performed under the user ID that owns those directories. This is typically root. (If you install from RPM packages, that’s in fact the default ownership.) However, on single-user machines, it is often convenient to chown those directories to your normal user account so that you don’t have to su to root all the time.

To allow a Nix store to be shared safely among multiple users, it is important that users are not able to run builders that modify the Nix store or database in arbitrary ways, or that interfere with builds started by other users. If they could do so, they could install a Trojan horse in some package and compromise the accounts of other users. To prevent this, the Nix store and database are owned by some privileged user (usually root) and builders are executed under special user accounts (usually named nixbld1, nixbld2, etc.). When a unprivileged user runs a Nix command, actions that operate on the Nix store (such as builds) are forwarded to a Nix daemon running under the owner of the Nix store/database that performs the operation. Multi-user mode has one important limitation: only root can run nix-pull to register the availability of pre-built binaries. However, those registrations are shared by all users, so they still get the benefit from nix-pulls done by root.

The build users are the special UIDs under which builds are performed. They should all be members of the build users group (usually called nixbld). This group should have no other members. The build users should not be members of any other group. Here is a typical /etc/group definition of the build users group with 10 build users: nixbld:!:30000:nixbld1,nixbld2,nixbld3,nixbld4,nixbld5,nixbld6,nixbld7,nixbld8,nixbld9,nixbld10 In this example the nixbld group has UID 30000, but of course it can be anything that doesn’t collide with an existing group. Here is the corresponding part of /etc/passwd: nixbld1:x:30001:65534:Nix build user 1:/var/empty:/noshell nixbld2:x:30002:65534:Nix build user 2:/var/empty:/noshell nixbld3:x:30003:65534:Nix build user 3:/var/empty:/noshell ... nixbld10:x:30010:65534:Nix build user 10:/var/empty:/noshell The home directory of the build users should not exist or should be an empty directory to which they do not have write access. The build users should have write access to the Nix store, but they should not have the right to delete files. Thus the Nix store’s group should be the build users group, and it should have the sticky bit turned on (like /tmp): $ chgrp nixbld /nix/store $ chmod 1775 /nix/store Finally, you should tell Nix to use the build users by specifying the build users group in the build-users-group option in the Nix configuration file (usually /etc/nix/nix.conf): build-users-group = nixbld

The simplest setup is to let root own the Nix store and database. I.e., $ chown -R root /nix/store /nix/var/nix The Nix daemon should be started as follows (as root): $ nix-worker --daemon You’ll want to put that line somewhere in your system’s boot scripts. To let unprivileged users use the daemon, they should set the NIX_REMOTE environment variable to daemon. So you should put a line like export NIX_REMOTE=daemon into the users’ login scripts.

It is also possible to let the Nix store and database be owned by a non-root user, which should be more secureNote however that even when the Nix daemon runs as root, not that much code is executed as root: Nix expression evaluation is performed by the calling (unprivileged) user, and builds are performed under the special build user accounts. So only the code that accesses the database and starts builds is executed as root.. Typically, this user is a special account called nix, but it can be named anything. It should own the Nix store and database: $ chown -R nix /nix/store /nix/var/nix and of course nix-worker --daemon should be started under that user, e.g., $ su - nix -c "exec /nix/bin/nix-worker --daemon" There is a catch, though: non-root users cannot start builds under the build user accounts, since the setuid system call is obviously privileged. To allow a non-root Nix daemon to use the build user feature, it calls a setuid-root helper program, nix-setuid-helper. This program is installed in prefix/libexec/nix-setuid-helper. To set the permissions properly (Nix’s make install doesn’t do this, since we don’t want to ship setuid-root programs out-of-the-box): $ chown root.root /nix/libexec/nix-setuid-helper $ chmod 4755 /nix/libexec/nix-setuid-helper (This example assumes that the Nix binaries are installed in /nix.) Of course, the nix-setuid-helper command should not be usable by just anybody, since then anybody could run commands under the Nix build user accounts. For that reason there is a configuration file /etc/nix-setuid.conf that restricts the use of the helper. This file should be a text file containing precisely two lines, the first being the Nix daemon user and the second being the build users group, e.g., nix nixbld The setuid-helper barfs if it is called by a user other than the one specified on the first line, or if it is asked to execute a build under a user who is not a member of the group specified on the second line. The file /etc/nix-setuid.conf must be owned by root, and must not be group- or world-writable. The setuid-helper barfs if this is not the case.

To limit which users can perform Nix operations, you can use the permissions on the directory /nix/var/nix/daemon-socket. For instance, if you want to restrict the use of Nix to the members of a group called nix-users, do $ chgrp nix-users /nix/var/nix/daemon-socket $ chmod ug=rwx,o= /nix/var/nix/daemon-socket This way, users who are not in the nix-users group cannot connect to the Unix domain socket /nix/var/nix/daemon-socket/socket, so they cannot perform Nix operations.

To use Nix, some environment variables should be set. In particular, PATH should contain the directories prefix/bin and ~/.nix-profile/bin. The first directory contains the Nix tools themselves, while ~/.nix-profile is a symbolic link to the current user environment (an automatically generated package consisting of symlinks to installed packages). The simplest way to set the required environment variables is to include the file prefix/etc/profile.d/nix.sh in your ~/.bashrc (or similar), like this: source prefix/etc/profile.d/nix.sh