Nix is a system for the deployment of software. Software deployment is concerned with the creation, distribution, and management of software components (packages). Its main features are: It makes sure that dependency specifications are complete. In general in a deployment system you have to specify for each component what its dependencies are, but there are no guarantees that this specification is complete. If you forget a dependency, then the component will build and work correctly on your machine if you have the dependency installed, but not on the end user's machine if it's not there. It is possible to have multiple versions or variants of a component installed at the same time. In contrast, in systems such as RPM different versions of the same package tend to install to the same location in the file system, so you installing one version will remove the other. This is especially important if you want to have use applications that have conflicting requirements on different versions of a component (e.g., application A requires version 1.0 of library X, while application B requires a non-backwards compatible version 1.1). Users can have different views (profiles in Nix parlance) on the set of installed applications in a system. For instance, one user can have version 1.0 of some package visible, while another is using version 1.1, and a third doesn't use it at all. It is possible to atomically upgrade software. I.e., there is no time window during an upgrade in which part of the old version and part of the new version are simultaneously visible (which might well cause the component to fail). Likewise, it is possible to atomically roll back after an install, upgrade, or uninstall action. That is, in a fast (O(1)) operation the previous configuration of the system will be restored. This is because upgrade or uninstall actions doesn't actually remove components from the system. Unused components can be garbage-collected automatically and safely. I.e., when you remove an application from a profile, its dependencies will be deleted by the garbage collector if there are no other active applications that are using it. Nix supports both source-based deployment models (where you distribute Nix expressions that tell Nix how to build software from source) and binary-based deployment models. The latter is more-or-less transparent: installation of components is always based on Nix expressions, but if those expressions have been built before and Nix knows that the resulting binaries are available somewhere, it will use those instead. Nix is flexible in the deployment policies that it supports. There is a clear separation between the tools that implement basic Nix mechanisms (e.g., building Nix expressions), and the tools that implement various deployment policies. For instance, there is a concept of Nix channels that can be used to keep software installations up-to-date automatically from a network source. This is a policy that is implemented by a fairly short Perl script, which can be adapted easily to achieve similar policies. Nix component builds aim to be pure; that is, unaffected by anything other than the declared dependencies. This means that if a component was built succesfully once, it can be rebuilt again on another machine and the result will be the same. We cannot guarantee this (e.g., if the build depends on the time-of-day), but Nix (and the tools in the Nix Packages collection) takes special measures to help achieve this. Nix expressions (the things that tell Nix how to build components) are self-contained: they describe not just components but complete compositions. In other words, Nix expressions also describe how to build all the dependencies. This is contrast to component specification languages like RPM spec files, which might say that a component X depends on some other component Y, but since it does not describe exactly what Y is, the result of building or running X might be different on different machines. Combined with purity, self-containedness ensures that a component that works on one machine also works on another, when deployed using Nix. The Nix expression language makes it easy to describe variability in components (e.g., optional features or dependencies). Nix is ideal for building build farms that do continuous builds of software from a version management system, since it can take care of building all the dependencies as well. Also, Nix only rebuilds components that have changed, so there are no unnecessary builds. In addition, Nix can transparently distribute build jobs over different machines, including different platforms. Nix can be used not only for software deployment, but also for service deployment, such as the deployment of a complete web server with all its configuration files, static pages, software dependencies, and so on. Nix's advantages for software deployment also apply here, for instance, the ability trivially to have multiple configurations at the same time, or the ability to do rollbacks. This manual tells you how to install and use Nix and how to write Nix expressions for software not already in the Nix Packages collection. It also discusses some advanced topics, such as setting up a Nix-based build farm, and doing service deployment using Nix. This manual is a work in progress. It's quite likely to be incomplete, inconsistent with the current implementation, or simply wrong. Some background information on Nix can be found in two papers. The ICSE 2004 paper Imposing a Memory Management Discipline on Software Deployment discusses the hashing mechanism used to ensure reliable dependency identification and non-interference between different versions and variants of packages. The LISA 2004 paper Nix: A Safe and Policy-Free System for Software Deployment gives a more general discussion of Nix from a system-administration perspective.