Exploring Nix for enterprise teams | by Duy NG | ekino-france | Jul, 2026 | MediumSitemapOpen in appSign up<br>Sign in

Medium Logo

Get app<br>Write

Search

Sign up<br>Sign in

ekino-france

Groupe de transformation digitale, nous accompagnons les entreprises à se transformer pour adresser les nouveaux enjeux de l’IA, de la technologie et du design. Nos équipes sont incroyables, passionnées, humaines, et surtout expertes. Ce medium en est la preuve. Merci à eux !

Exploring Nix for enterprise teams

Duy NG

9 min read·<br>1 day ago

Listen

Share

Using Nix to provide reproducible development environments for enterprise teams and accelerate developer onboarding.

Context<br>A new developer joins your team. You send them the onboarding doc. A few hours later, they’re still stuck because their machine has a slightly different setup and something broke. You get the Slack message: ”Hey, I’m getting an error… did this work for anyone else?”<br>You’ve seen this before. Every new hire loses time to environment setup, and your senior devs lose time helping them debug it.<br>At ekino, our Node.js team hit this wall enough times that we started looking for a better way. A few of us had been using Nix for personal setups, and the stability was hard to ignore. We decided to test whether it could scale to a full team without making everyone’s life harder.<br>Nix is not a new tool. Eelco Dolstra started it in 2003, and NixOS was first built by Armijn Hemel in 2006. For years it had a reputation for being hard to learn, with a strange language and a steep curve that felt aimed at Linux experts. But things have changed.<br>Nixpkgs now has over 120,000 packages. Flakes fixed the project structure story. And modern AI tooling makes writing config files much less painful. Nix is quickly becoming the most reliable way to manage team environments across both macOS and Linux (our team at ekino runs on Apple Silicon Macs, so the examples here reflect that experience).<br>We’re still in the experimentation phase. Nix is a vast ecosystem, and there’s plenty we haven’t explored yet. But we’ve found a path that solves our immediate problems: unpredictable onboarding, environment drift between projects, and the constant “did you install this?” back-and-forth.<br>Here is how we structured Nix for our Node.js team, what actually worked, and the edge cases we hit along the way.<br>Why Docker and Homebrew are not enough<br>Before Nix, our Node.js team at ekino used the standard setup: Homebrew for CLI tools, Docker for project isolation. It worked until it didn’t.<br>The pain points were small but constant. Someone runs brew upgrade and suddenly a tool version changed. Docker fixes consistency but file syncing is slow on Mac, and your editor can't easily reach tools inside the container. We had developers juggling multiple projects with different tool requirements, and no clean way to guarantee everyone had the same setup without conflicts.<br>Nix gave us per-project isolation without the VM overhead. Each project gets exactly the tools it declares, nothing more, nothing less.<br>The Architecture: project vs. machine level<br>Nix draws a hard boundary between your projects and your machine.<br>Press enter or click to view image in full size

Your global machine setup and your project environments never interfere with each other. Upgrading Node.js or Python in one project won’t affect anything else on your laptop.<br>The project level<br>The easiest way to introduce Nix to a team is at the project level. You lock down the project’s tools without touching the rest of the developer’s laptop. This is where we started at ekino.<br>We handle this using flakes alongside direnv. A flake.nix file goes into the root of your project, acting like a package.json for system packages. Here’s the structure we landed on:<br>description = "Node.js/TypeScript project with Nix flakes and direnv";

inputs = {<br>nixpkgs.url = "github:NixOS/nixpkgs/nixos-26.05";<br>flake-utils.url = "github:numtide/flake-utils";<br>};

outputs = { nixpkgs, flake-utils, ... }:<br>flake-utils.lib.eachDefaultSystem (system:<br>let<br>pkgs = nixpkgs.legacyPackages.${system};<br>baseTools = with pkgs; [ fish nodePackages.pnpm esbuild fnm ];<br>in {<br>devShells = {<br>default = pkgs.mkShell {<br>buildInputs = baseTools;<br># ... shell hooks<br>};

database = pkgs.mkShell {<br>buildInputs = baseTools ++ [ pkgs.redis ];<br># ... shell hooks<br>};

# testing, devops shells...<br>};<br>);<br>}Full example in the demo-nix-shell repo<br>The key insight: multiple devShells instead of one bloated environment . A backend developer runs nix develop and gets pnpm, esbuild, and fnm. A DevOps engineer runs nix develop .#devops and gets Kubernetes, Helm, and Docker on top. Everyone gets exactly what they need, nothing more.<br>flake-utils.lib.eachDefaultSystem handles cross-platform support automatically, so the same flake works on our M-series Macs and on Ubuntu CI runners with no extra configuration.<br>Auto-activating with direnv<br>Typing nix develop every time you open a project gets old fast. Pair the flake with a...