Show HN: Flox 1.0 – Open-source dev env as code with Nix (opens in new tab)

Appreciate the call out. Regarding pricing, bringing forward what you saw today for free and open source, was a major part of why I started Flox, with much more to come into it. What we released today will be free forever (both the open source client and the FloxHub services for sharing environments). We plan on expanding the offering to include a more robust private software catalogs that layers on top of the OOTB Flox Catalog that ships with Flox. If you are interested in publishing your output or need revised versions of open source packages in Flox then it'll be very easy to have your own catalog to compliment the always-free Flox Catalog that Flox ships with today. Beyond that, we are focused on a number of services that help bring Nix's build to the enterprise. Over time we intend to sell a solution to enterprises - through subscriptions and services - so they can more effectively manage expansive and fragmented software supply chains. As part of developing custom tooling for enterprises, we think it's reasonable for them to participate in funding for that work.

> Crunchbase links to news articles that make it seem like you've raised $24MM.

Oh wow. I really don't see a way to a $2.4B exit here. Good luck!

"Flox began its life during the deployment of Nix at the D. E. Shaw group, where it quickly proved invaluable by making Nix easier for newcomers".

Is that the line you are referring to? Sounds like the opposite of what you suggests it says.

I read that as Flox makes nix easier for newcomers, not that nix is easy for newcomers.

Exact same experience here. Been fiddling with nixos for quite a while, but never got comfortable with .nix or flakes. The base concepts keep escaping my mind, I have to revisit every time I have to configure something new and I just got tired. Issues are difficult to debug and you have to go through very specific commands and a hellish filesystem to understand what's going wrong. I love the concept, but I feel like it just gets too much in my way.

I love nix and have contributed quite a few packages to the nix repository, and I will vouch that it’s anything but easy. I have a background in Haskell which makes it more familiar, but even the syntax is counterintuitive to newcomers.

Hard agree. I see the advantages but the initial learning curve is incredibly steep. Funny how this mimics my experience with Rust.

Agreed on the experience, hard to onboard. I looked at devenv.sh as easier way to get going. Implemented all with Nix, less lock-in. Just found std [0] and that looks quite promising too.

[0] https://std.divnix.com/

I think once somebody solves the hellish configuration with another language that people can actually understand NixOs will take off. I mean, I hate js as much as everybody else, but I’d rather use that to configure nix than whatever that thing is that they use now.

I used the repl from day 1 and it was so intuitive. No other alternative has a repl (besides guix I guess)

Supporting rollback and history means disks can fill up. With Nix, this is usually due to a bunch of GC roots pointing to profiles and packages that then cannot be cleaned up. Our environments are not just symlinks, but have a declarative format (under the hood, flakes) so one can remove them, but also reproduce them as needed. So GC'ing them is less destructive than with using `nix-env`/`nix profile`. This allows us to be more aggressive in cleaning up old generations.

So the strategy is to ensure there is always a declarative+reproducible way to recover the things you clean up, then we can apply various heuristics to avoid disks from filling up; free space, age, least-recently-used, least-frequently-used - are all being considered.

As opposed to Docker, or Bazel?

Conversely I have never had this problem with Nix. It tells you plainly how to clean up garbage. It's easy to interrogate to find out what's hanging around, and why. The reason it's not on by default is that, like any garbage collector, it can be disruptive -- there is no "one size fits all" policy.

Ultimately if you have too many gc roots you have to make some decisions.

Nix supports garbage collection.

Also there are literally thousands of insanely complex things happening behind the scenes every time you use your computer. Not sure why Nix is considered special when abstracting over it.

We have the same problem with bazel at work, after a few months your machine is running out of disk space

Just set nix garbage collect to run every thirty minutes.

> What's your story for dropping down into 'real Nix' if required?

We already have talked about this and plan to allow using Nix itself in those cases where someone needs the additional power. The current thought is to have allow a either a reference to a flake for specific fields or to have an Nix-style entrypoint.

This is not yet exposed or documented. Stay tuned.

aside: absolutely agree that there is a fine line between hiding complexity and exposing power

Flox employee here! To start off by addressing how this relates to nix tools:

