nixcage

2026-09-06 #nix #tools

nixcage gives every project its own systemd-nspawn container, built from the project's own devShells.default. There is no nixcage init and no nixcage file in the repository: the devShell is the entire interface.

Inside the container a project sees only its own directory, its own persistent home, and the Nix store read-only. Two projects on the same machine cannot reach each other's source, and neither can whatever their toolchains decide to run.

nix profile install github:hamidr/nixcage
cd ~/Src/some-project
nixcage enter

On Linux the container runs natively on the host. macOS has no containers, so the same container runs inside one shared NixOS microVM whose only job is to provide a Linux kernel. That boots once and serves every project, and it adds a VM boundary between the containers and the host.

The CLI is small: enter, exec, rm, status, plus rebuild and down on macOS where the VM lifecycle is yours to manage. Configuration is a NixOS module on Linux and a config flake at ~/.config/nixcage on macOS, so the VM is an ordinary NixOS system you own.

Secrets come from sops-nix and are injected per session:

nixcage.secretEnv.ANTHROPIC_API_KEY = "anthropic";

Four exported primitives (enter, uid, storage ensure, and exec) are the whole interface for tools built on top; you name paths and principals, nixcage names datasets and numbers.

GPLv3. README and ADRs are in the repository.