You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
add devbox-installed nix packages to NixOS build #2758
It is frustrating however, to not have the devbox packages instantly available in a nixos-rebuild build-vm (nor in a custom NixOS ISO).
I would like to use devbox as my primary package manager for apps and tools. But this workflow completely breaks down because I cannot test small changes to my system config in a build-vm because redownloading all the devbox packages is prohibitively expensive time-wise. As I understand it, devbox uses nix packages under the hood. So it would be absolutely FANTASTIC to have those nix-store-paths available in the VM as well instead of redownloading them after every rebuild. It would also be nice to have them available in the ISO when I generate it from my system config but that is secondary.
What solution would you like?
So telling devbox a directory where to keep an always current "devbox-packages.nix" (with all the pinned nix packages devbox resolved and installed) generated and updated by devbox in a format that I can import in my configuration.nix would be perfect.
I can run a refresh-global in the VM to give devbox the chance to wire everything up and keep to the devbox workflow. It would also have its last devbox.json and devbox.lock available. I would be happy to just have the nix-store-paths magically available during "ensuring packages are installed"
Alternatives you've considered
If that's not possible, I would appreciate a more hacky way as well. Maybe how I can write a shell script to copy over the relevant nix files from devbox to my nixos config dir and import them myself or some brute-force nix-way of letting NixOS know about all the nix-store paths to have them available in the build or even mounting the devbox-installed nix-store-paths somehow along with the system build. (I don't know much about the internals of nix and devbox)
Any help is appreciated.
I also considered setting up a nix cache server. That would speed things up slightly but still involve a lot of useless copying. Making NixOS properly aware of the packages or at least mounting them directly is the better way.
Hi @123batman thanks for reaching out. Have you looked into the .devbox/ directory that devbox creates after running a devbox shell command? More specifically, devbox generates a flake.nix file in .devbox/gen/flake/flake.nix that contains the packages (but not env variables and scripts) that are defined in devbox.json.
The scripts section of devbox.json file is also kept in .devbox/gen/scripts/. So if you want a hacky solution these 2 files might be a good start.
This asks devbox to emit and maintain a NixOS-importable module of the store paths it resolved, or otherwise integrate with nixos-rebuild build-vm and ISO builds. That is a new integration surface outside devbox's core dev-env use case. It also needs design work: global versus per-project, env vars and scripts, and keeping the module in sync.
Pieces already exist for a DIY approach:
devbox.lock records the resolved per-system store paths for each package (outputs[].path).
.devbox/gen/flake/flake.nix is the generated flake. See @mohsenari's comment above.
A small script could read the lockfile store paths and write them into something like environment.systemPackages, or into virtualisation.additionalPaths for a VM, so the paths are copied into the VM's store instead of being redownloaded. This is a nice-to-have and unlikely to be prioritized soon.
Activity
[-]add devbox packages to NixOS build[/-][+]add devbox-installed nix packages to NixOS build[/+]mohsenari commentedon Jan 13, 2026
Hi @123batman thanks for reaching out. Have you looked into the
.devbox/directory that devbox creates after running adevbox shellcommand? More specifically, devbox generates a flake.nix file in.devbox/gen/flake/flake.nixthat contains the packages (but not env variables and scripts) that are defined in devbox.json.The scripts section of devbox.json file is also kept in
.devbox/gen/scripts/. So if you want a hacky solution these 2 files might be a good start.mikeland73 commentedon Sep 28, 2026
Triage:
looks hard,p4This asks devbox to emit and maintain a NixOS-importable module of the store paths it resolved, or otherwise integrate with
nixos-rebuild build-vmand ISO builds. That is a new integration surface outside devbox's core dev-env use case. It also needs design work: global versus per-project, env vars and scripts, and keeping the module in sync.Pieces already exist for a DIY approach:
devbox.lockrecords the resolved per-system store paths for each package (outputs[].path)..devbox/gen/flake/flake.nixis the generated flake. See @mohsenari's comment above.A small script could read the lockfile store paths and write them into something like
environment.systemPackages, or intovirtualisation.additionalPathsfor a VM, so the paths are copied into the VM's store instead of being redownloaded. This is a nice-to-have and unlikely to be prioritized soon.Generated by Claude Code