Introducing flox - Nix for simplicity and scale

We think Nix is one of the few technologies left in the world that’s extremely powerful but still too difficult for many engineers to use. flox is trying to change that—to get the world building with Nix. We think it’s too good to be anything less than the de facto standard for packaging software.

Sign up for the closed beta to use it and help us shape its future. It’s free and available for all Linux distros, including NixOS. (MacOS support is coming soon). We’d love to hear what you think of it and see what you use it for.

What is flox?

flox is a platform for installing, building, and deploying Nix packages. Our users think it makes Nix simpler for individuals and more scalable for teams. At a 30,000 foot view, flox’s main technical innovations are that it:

  1. Provides all users shared access to a unified Nix store, managed by a single Nix daemon and backed by a farm of powerful build hosts
  2. Distributes the contents of the shared Nix store to all endpoints on-demand with local caching and automatic background garbage collection
  3. Instantly synchronizes Nix profiles globally and provides web and command line interfaces for managing them
  4. Exposes a new command line interface that makes writing Nix expressions easier for novices
  5. Creates a new framework for organizing Nix expressions which facilitates continuous integration

And don’t worry: flox accomplishes all of this without interfering with your local Nix store and daemon on NixOS.

Why did you build flox?

The histories of many visionary technologies include periods where they’re only adopted by the best engineers solving the hardest problems. Over time, the core technology evolves, and follow-on projects tear down the barriers to adoption less sophisticated users faced:

We think that today Nix is somewhere between these extremes. The community is growing faster than ever, and Nixpkgs has become one of the most active open source projects of all time. But Nix adoption is still much lower than Kubernetes and Docker adoption. More importantly, it’s much lower than it ought to be.

That’s why we built flox at the D.E. Shaw Group—to solve the problems our developers faced adopting Nix at scale. Now, with help from @grahamc and @Infinisil, we’re sharing flox with other developers to address the challenges they face adopting Nix too. Ultimately, we want to see more people contributing to Nix, Nixpkgs, and NixOS and using the awesome tools you’ve built on top of them.

flox is currently in a very early stage beta (expect bugs!). We plan to continue improving the tooling, documentation, and performance, but we didn’t want to wait any longer before sharing it with you. We want to see what creative applications you find for it and what you think we should build next! Eventually, we may build a stand-alone business around flox. But for now, we’re just looking for feedback.

Why should I care if I’m already using Nix?

Our early beta testers have highlighted 3 main ways flox enhances Nix:

  1. Improved collaboration experience
  2. Simplified continuous integration and continuous deployment for Nixpkgs (CI/CD)
  3. Faster development cycles

Improved collaboration experience

We designed flox from the ground up specifically to facilitate collaboration. When evangelizing Nix, we identified three main barriers to collaboration:

  1. Everyone on a project needed to run their own Nix daemon and manage their own store, which introduced reproducibility problems (e.g. the same path could contain different bits) and frustrating overhead sharing/deploying build artifacts
  2. Profiles were isolated on individual machines, which made them difficult to use as shared development environments and deployment environments
  3. Users didn’t know where to put their Nix expressions or find other users’ expressions outside of Nixpkgs, which led to Nix expression sprawl across GitHub

The first problem motivated us to build the flox Storehouse. The Storehouse is a centralized fault-tolerant set of machines that houses a globally available Nix store and runs a shared Nix daemon, which flox relays all Nix commands to.

With this design, users don’t need to install Nix everywhere they want to use it. When a machine traverses a /nix/store path, flox automatically downloads the required packages from the central store and caches them locally until they’re not needed anymore. This gives all our users local Nix performance with no configuration/maintenance overhead.

This also eliminates Nix daemon version control and reproducibility problems. Everyone is using the same daemon and receiving artifacts from the same central store. That means /nix/store/11zj...kfr2-foo is bit-for-bit identical across all developer machines and servers.

To address profile isolation, we built a new profile manager that instantly synchronizes profile generations and contents across machines, along with a CLI and web app for interacting with it.


This allows flox profiles to act as portable development and deployment environments, which can be accessed using the same paths anywhere. Just by using the same profile, multiple developers can keep their tools and packages in-sync to iterate and collaborate more easily. And sys admins can update everyone’s tools with a single command.

Global profiles also makes deploying, updating, and rolling back packages across multiple machines transactional and atomic. All it takes is a single click in the web app or a single floxpm upgrade command.

To address Nix expression sprawl, we developed a unified framework for organizing Nix expressions in git servers, which we refer to as the “Nixexprs framework”.

