What Is Guix Really?

an advanced distribution of the GNU operating system

‑ the GNU Guix website

a purely functional package manager, and associated free software distribution

‑ the Guix subreddit

I find these descriptions uninspiring and wouldn't be so excited about Guix if that's really all it was. So what is Guix really, how does it relate to these descriptions, and what makes it so compelling and different?

Guix is a Universal Software Deployment System

Guix puts software and data onto computers, following your plan. In that sense, its closest competitors might be Ansible, Chef, or Docker. But it's a more useful and capable technology than any of those because its underlying model is so expressive. It provides a collection of composable building blocks to create and organize systems of any complexity and deploy them to any computer, all using declarative code.


When you run software with Guix you take total control over the how and where, without having to use different tools and processes depending on your choice. You can run software normally on your machine, or in a container, in a virtual machine, on some other machine, or across a cluster of remote machines, by providing different configurations. And when you change your mind as the situation evolves, the tool follows.

Containers & VMs are truly optional in Guix. The reproducibility of your deployments does not rely on containerizing or virtualizing every application, so the decision of whether to run uncontained on bare metal, in a container, or virtualized, is up to your choice rather than being imposed upon you by the platform.


Guix is comfortable at any scale. While it can deploy systems across a whole cluster, it's just as easy on a single-user machine. This doesn't require simulating a cluster or installing a stripped-down mini version of the software, because Guix only loads the building blocks you need to operate at the scale you ask for.

You can use Guix to deploy your developer tools like vim and git onto your own machine. That's where the comparisons of Guix to a "package manager" come from: installing software on your own machine is just as easy as with apt or brew, just guix install vim and you're set. But with a little more configuration, it can also deploy a complex service, eg. Ruby + Rails + Postgres + nginx. Or it can deploy an entire operating system on a single computer or on a whole clusters of machines. You scale-up by providing a configuration that invokes more components of Guix, activating them to orchestrate deployment on whatever scale you care about in the scenario.

Guix views an operating system as just a big collection of software and data, organized into services. Just as you can deploy a single service on your computer, you can scale that up and deploy the whole set of them that comprises an operating system. The Guix System is a full ready-to-use operating system defined entirely using Guix in terms of software packages and services, and you can use it as a template to deploy any kind of operating system you can imagine. This is where the descriptions of Guix as a "distribution" come from: because Guix is so powerful and general, you can use it in place of a traditional operating system distro.


Using Guix to deploy your software helps make it resistant to bitrot, configuration drift, and all the forces of entropy. That's because every build, deploy, and configuration using Guix is designed to be byte-for-byte reproducible, and it automates the creation of detailed provenance files describing the names, versions, and configurations of every single piece of software that's part of the deployed system.

Once you get software working on your own machine, you want to ship it to other machines and be able to trust it'll work there too. Guix makes that realistic. It isolates packages and builds from the host system and from one another so they don't interact in any ways you don't define explicitly. It can also create pure isolated execution environments for development and testing to help you ensure that your software will work the same wherever it's deployed.

Many language ecosystems also to go great lengths to deliver this same sort of experience. But Guix does it in a way that is independent of languages or build tool and spans the full stack. Often the odd dependencies become the trickiest part of installation and deployment, but because Guix is universal it tackles the whole problem with one tool set.


These capabilities arise from a design which uses a collection of composable building blocks to create systems of any desired scale and complexity. You can reuse them as a library and extend them with your own blocks to create new ways of describing and deploying systems. For example, the Guix Workflow Language extends Guix with tools for managing scientific data workflows.

Guix is totally programmable and fully compatible with infrastructure-as-code. The definition for every object in Guix, from an origin (describing the location and metadata of some source code) to a package, service, or operating-system, is all just code. We provide a rich set of domain-specific languages for writing declarative descriptions, which you can extend with your own logic.

Guix Makes Many Software Problems Optional

The uniformity and expressiveness of Guix allow you to avoid entire classes of problems with software deployment that we typically use a collection of tools to handle.

Fetch and manage versions of your runtimes and dependencies

If you use Ruby you might be familiar with rvm, gem, and bundler, the tools for managing installed versions of Ruby, fetching Ruby libraries, and collecting sets of Ruby libraries that comprise the dependencies for a service, respectively. If you also use Python you might be familiar with pyenv, pip, and pipenv, which perform the same functions for Python. In general, we might say that if you use N languages, you likely use some multiple of N, N×C, language-specific tools to manage the tools and libraries you use.

Guix replaces all these tools. It can fetch the version of the compilers and language runtime you want and all your dependencies, and it can provide a file describing the complete provenance of that software, comparable to a lockfile. And even better, you're free to use a single manifest and lockfile to describe all the runtimes, dev tools, and dependencies for your project, no matter how many language ecosystems they span.

Avoid version conflicts

If you run many versions of a service on your local machine, you may be familiar with tools like bundler, virtualenv, and docker which allow you to create separate, disjoint environments for each version of the service to avoid conflicting versions of dependencies. Dependency conflicts happen when many different pieces of code want to have the same name on your system. These listed tools avoid conflicts by creating many copies of your dependencies in different folders for each project.

Guix sidesteps this problem entirely by addressing every package and every file using unique hashes instead of potentially-conflicting global names. It doesn't need to make a copy for every project, because each version you want has a globally unique name you can depend upon directly. You won't need to type those hashes or hard-code them into your scripts or other build tools, because Guix provides hooks to set environment variables similar to how the above version management tools work.

Treat deployment problems as optional

Guix doesn't try to forbid you from using these tools you might be familiar with. It'll happily install them for you. But wouldn't it be nice to treat these tools as viable solutions to an optional problem, a software deployment wrinkle that you can opt-out of if it becomes too complex? Using Guix gives you the freedom to make the best technical decisions about how to manage your dependencies without feeling forced to use all these language-specific tools out of necessity.

Guix is Radically Free

Every part of Guix is free software according to the Free Software Definition, and the Guix project as a whole meets the much higher standards of the Free System Distribution Guidelines. Beyond that, the design of Guix is carefully thought-out to help you make practical use of your freedom.

Take control of your upgrade cycle

Guix never requires you to upgrade the version of a package system-wide just to deploy some other package. You can choose to keep some packages extremely stable and update them on a slow regular cadence, while deploying bleeding edge versions of others, and it won't cause you any hassle.

You aren't restricted to the versions of packages provided by the Guix upstream project. When deploying software you can always specify a specific version, tag, branch, commit hash, or even provide your own patches.

Guix puts you totally in control of what you deploy, so you don't need to upgrade when a distro maintainer says it's time or wait for them to provide a new version you want to use.

Bring your own libraries, tools, and other software

You can add definitions for your own internal packages, services, and operating systems to Guix. These do not have second-class status: they get all the same powers, bells and whistles as what you get from Guix upstream. You can add one or more internal channels to your Guix configuration to extend it in any way you like. You can also publish a channel to your organization or to the world.

The Guix project does not maintain any kind of gatekeeper role. While Guix itself is radically free, we pass that freedom on to you in its entirety to be a full member of our ecosystem and publish any software using any business model, licenses and terms you deem appropriate.

So That's What Guix Is!

The Guix project is backed by a non-profit foundation and maintained entirely by volunteers. It has no backing from venture capital, no enterprise product, and no advertising. If you want to see it grow and succeed at bringing universal deployment to the whole world, please consider contributing your skills in one of the many areas we need help, or making a donation to the project!

More resources