- Our goal is to be more user friendly. You don't have to learn the Nix expression language or understand nix internals to be successful.

- We've been able to add some opinionation and polish. Some of that is subjective, but some examples are:

  - We have a hybrid imperative/declarative interface. You can `flox install && flox list`, and those changes are reflected in TOML. Whereas with `nix develop` you have to edit a Nix expression

  - `nix develop` drops you into a bash shell, whereas `flox activate` can drop you into a bash or zsh shell (and we plan to add support for fish)

- We support using git to manage environments just like nix tools do, but we've also added the option to share flox environments in ways you can't with any of those tools (flox push/flox pull/flox activate -r) and the ability to view environments in ways we feel can be more user friendly. If you create an account, you can see packages I have in my environment at https://hub.flox.dev/mkenigs/default, or if you have the CLI, you could inspect my environment with `flox list -r mkenigs/default` before using it with `flox activate -r mkenigs/default`. I think that's much more digestible than linking a flake.nix to someone who doesn't know the Nix expression language

Put another way, I would think that individual engineers would be better off learning the underlying tech and the tools provided that go with them. I think it's very possible that Flox (or devenv or...) reaches EOL, or ceases to track nixpkgs appropriately, or any of the other ways that software rots. Where nix develop is going to last as long as Nix Flakes do, and there's incentive to provide a migration path to whatever's next.

Even more important: every abstraction is going to leak. Maybe the Flox CLI "looks" cleaner or whatever, but in the end you'll still need to learn Nix to use it effectively. Why learn twice as much stuff as you need?

Or https://devenv.sh

I just want clean, repeatable environments for different projects. I’ve tried getting into Nix a few times but I always get overwhelmed by all the different things it is/does. This looks 100x simpler to me.

I understand that Nix solves many problems and indeed bet on its ability to do so. It is why I've put so much effort into Nix itself.

However, Nix poses a relatively steep learning curve being built up from first principles making it very general. Flox aims at simplifying this by narrowing the problem field and providing specialized abstractions and interfaces for those who want to benefit from nix' capabilities without needing to becoming a nix expert at day 0.

(flox employee)

Selling coworkers on flox or devenv is way easier than Nix.

Thanks for asking! This is definitely a deeper lets get beers convo when you're in the bay! But - Have you ever seen the Microservices video? https://www.youtube.com/watch?v=y8OnoxKotPQ

I was leading the developer products team at Facebook back then and started a project around injecting remote capabilities into local dev. Short of it was that thousands of developers were waiting 45 minutes for cold builds... Part of the initial steps for the project was to map out the entire SDLC (so we can get a sense of what parts of the toolchains we need to rebuild), that's where that video above comes into mind if you look at that whiteboard towards the end... Visualizing how complex we've made it is what got me into the headspace of - this can't actually be how we go about this.

I believe so, it seems like almost all (or all?) solutions listed here: https://news.ycombinator.com/item?id=39696038 use flakes underneath.

I think the flakes problem come from two things:

- flakes are labelled experimental for years now (I think it might be almost 5 years now) which creates confusion with new users, but they are universally used nearly everywhere now - there seems to be some bad blood[1] between https://determinate.systems/ company and the long time Nix users and developers who are accusing them that they are using Nix for their benefit with not contributing back. From my understanding Determinate Systems introduced flakes and probably this why there's some resistance to it by some.

But to answer your question, pretty much everyone adopted flakes and guides that don't use them are most likely old.

[1] https://discourse.nixos.org/t/introducing-flakehub/32044

I don’t know anyone who is recommending against flakes these days. The “experimental” label is more about the API stability than completeness, bugginess, or anything else.

There are certain scenarios where the performance can be problematic, but there are workarounds and permanent solutions are being worked on. Nevertheless, using flakes extensively at home and work.

See: A plan to stabilize the new CLI and Flakes incrementally https://github.com/NixOS/rfcs/pull/136

Hey there! Looks like you may have missed the Nix/Generic and Nix/NixOS tabs at https://flox.dev/docs/install-flox/? Do those satisfy the side by side use case you’re talking about?

I think the best way to use fish at the moment is `FLOX_SHELL=zsh flox activate -- fish`. That doesn’t support aliases but should mostly work