The framework uses orgs/users on a git server as the first-order unit of organization. It arranges the Nix expressions for each org’s packages in a repo named “nixexprs”, which is patterned after Nixpkgs itself. Each Nixexprs repo serves as a runbook for Hydra and produces a channel of packages based on its contents.

We’ve found this system has made it easier for developers to start and join new projects, transfer knowledge about projects to other devs, and collaborate on expressions.

Faster Development cycles

We love Nix, but we wanted to make it faster. So flox adds a few performance-enhancing features:

Powerful remote build farm: Instead of building derivations on your laptop, flox builds them in a powerful remote build farm. Builds complete faster, and your machine stays available for development and other local workflows.


Lazy loading: Unlike Nix, flox loads dependencies lazily at runtime (by /nix/store subdirectory). That means flox only loads what you use, when you use it, no matter what languages you’re using. For complex packages with sprawling dependency trees, this can lead to large reductions in memory footprint.

Negative lookup caching: flox serves /nix/store with a file system that knows its contents are immutable. This allows flox to cache all negative lookups–path traversals that ultimately don’t find the requested files–and avoid re-executing them unnecessarily. This produces significant runtime speed increases, especially for languages known to execute many negative lookups (e.g. Python).


Simplified CI/CD for Nix packages

Together, our Nixexprs framework and global profiles allow users to rebuild Nix packages with a simple git push and deploy them anywhere with floxpm upgrade:


Our profiles have automated upgrade schedules by default, so the second command isn’t even necessary.

How I can I get my hands on it?

  1. Sign up for the private beta - flox is a work-in-progress, so expect some bugs. But don’t shy away from trying to break it. :slight_smile:
  2. Request access to our Discourse – Our users post bugs, questions, and feature requests there.
  3. Email if you’re interested receiving an enterprise demo or private instance.

We’re looking forward to hearing what you think of flox and making it better for you.

Where can I learn more?

@zimbatm is interviewing me and @limeytexan about flox on Nix Friday on February 5th at 16:00 UTC. We’ll demo a few features and chat about why we built flox, the implementation, and what we think the most exciting uses are for individual devs and teams. Tune in to ask questions and learn more!

- The flox team


This looks really cool! Can’t wait to get my hands on it. Will the client side tooling be open source?


Great question, and honestly, we don’t know yet. To get flox out the door as fast as possible, we pushed off thinking about open sourcing.

For now, we’re just trying to see if anyone wants to use it. If people think it’s useful, we’ll start having conversations with our users about what we can open source.

After all, Nix and Nixpkgs are great examples of the fact that not every code base can be supported by 1 entity.


I have to confess that I was very sceptic when this announcement was posted, it felt somehow overwhelming and too commercial. And the closed Beta testing where you have to agree with the terms and conditions didn’t seem that “open” to me.
After watching the Nix Friday video I love the way this has been setup, you’re explanations and the hard work that has gone into it!
A lot of people have clicked on the Beta link so I do hope you get the input you are hoping to get from all this testing. I think this right now is already so polished and smooth that it will be a great incentive for company’s and enterprises to get their feet into the Nix world, finally…
Not withholding anymore because of a perceived hard learning curve to get Devs up and running with Nix. I hope that you, new company’s and everyone using Nix(OS) will benefit from this. Thanks!


Thanks for the well-wishes, and I’m really glad you enjoyed the stream! @zimbatm is a great host, and we had a lot of fun with it! Right now, we’re just excited to hear what the community thinks of efforts (for better or worse)!


I consider that your (excellent) fuse fs approach with a remote store should graduate into standard nix tooling, so that it can be used whenever a server agrees to provide enough bandwidth to serve the users’ filesystem on demand (like in controlled environments).

This might yield the broader nix a real competitive edge as a thought model on binary distribution strategies (in combination with upcoming trustix).

Note that the k8s explores a similar approach for image path loading.

I hope you won’t be tempted to declare it competitive USP for flox for too long. :wink: It might be too groundbreaking to promote the greater good out-of-tree on the long term.

At least, there might arise a risk of a technical split brain when the ecosystem eventually tries to reimplement this. I wish you all the best luck to lead the (community’s) way in that regard! :+1:


Glad you like the FUSE approach! It works really well for us because it gives us access to the entirety of Nix store anywhere (including edge devices) and simultaneously on thousands of machines without trying to predict what each machine might need or actively manage local caches.

We’d love to work with the Nix community to graduate some of our work to standard tooling or otherwise API-ify and document it in a way that makes it more accessible without plugging into the entire flox ecosystem (that can be a lot to ask). A lot of users are requesting we open source various components of the stack (and we could use some help!), so this is top of mind for us right now.


A quick flox update and thank you

I just wanted to say thank you briefly to the community for the warm welcome we’ve received so far and share a few things we’re working on to make flox better for you!

