Nuking projects (from orbit, apparently)
So there I was, working on a software product team that was doing all the right thingsâshipping multiple times a day, iterating quickly, rolling out with feature flags, deploying in cloud native ways where what is being tested is whatâs being deployed (and the same being true in reverse).
However, despite a stellar team that seemed to have all the best engineering principles, we still occasionally had to, in the words of the team, ânuke it from orbit.â So much so that our cute little Hubot in Slack had a response to the word ânukeâ with âburn it with fire!â and some fun memes (you know, the classic ones that totally reveal my age).

Iâll step back a bit for those who might not know what I'm on about. To ânuke it from orbitâ you would rm -rf
an entire project and re- git clone
it from source. There were softer ways of cleaning up the environment but sometimes they just didnât work. So out rolls the nukes.
So why is it that a high performing team periodically has to nuke things?
The answer? âThatâs just the way it is.â That feeling of âthe way it isâ permeates a special class of problemsâoften referred to as the age-old âworks on my machineâ (but not yours) response to a question from a coworker. I think part of the reason is it is how software has been done for a long time and itâs a special class of problem that vanishes (and you purge it from memory) as soon as you resolve it.
Often when you ask an engineer how much time they spend on this theyâll say âoh almost nothingâ but if you ask âtell me about how the last person that joined the team got onboardedâ youâll hear a very different answer. We so deeply accept this as how it works that we sometimes donât see how much time we lose to âthe nukeââeither in the time you spend waiting to reconstruct the universe or the time spent helping someone else figuring out what has gone horribly wrong with their universe.
Reproducibility with containers! And Nix!
Then containers came alongâŠand a part of me was like FINALLY. We have a solution, right? Our lives are better, right? Well, sort of.
Containers are a very powerful abstraction providing us a very simple way to run and deploy our code repeatedly. But for local development? You can drill the holes in the container and get your source code mounted but youâll always feel like youâre doing some development on not-my-machine and, in my observation, this tends to put off most people from doing local development from within a reproducible container. Many instead defer to containers to get you a database or a redis cluster but leave the cool language of choice things to that language of choiceâs toolset.
Are containers the only option? Well, no. This class of problems is one of the reasons why open source Nix, Nixpkgs, and NixOS exist. If you donât know what Nix is, itâs a 20+ year-old open source technology that provides declarative principles that allow guarantees of reproducibility (itâs more than that, Iâm over simplifying). If you speak to anyone who has ever crossed the Rubicon from todayâs ways to Nixâs ways then youâll know what I'm about to say: you can âjust do it betterâ and never have any of those problems ever again.
Amazing, right? Well, unfortunately for Nix it takes a lot more than a blog post to convince people to rock the boat. Thereâs a real cost to trying to adopt a new way to work, and your coworkers may not easily follow you to a new mantra. So Nix is an answer but it doesnât feel like itâs familiar or forgiving enough to be the answer on its own.
What is Nix missing? Not a lot from a functionality standpoint. However, I think Nix presents three key challenges that helped push us towards creating Flox:
- The user experience is unfamiliar and the learning curve is high.
- The technology is so un-opinionated and flexible that itâs hard to implement something using it without feeling like you are inventing the universe.
- Nix is decentralized by design in a way that makes it a hard sell for the enterprise.
Introducing Flox
This is a long way of saying we built Flox to take the best declarative parts of Nix, wrap them in a user experience you are familiar with, and offer centralization in the right places so individuals (and enterprises) can manage their applications comfortably.
Flox is a virtual environment and package manager all in one. With Flox you create environments that layer and provide dependencies just where it matters, making them portable across the full software lifecycle. Flox gives you a developer environment that you can take with youâacross different system types and architectures and, broadly, the software development lifecycle.
Flox helps you avoid having to nuke your projects but thatâs not the only reason I love it.
Flox environments are declarative and comprehensive: Flox contains software youâd normally install with an OS package manager plus all the software you would install with a tool-specific solution such as nvm
for node projects. This can all be declared in a simple manifest (toml), checked into your source code, and environments ship with an activation script plus environment variables that make it simple to reproduce the environment no matter where itâs running. This comprehensive approach reduces a README.md guide down to a single flox activate
that works no matter what Linux or macOS flavor youâre on (or what CPU type youâre using).
Flox CLI semantics are so familiar you likely already know them: whatâs your favorite package manager? We think Flox works just like it does (or very close). Flox adds only a single abstractionâthe environmentâon top of your computer so you can have multiple declarative environments on the same machine. That means fast searching, installation, and declaration of packages and simple environment creation, use, and removal.
Flox is fast: Trying to get onto development really quickly to check something for a colleague? With Flox you can switch environments (inclusive of packages, environment variables, and that activation script) and confidently get new context, software, and variables in under a second.
We have a long way to go to fulfill our full vision and the Flox CLI 1.0 and FloxHub service is just step 1 of the journey. But I think technologies like Flox will help guide us towards a world where it does work on my machine and we can be a lot kinder to our development environments because they work like they should and donât waste our time.
Flox is free to use. We hope you give us a spin at flox.dev and tell us what you think!