Are you hoping to actually hack on the source or just trying to understand how to come up with a workaround? We error for any shell other than bash or zsh somewhere around https://github.com/flox/flox/blob/9e18a3ceaa185006bae95a4827... If you want to take a crack at hacking on it I’d be more than happy to give more background!

Using Nix as a package manager works best with a repository called "Nixpkgs".

Nixpkgs focuses on reproducible builds, that means that for the same inputs, you always are going to get the same binary output.

All of Nixpkgs are built using nixpkgs, and they don't depend on any library outside nixpkgs, including glibc and compilers.

That means that you can "lock" your packages into a version, and you ensure that it will run the exact same version and configuration in all machines that you install it, no matter the underlying OS or how old/new it is, glibc problems etc...

This is the power of Nix.

All of this can be done via a simple

Flake.nix -> define the system Flake.lock -> automatically generated, defines the exact version of nixpkgs among others.

(Can also be done via channels but flakes are better imo)

Nix runs alongside other distributions in various OSs, including OSX. (Windows is being looked at, do not hold your breath.)

The cross-platform capability of `flox` comes from our usage of Nixpkgs, which includes allowance for some of the differences between platforms and makes them less of an issue.

If some piece of software has a specific difference when run on different platforms and you rely upon that difference, then your need to use that platform in some way: native, VM, translator, etc. Nix does make it easier to manage, build, distribute, multiple kinds of software.

Flox environments leverage this same foundation to expose the same environment on multiple systems and we plan to work on this more. What in particular would you be looking for?

> The rise of Arm workstations has made this interesting, but Debian 12 on Amd64 is still a heck of a lot closer to Debian 12 on Arm64 than it is to macOS or Windows on anything.

The kind of default/minimum reproducibility for most Nix-based deployments is basically a stronger version of this. It's like 'Debian 12 on AMD64 with all the exact versions and non-arch-specific build flags of all packages exactly pinned is very similar to Debian 12 on ARM64 with all package versions and non-arch-specific build flags pinned to the exact same thing'.

> Sure, some things work the same or close-enough to the same, but even with scripting languages (no aot compiling) that have pretty good cross platform support, there are differences either in features, extensions, or in system level dependencies (i.e. a database server, cache server, etc).

This is worth digging into.

> there are differences either in features, extensions

Nix will guarantee for you that you always get the exact same features and extensions unless it's truly the case that a feature is just not available on some platforms. So it takes care of differences that come from different operating systems and distros using different ./configure flags and so on.

> or in system level dependencies (i.e. a database server, cache server, etc)

Flox and competitors like it all support local process supervision/service management as well as just adding packages to an environment, so you pin down the versions and configuration options of your DB server and cache server in the environment specification as well.

> Sure, some things work the same or close-enough to the same