We’ve had more than 160 people sign up for the beta, 80 join our Discourse, and a dozen join our Slack. You guys have also shared a lot of ideas for making flox better that we’re working on now:

  1. The ability to download the full contents of a profile, so you can take it on the go (This is out now under floxpm download)
  2. A watcher to see the progress of your lazy downloads, so you know why your commands are hanging
  3. Support for installing flox on NixOS configured with flakes
  4. A more intuitive dialogue for initializing Nix expressions (flox init)
  5. A MacOS client
  6. Loads of minor bug fixes

A few people had problems logging in (because github is case insensitive but we/Nix aren’t!) that we’ve sorted out now. And @grahamc has been hard at work making Hydra more efficient for us and the Nix community.

We’ve also had many people request we open source parts (or all) of flox, and we’re trying to figure out the best way to do this. It’s slow going (thanks to lawyers), so thanks for your patience.

Special thanks to @jD91mZM2 @castrojo @stolyaroleh @edolstra @lheckemann @robertodr @DieracDelta @zimbatm for especially detailed feedback!

We’re going to continue pumping out updates to make it easier to bring to Nix to work.


Just got around to watch the Nix Friday episode on Flox, and I liked the remark on how Flox compares to Nix community innovations (flakes, in this case), and putting it into the context of intra- (Flox) vs inter-organizational (flakes) collaboration.

The future of Flox is uncertain (business model, open sourcing, etc.) but it is easy to see how it would help organizations to set up a uniform developer experience and environment; yes, one could set up a Hydra build-farm, create internal workflow instructions on how to use Nix, but that’s an overhead that is discouraging and can also be a huge barriers to adopting Nix. For instance, I work for a small non-profit whose leaders boldly decided to develop some software projects in-house, and everyone can tell that the actual dev work in such a setting is only a small percentage compared to operations, compliance, security, etc. matters. Flox would only alleviate a moderate part of the situation, but it would still be a big win, both in the short and in the long term.


I would realy love to see an update on things “all Flox”.
Could there perhaps be a follow up online meeting to discuss more about the Flox inners and the way it has been working for others? Or explaining more how using Flox will/would benefit companies willing to dive into using Nix?


Hi @JosW !
Quick intro as this is one of my first messages here! I just joined Flox as CEO after leading developer products at Facebook.
In brief, we are diving deep into how Flox can both contribute to the Nix ecosystem and drive more enterprises, teams and engineers to Nix. It’s a tough nut to crack and we strongly believe that doing so would put Nix at the top tier of the development vocabulary. I would love to hear your thoughts and set up some time to talk about the topics you raised here. We can even turn this into a small roundtable with anyone else that might be interested if you are up to it.


Frankly, this concerns me. “Drive more people to Nix” sounds great on the surface of it, but will they actually be driven to Nix, or specifically to flox as an indispensable usability layer over it?

With there being no clear commitment to open-source and community engagement that I can see (in this thread anyway, please correct me if I’m wrong!), I’m concerned that this would siphon momentum from the Nix project itself (and more importantly, the drive to improve it), in favour of what is essentially a proprietary, commercial product.

Shouldn’t improved usability ultimately be something that’s a part of Nix itself, instead?


Thanks for your comment @joepie91 ! There’s been a lot of changes on our side, (including making Flox its own company), so we may have lost some stuff in translation. I’m also still learning because I just started a couple weeks ago.Let me be very clear about a few things:

  1. Flox is committed to open source. Everyone at our company is a developer. We understand the importance of free software. We will open source or commit code upstream whenever it makes sense. If anything remains closed source at all, it will only be functionality that specifically matters to teams and enterprises (think analytics, security enhancements, compliance, logins. etc…) or services that run on our machines. I promise more of the code in the beta will be open sourced when we can get around to it, and I’ll set a proper policy in the future.
  2. Flox is committed to making technical contributions to the Nix ecosystem. We have already made many direct contributions to Nix, Hydra, and Nixpkgs. We have many more on our roadmap. We’re also drafting our first official RFC now! If we just wanted to be a usability layer, we would keep that stuff to ourselves.
  3. Flox is committed to supporting the Nix community. @tomberek spends some of his time at work serving as a NixOS release manager, holding Nix office hours for the community, and helping the marketing committee figure out how to drive more folks to Nix directly . This kind of work is literally in the job description because we believe Flox wins when Nix wins.

If we pull it off, there will be more jobs for Nix users, more donations in support of Nix projects, and more contributors in the ecosystem.I’m excited to dig in on the details of all of this in the coming months, and I’d welcome a round table. Please reach out to me at if you want to chat.

Hosted by Flying Circus.