We use NixOS in production in our product, for our cloud services, and for some development environments.

We build everything with nix from sbt projects, go projects, haskell projects, purescript projects, docker images, and npm projects.

It's an incredible tool.

NixOps is also a good tool but there are a lot of issues with it we haven't had time to contribute fixes for. We also wanted it to be lighter weight and to decouple system specification from system deployment. So I wrote a tool that handles performing the same system deployment operations that NixOps does for you and you can simply pipe the nix path result from nix-build to it. We use terraform to specify and manage the cloud resources.

Are you able to share your tool?

We will definitely be publishing it. Time is very short and the backlog of projects to publish is growing though so it might take time to polish and write a blogpost and tutorial.

I work for Awake Security so keep an eye out on the company's GitHub org as we've been publicly releasing a lot of projects even though they aren't completely polished or announced yet. I'll see if I can do this for our deploy tool soon.

Nice, I'd love to see it released.

Gabriel also has a great blog http://www.haskellforall.com/

Basically the kind of person I would love to buy a beer any time because he does so much great work.

on topic: The binary caches are great. For work I'm currently evaluating https://github.com/typeable/stackage2nix and https://github.com/input-output-hk/stack2nix to generate nix expressions from our haskell stack projects. And then push the build artifacts to a shared cache. Such that nobody has to ever compile a dependency twice. Because nothing sucks more than starting your day watching the compiler churn away at compiling after version bumps, to then also see a collegue go to the same pain all over again.

I love Nix concepts and all it's subprojects (NixOS, NixOps, Hydra, Disnix).

However, i've found NixPkgs to be a bit messy. It's too big, targets too many platforms and it's too disorganised. But to be completely fair, I think it's getting a lot of good refactorings lately.

Yeah it's basically just growing pains.

For large enterprise use, Nix is going to need to mature to a point where it's possible for enterprises to host a Nixpkgs cache locally, using a binary repository manager like Artifactory or Nexus, both for sheer cost (to save on bandwidth of thousands of servers downloading updates from the Internet) as well as risk reduction (in case the public binary caches are unavailable at critical moments). If this is doable today, it's not really documented.

I'm sure the project will get there... eventually.

You can install nix-serve on any machine to share its binary cache (including patched applications). Then add all of the enabled machines to every machine's nix.binaryCaches in order of preference. If they don't have what you need, it will fall back to the upstream server. You'll want to make sure they are upgraded in an appropriate order to minimize the need to leave your network for updates. It's true this isn't well documented, but I figured it out in about a day and was surprised at how simple it turned out to be.

You can even go further and set up your own build server to service all the architectures you need to support.

I found Guix a lot more organised. Most package code is very simple, and the toolchain is also quite elegant. Hopefully the latter will be addressed by the new nix interface.

Is GuixSD really usable in production? Its focus on using a Linux-libre kernel instead of mainline is worrisome regarding real-world hardware support.

Switching to mainline is almost trivial, just override plain linux-libre kernel and redefine the source.

GuixSD is getting production-ready IMHO. See for example Guix getting adopted by some HPCs:

https://guix-hpc.bordeaux.inria.fr/

That is already very easy:

https://github.com/nh2/nix-binary-cache-proxy

Allows you to set up (using NixOps!) a caching proxy for the nixos binary cache in your local network.

It can also serve your own custom packages if you sign it with your own package signing key and tell your machines to trust it.

Setting up your own binary cache is straightforward: https://nixos.org/nix/manual/#sec-sharing-packages

Is using Artifactory or Nexus a requirement? Why?

Mainly concerns like access control, and auditing for internal projects. If we're going to package for Nix, we need to host those packages internally somewhere, and access to that host needs to be audited/monitored. Access should be limited to developers and forbidden to non-engineering staff, etc.

Nix package definitions sit in a Git (or other VCS) repo, which you can access-control through your usual means.

The binary artifacts are behind an HTTP server, which you can access control through whatever normal access control mechanisms, or leave uncontrolled and rely on the fact that it's not possible to retrieve artifacts from the server without having access to all the build inputs so you can hash them.