The inordinate usefulness of Nix really sinks in when you realize that it allows you to define a single piece of unified infrastructure for handling all the different parts of the software lifecycle. Furthermore, this infrastructure doesn’t even need to be project-specific. For a given class of projects, the “holy grail” Nix flake template defines all the following:

  1. All the dependencies, pinned in the flake.lock and updatable with nix flake update.
  2. A dev environment accessible with nix develop.
  3. A package derivation that encapsulates the build process in a nix build command.
  4. A module that exposes the app as a configurable system-level service that can be leveraged in integration checks with nix flake check.

With these things in place, activities that traditionally create overhead for developers (environment and deployment) are abstracted and standardized. And even though other tools solve similar problems, none of them achieve the universality of the Nix model. That’s because the most natural and complete description of software packaging is as pure functions over store paths. But in this post I’m focusing on convenience. The correctness of Nix, and the fact that correctness leads to convenience, are topics for a different post.

I’ve released some Nix infrastructure for Phoenix in a repo called PhoeNIX. It’s constructed, as is tradition, by copy-pasting from someone smarter (shoutout Zeke Dou and jurraca) and then extending to meet my needs. I haven’t seen any other flake templates for Phoenix that hit all 4 of my holy grail elements, so I hope this repo is useful for someone.

If you’ve got a deploy-rs setup for pushing system closures, then you can achieve a workflow that makes other DevOps, Cloud, and Containerization solutions look somewhat inadequate.