HaS-002: Nix and Rust + Bevy
Towards a more repeatable game builds
One of a big technical decision I need to deal with is setting up repeatable builds.
While I mostly work on the code by myself, hopefully there will be a point where I can bring in others to help with programming. This means setting up the repository such that others feels easy to start developing.
For games, a challenge here would be packaging the development environments: you would need a compiler + linker (Rust), lots of low-level library for device graphics, input, audio, etc. Things might be different across combinations of OS and CPU architecture, too.
At work, where I only build back end/infra software, we typically put the development dependencies into a Docker image (running Linux)and run that. However, this is not as straight forward for games:
For once, the performance of a Linux-based container in OSX is terrible.
I also read that it’s not simple to funnel things like graphics and audio out of a container (haven’t tried it, actually).
=> This call for a different packaging approach.
I have been dabbling with Nix for other stuff, and maybe it is a better match for this problem, because:
We can declarative define an environment (binary, env variables, file systems, etc) and pin those dependencies.
We can define variations of the environment for Linux, OSX, as well as different CPU/GPU architectures.
The environments setup with Nix will be native to the developer’s machine.
It’s a bit of work to create. For example, instead of running lots of apt-get install [pkgs] and rely on assumed system paths, I now have to declare them upfront and set variables like LD_LIBRARY_PATH. Knowing exactly what to do takes a decent of work to figure out. You typically need to dive into Github issues, obscure forums and other Slack/Reddit, etc. Though this is slightly easier nowadays with support from tools like Copilot or Claude, however.
I also found: https://github.com/drxm1/bevy-project-template-nixos-wayland, which helps a lot when I need to reference how to do something.
Hopefully this approach will pay off sometime in the future. At least for now, the real benefit is that it teaches me exactly what is required to build the game. It also helped me understand where Nix, Docker, package managers (Go, Rust), Bazel, etc fits in the big picture of building a program.


The Nix approach for cross-platform game dev makes alot of sense when Docker's OSX performance is that bad. Declarative environments with pinned deps sound way cleaner than chasing down system paths and library versions, especially once collaborators join. I've hit similar issues trying to share backend setups across teams,and the upfront work to lock everything down always pays off eventualy.