For things that are genuinely different (e.g., Nix itself has different sandboxing features and support on Linux because those operating systems' respective kernels also differ in their capabilities), you are still going to want to virtualize. If your production environment is NixOS, there are some pretty nice tools available for this. Otherwise you might want to do your final testing via something like Vagrant or Tart or some custom Nix-based tooling.

But if Docker-in-a-VM is good enough reproducibility for your stack, Nix will probably be a little bit better.

I think you're looking for Nix flakes proper! This is one of the promises!

Given so, this means many tools based on nix provide this too, though it's not as easily surfaced.

Sorry you had a frustrating experience. It's definitely us missing the mark.

Re: fish, saw you found the issue someone else opened on it. We have it on our plan and will be adding support soon https://github.com/flox/flox/issues/1173

Re: your zsh experience, it's hard to judge exactly what's happening from your comment but we have had other users where the state of activation was suppressed by themes which can cause "environment already active". https://github.com/flox/flox/issues/637 - if you think it's something else or have more detail to share, let us know (either here, github, anywhere).

Thanks for trying Flox!

(Flox employee here)

`flox` needs Nix to function. So the rpm/dev/OSX installers first install Nix, and then installs flox itself.

If you have Nix already, you can try it out as described here: https://flox.dev/docs/install-flox/#install-with-existing-ni....

side-note: with further improvements to Nix as a library, it may be possible to make installing Nix not necessary for flox to function, but this is on a longer time horizon... don't hold your breath

> If I have some developers using an ARM based macbook, and some devs on an x86_64 based machine, is it easy to support both without much maintenance?

Yes.

I maintain a small collection of Nix packages at my job (some of which come straight from upstream, some of which I've written in-house and are out-of-tree) for use in development and CI environments. We currently support both Intel and Apple Silicon Macs as well as x86_64 Linux environments.

There are a couple of small OS-specific tweaks in one or two packages (which we inherit from those packages, which ship OS-specific scripts). There is no architecture-specific code in the repo; I literally never have to think about it.

Target platforms are all tested in CI. Deployment targets (users, CI runners) on all supported platforms get the exact same versions of everything, in binary form appropriate to their architecture.

One way of thinking about Nix is like A Makefile on steroids. It will build what is needed for the right platform. It is also smart enough that you can add cache server and when it needs something that already is in the cache[1] it will download and use binary package seamlessly.

Those packages are built from the same sources with same (or almost the same) configuration options and for all intents and purposes should be nearly identical.

So while you use your devenv, it will download and use the right packages for your architecture, and if something is missing on the cache server it will build it locally.

Now as ARM Mac's are as popular as the intel ones, people are making sure that the packages build on both.

[1] nix generates a hash which is based on the package source code, compile options, architecture etc. and uses that for the lookup.

The Nix binary cache does x86_64-linux, aarch64-linux, x86_64-darwin, aarch64-darwin and maybe others. Every single package is different, but built from the same source. You won't be sharing binary cache even for python or other interpreted things since they depend on "stdenv" which contains bash.

But in practice it's really easy. Though if you're all into robustness you should probably test on the same arch you deploy to eventually.

Yes. We have designs to allow for more powerful configuration for experts. A good example of this is let people use alternative manifest representations; JSON, Nix, etc.

The python ecosystem will require specific support, so at the moment we recommend using `flox` to get all of the other things that might not be managed by an existing Python package manager, and/or to install that package manager itself.

Being a general solution, `flox` cannot directly provide the same level of integration as a python-specific tool, but we CAN make it easier to use those other tools, and bring in others.

It can, but I wouldn't recommend it unless you have native dependencies that are just a pain to install. You'll loose Windows compatibility, may have to package some Python packages yourself, have a learning curve for everyone in the Python ecosystem and gain... what exactly?

Thanks for asking! I'm Michael Brantley, Flox CTO and formerly responsible for build and release engineering at the D. E. Shaw group. The high-level summary can be found in https://flox.dev/about but the back story is that I started diving into Nix in late 2017, and once I finally understood how Nix worked, how amazing the Nix community is and the incredible potential of the Nixpkgs collection I immediately realized I'd been "doing it wrong" all this time! It was then that we embarked on an effort to deploy Nix internally, but soon ran into many obstacles to enterprise adoption.

As I'm sure will be similar for many other teams, our Nix deployment started life as a series of bespoke applications and systems created to address such obstacles, but I suppose the difference in our case was that we had an internal venture studio called DESCOvery who recognized the impact that it could have on devs everywhere, and then worked closely with Ron, founding engineer Tom Bereknyei and me to launch the business. It's been an awesome journey - we hope you like it, and stay tuned for more to come!

we will always allow the CLI to stand alone for a local developer or CI runner. the service side of Flox is for those who want a faster performance, easy sharing, or eventually enterprise control. so while the CLI can use the closed service it's purely optional (and will always be optional)

Happy to take this one, as I am one of the cofounder of Daytona.

Daytona solves all the automation and provisioning of the dev environment, actually wrote an article here laying out exactly what we do: https://www.daytona.io/dotfiles/diy-guide-to-transform-any-m...

Daytona currently supports only the dev container (https://containers.dev/) "dev env infrastructure as code" standard, but are looking to support others such as devfile, nix and flox.

Hope this helps

Flox employee here, you can do that by creating an environment in your home directory and activating it in your `.bashrc` or `.zshrc` (we don’t support fish yet, but it’s on the roadmap). An environment created in your home directory is called `default` and your question is exactly its intended purpose.

Hi! Flox employee here and pulled from our Head of Product:

Flox will match the most compatible Nixpkgs version given the declaration in the manifest. We are working on a robust service to allow better searching across time to dramatically expand the amount of software available.

We're working on a few solutions to this--allowing flake references in the Flox manifest and offering a robust solution as a product feature.

Flox is compatible with language specific package manager--and provides suggestions and auto detection of existing package managers. You can use the Flox shell hook to initialize the project in the language specific package manager of choice and Flox will suggest this to you if it sees you're using a known package manager (such as requirements.txt for pip, yarn.lock for yarn, etc).

Hope this helps

Yes. For limited situations it provides a simpler interface. Flox won't provide exactly the same feature set, but there are many situations where home-manager is too much.

You can consider the current `flox` environment to be similar to a declarative profile, conceptually positioned between home-manager and devShells.

You don't need to choose :). You can use Devcontainers with most of the Nix tools, including Devbox. See https://containers.dev/supporting

They're nice, but they lock you into vscode

Thanks for pointing it out, it made me look closer at it.

I normally would actually welcome GPL, because it allows to keep project being open source.

Though looks like project also comes with CLA where anyone who contributes surrenders their copyright to FloxDev, Inc.

What this means, is that no one can fork it and make from it a commercial product. Many would say this is great as it can keep the project open source, except the CLA gives FloxDev, Inc. option to change license at any moment to whatever they want, including making the project fully closed source.

I don't think such project can be called open source. It feels like a Trojan horse to fool developers (kind of what Hashicorp did). I mean it is the right, but if you're contributing to it, you're not contributing to Open Source project but volunteering free work to another company.

That link in hub.flox.dev is wrong. The link at https://flox.dev/terms-conditions is correct. Fixing.... thanks!

It's not necessarily that one is better than another; it can be complementary. I tend to think that Nix makes many of the reasons to use a container superfluous, but there still remain other reasons to use containers.

For example, a talk about using both Docker and Nix (yep, that's me ;) ): https://www.youtube.com/watch?v=l17oRkhgqHE

I have to use both at the same time.

I have a Docker with an old version of centos which for some reason is the one provided to us.

I then create an "overlay" over it using nix, so I can actually use software with newer glibc etc... easily.

Regardless of that, nix is way better than docker, in the sense that docker doesn't ensure reproducibility, you can build a Dockerfile in two different days, and get different versions of packages installed, this is simply not possible with nix, you have complete control over your tools.

And if you decide to port your application to a "nix package", you have complete control over all the dependencies of you application, a reproducible way to build it, and an easy way to deploy it.

On non-Linux it should be faster/less overhead; on all platforms I suppose it's just arguably easier/quicker to make changes & 'rebuild', and then the result is that that just is your environment, it's not a container inside it that you have to exec into or run commands through or make your IDE use or whatever.

But mostly it's just two different approaches and people will be happy to argue about why there's is better, or that they don't use either (just the system environment (on a non-NixOS system..) as it were).

Not nix based, but I really like https://github.com/jdx/mise too to manage dev tools.

It’s a modern version of https://github.com/asdf-vm/asdf written in Rust.

> but worried that the development is not moving forward

There is an open v1.0 PR: https://github.com/cachix/devenv/pull/1005

Nix allows you to have a single lock file for all your dependencies. This is very useful for development environments. When you share a lock file via Git, then you know your colleagues will be running the same versions.

Devbox can also run services too. Both products use an awesome process runner called process-compose (https://github.com/f1bonacc1/process-compose/) which is worth checking out (it's even built with nix!)

+1 to devenv. I used to use Nix natively, then switched to devbox and then devenv. devenv is the most intuitive to use. I just wish that I could just run a command using devenv (similar to nix run) instead of having to declare it in the devenv.nix first.

Great list.

Using devbox myself and very happy with it.

Would be great to hear what separates flox from the rest.

I have used devbox and have been keeping an eye on other options. Haven't tried devenv yet. Any thoughts on devenv vs flox given what we're seeing here?

That doesn’t solve “works on my box” or reproducible builds

Developer environments should be cattle, not pets once you’re working with more than a few engineers