devenv | Blog

devenv 2.2: attach to running processes and persistent out-of-tree environments

Tue, 28 Jul 2026 00:00:00 GMT

Attach to running processes: share one native process manager across terminals, with live status, ports, logs, and a choice to detach or stop.
Persistent out-of-tree environments: bind a directory to a local or remote --from source, including profiles and the source’s complete devenv.yaml.
More reliable shell activation: automatically load hooks in fish and nushell, select the correct login shell in stripped environments, and behave predictably in multiplexers and nested shells.
SecretSpec 0.17 and Cachix integration: upgrade from SecretSpec 0.8, pull and push to private caches without exporting CACHIX_AUTH_TOKEN, and run the bundled SecretSpec CLI with the same profile and provider as devenv.
A calmer and sturdier TUI: use near-zero CPU while idle, distinguish every process state at a glance, and handle unusual terminal input safely.
Evaluation cache fixes: invalidate correctly when local inputs, copied sources, and files modified during evaluation change.
Better automation interfaces: inspect tasks as JSON, access inputs in the REPL, distinguish trace callers, and avoid streaming interactive output into coding agents.
Smaller installs and better diagnostics: remove unnecessary LLVM and debug-toolchain dependencies while surfacing clearer errors in terminals and CI.

One process manager, many terminals

Running devenv up while the native process manager is already active now attaches to it instead of failing (devenv#2936). The second invocation connects over the control socket, starts any requested processes that aren’t running yet, and streams status, ports, and logs.

$ devenv up -d                      # start processes in the background
$ devenv up                         # attach: live status, ports, and logs
$ devenv processes attach           # watch without requesting any starts
$ devenv processes start postgres   # start one process, cold-starting a manager if needed

The manager resolves before and after ordering through its own task scheduler. An attached terminal first receives the current state and recent log output, then follows live changes. Other terminals can attach and detach independently without taking ownership away from the daemon.

Ctrl-C on an attached devenv up asks whether you want to detach and leave the processes running, or stop the whole manager. devenv processes attach always detaches on Ctrl-C.

devenv processes start <name> no longer requires a manager to be running. It can cold-start one in the background with that process and its dependency closure, equivalent to devenv up -d <name> (devenv#2930). Named starts always start the requested process, even when its default start.enable is false.

Attaching is deliberately interactive. CI jobs, piped commands, and detected coding agents report that processes are already running instead of entering a live view that could wait indefinitely.

Under the hood, the process manager became the single owner of process state, the daemon pushes attach sessions as an event stream instead of being polled, and every process launch goes through the same task graph. This fixed a family of lifecycle bugs along the way: double launches, processes vanishing from list, stuck relaunches, concurrent daemon startup, and a foreground devenv up corrupting a running daemon’s PID file.

Closes devenv#971, open since February 2024.

Configure an environment once, use it anywhere

--from lets you use a devenv without checking devenv.nix into the project. In 2.1 you had to repeat the flag for every command. In 2.2, devenv allow can bind the current directory to that source:

$ cd my-project
$ devenv --from github:myorg/devenv-configs?dir=rust-web allow
$ devenv shell

Every subsequent devenv command in that directory loads the bound configuration. The native shell hook auto activates it on cd, just like a project with a local devenv.nix.

Profiles persist with the binding:

$ devenv --from github:myorg/devenv-configs \
    --profile backend \
    --profile observability \
    allow

An explicit --profile still takes priority when you need a one-off override.

Local sources now bring their entire configuration with them. --from path:../shared-devenv loads the source’s devenv.yaml, inputs, imports, and sibling modules from its Git repository. Modules are read from the live directory, so edits take effect without fetching or rebinding the source.

Normal in-tree projects are easier to navigate too: devenv now walks up parent directories to find devenv.nix. Commands work from any subdirectory while the shell and devenv shell -- <command> keep the directory where you invoked them (devenv#2232).

Shell activation gets out of the way

The native shell integration added in 2.1 now loads automatically in fish and nushell through their vendor configuration mechanisms. Bash and zsh have no equivalent, so they still need the one-line devenv hook setup in your shell configuration.

Shell selection is more reliable in editor terminals and stripped environments where $SHELL is missing. devenv looks up the user’s login shell before falling back to bash, and warns when a shell explicitly requested through --shell or devenv.yaml is unsupported (devenv#2880, devenv#2992).

Activation and deactivation have also been hardened across real-world shell setups:

New tmux and zellij panes, SSH sessions, and nested shells no longer inherit a marker that can close them when they change directory (devenv#2861).
Leaving and immediately re-entering a project activates it again on the first try.
Fish preserves cd - history and works when zoxide overrides cd (devenv#2853).
A manually entered devenv shell, or an environment already loaded by direnv, no longer gets another devenv shell stacked on top.
Nushell now deactivates reliably when leaving a project.

If you still use direnv, devenv init --include-envrc (or DEVENV_INCLUDE_ENVRC) adds an .envrc to a new project. Native activation remains the default and requires no project-local activation file.

SecretSpec 0.17 and Cachix integration

devenv 2.2 upgrades its SecretSpec integration from 0.8 to SecretSpec 0.17. The release adds scopes, secrets caching, cross-secret validation, GitHub and Forgejo Actions support, and new providers including SOPS, age, KeePass KDBX, OpenBao, Scaleway Secret Manager, and systemd credentials.

Pulling from and pushing to private Cachix caches no longer requires exporting CACHIX_AUTH_TOKEN. devenv can resolve the token through SecretSpec without exposing it to the development shell:

devenv.yaml

secretspec:
  enable: true
  provider: keyring
  cachix_auth_token: true

No declaration in secretspec.toml is required. If SecretSpec does not return a token, devenv falls back to the token stored by the Cachix CLI through cachix authtoken. The resolved token is used for both pulls and the Cachix push daemon.

If your secrets backend grants access to the token under a different name, configure it in devenv.yaml:

devenv.yaml

secretspec:
  enable: true
  cachix_auth_token: CI_CACHIX_TOKEN

The string is the secret’s name, not the token itself.

The matching secretspec command is now bundled with devenv. The profile and provider selected in devenv.yaml are exported as SECRETSPEC_PROFILE and SECRETSPEC_PROVIDER, so runtime commands use the same configuration that devenv used during evaluation:

$ devenv shell
$ secretspec run -- npm start

TUI: calmer, sturdier

Process status at a glance. Each process now shows a status dot whose shape encodes its lifecycle instead of an identical spinner on every row. Waiting, starting, running, ready, stopped, exited, failed, and gave-up states remain distinct. The shape carries the state, so it reads without relying on color.

Near zero idle CPU. devenv up was burning roughly 10 to 15% CPU per managed process even when everything was quiet, because the UI recomputed its layout dozens of times per second. The TUI now only redraws when something actually changes (devenv#2915).

Fuzzed nightly. The TUI gained property-based tests and a nightly terminal fuzzing run, which already flushed out crashes on multi-byte characters, progress overflow, and narrow terminals.

Better terminal rendering. Long structured logs and stack traces wrap instead of being truncated. Shell output is read in larger batches, reducing rendering overhead, and long lines copied from devenv shell no longer acquire a hard newline at the terminal’s wrap point (devenv#2865).

Evaluation cache fixes

Local path: inputs now participate in cache invalidation. Editing a shared configuration applies on the next command instead of returning stale results until .devenv is deleted.

The cache also tracks local files and directories copied into the Nix store during evaluation. Directories are hashed recursively, so changes to nested scripts and imported source trees invalidate the attributes that depend on them (devenv#2886, devenv#2893).

If a tracked file changes while an evaluation is still running, that result is no longer stored. This closes a race where editing devenv.nix at the wrong moment could leave stale tasks or options behind (devenv#2745).

Other fixes cover newly created files with sub-second timestamps, SQLite caches on VM-mounted filesystems, and shells built through relocated or chrooted Nix stores (devenv#2499, devenv#2947).

For automation and coding agents

devenv down. A shorthand for devenv processes down, mirroring devenv up (devenv#2862).

devenv tasks list --json. Machine readable task graph inspection (devenv#2966).

inputs in the REPL. devenv repl now exposes inputs alongside devenv and pkgs, so you can poke at inputs declared in devenv.yaml directly (e.g. inputs.nixpkgs.lib.version).

Better agent detection. Quiet mode now kicks in for more coding agents (Aider, autonomous and cloud agents, and others) via the detect-coding-agent crate, not just Claude Code. Set DEVENV_NO_AI_AGENT=1 to opt out.

Trace callers. OpenTelemetry spans now identify whether devenv was invoked by the CLI, direnv, or the native shell hook through the devenv.caller attribute (devenv#2965). DEVENV_TRACE_DEFAULT_TO configures a default trace destination without overriding an explicit --trace-to or DEVENV_TRACE_TO.

Smaller installs and better diagnostics

Statically linking nixd, used by devenv lsp, removes the monolithic LLVM shared library and reduces the devenv closure and container image by roughly 550 MiB. Building libghostty-vt in release mode also avoids pulling a debug toolchain containing Zig and LLVM into every installation.

Non-TUI output now shows useful Nix evaluation and build progress while hiding internal debug noise. Evaluation warnings no longer replace the real error message, devenv test --no-tui preserves test output in CI, and unfree-package errors point to the relevant devenv configuration instead of generic NixOS advice.

devenv shell also terminates its inner shell when the terminal closes instead of leaving a background process at 100% CPU (devenv#2845). GitHub inputs resolve over SSH when a url.insteadOf rule rewrites them, using your SSH agent (devenv#2842).

See the full changelog for the rest.

Breaking changes

Dropped x86_64-darwin (Intel macOS). devenv is no longer built, tested, or released for Intel Macs. Pin an older devenv release if you’re on one. x86_64-darwin environments still run through Rosetta 2 on Apple Silicon, though nixpkgs 26.05 will be its final supported nixpkgs release.
Auto activation detects devenv.nix. The shell hook and devenv allow now look for devenv.nix instead of devenv.yaml. Projects with only a devenv.yaml no longer auto activate; add a devenv.nix to restore activation.

Final words

Open an issue or join the Discord with feedback.

Domen

Making devenv start fast, and the whole nixpkgs with it

Fri, 26 Jun 2026 00:00:00 GMT

I’m sitting here next to Farid Zakaria at Tacosprint where we looked at the stat storm that has been haunting nixpkgs for a decade.

devenv auto activation runs devenv hook-should-activate on every shell prompt to decide whether you’ve stepped into a project directory. It does almost nothing: discover the project, check the trust database, print a path. So its runtime is pure startup overhead, and it runs on every single prompt redraw.

$ time devenv hook-should-activate
/home/domen/dev/myproject
real    0m0.070s
...

70ms before a prompt, every prompt.

And this isn’t devenv’s tax to pay, it’s nixpkgs’. Every program pays it before it runs a line of its own code: the dynamic loader has to find each shared library, and the way Nix scatters packages across the store makes that search slow. This is not news. The cost has been measured, written up, and partly fixed more than once, and yet it has sat in limbo for the better part of a decade with no general fix merged into nixpkgs.

Most of that is the dynamic loader looking for a shared object that is sitting right there in the store, just not in the first directory it tried. The loader knocks on 486 wrong doors before it finds the right ones, and almost all of it happens before main even starts.

That number is the whole game. Above ~30ms you have to bolt a caching layer on top of the hook; in single digit milliseconds you just run it on every prompt and throw the cache away.

And it scales with the closure: imagemagick’s magick --version makes 1225 failing opens:

$ strace -f -e openat magick --version 2>&1 >/dev/null | grep '\.so' | grep -c ENOENT
1225

The community has been circling a real fix for years. This post walks through the problem, the approaches people have tried with their tradeoffs, and a more radical one we spiked for devenv to see if it was even possible: deleting the dynamic loader altogether by linking the whole program into one static binary.

The umbrella tracking issue for the general problem is NixOS/nixpkgs#481620.

Why Nix makes the loader work so hard

On a traditional distribution every shared library lives in a handful of global directories such as /usr/lib. The dynamic loader has a short, mostly cached search path, and ld.so.cache (built by ldconfig) turns soname lookups into a hash table hit.

Nix is different by design. Every package lives in its own /nix/store/<hash>-name/lib directory, and there is no global ld.so.cache for store libraries. To make a binary find its dependencies, Nix records a DT_RUNPATH in the ELF header that lists one directory per dependency. A program linked against fifty libraries gets a DT_RUNPATH with dozens of entries.

Now recall how glibc resolves a DT_NEEDED soname with DT_RUNPATH present: it walks every DT_RUNPATH directory in order, trying to open dir/soname in each, until one succeeds. So resolving N libraries against a path of M directories costs on the order of N times M openat() attempts, almost all of which fail. That is the stat storm.

It gets worse. For every directory it searches, glibc first probes the glibc-hwcaps subdirectories for your CPU (x86-64-v3, x86-64-v2, and so on), which adds roughly three more failing opens per directory on a modern machine. On a fast SSD with a warm cache none of this is noticeable. On a slow disk, a network filesystem, a cold cache, or a low power ARM board, it is the difference between snappy and sluggish, and it multiplies across every process a shell script spawns.

Concretely, the two workloads we traced most closely:

Workload	Loaded libraries	`DT_RUNPATH` dirs	Failing `.so` opens
`devenv version`	83	12 (leaf binary)	~486
`imagemagick magick --version`	91	35	~1225

The wider a binary’s own DT_RUNPATH and the deeper its transitive graph, the worse the storm.

What a good fix has to preserve

The reason this problem has stayed open so long is that the obvious fixes break things people rely on. Any serious solution is judged against a checklist:

LD_LIBRARY_PATH override. NixOS injects the GPU driver by putting /run/opengl-driver/lib on LD_LIBRARY_PATH. If a fix stops that from winning, graphics break.
LD_PRELOAD. Interposers and shims must still load first.
The libGL / glvnd runtime swap. A program built against Mesa must be able to pick up the vendor driver at runtime.
Two libraries with the same soname. This is the heart of the Nix model: different parts of one closure can legitimately depend on different builds of the same soname, and resolution must stay per object.
dlopen. Plugins loaded at runtime are a related but separate problem.
Cross compilation. A fix that has to run the target loader cannot cross compile cleanly.
Disk and closure size. Whatever metadata you add ships in every NAR.
Maintenance burden. A glibc or loader patch has to be rebased onto every new glibc release, and patching glibc rebuilds the world.

No approach so far ticks every box. The interesting part is how each one chooses which boxes to give up.

Approach 1: freeze the resolution with absolute paths

The simplest idea: rewrite every DT_NEEDED entry from a bare soname like libfoo.so.1 to the absolute store path of the library it resolves to. glibc has a “slash short circuit”: a DT_NEEDED containing a / is opened directly, skipping all search. No search means no storm, and not even the glibc-hwcaps probes happen.

This is well trodden ground:

Farid Zakaria’s shrinkwrap and the nix-harden-needed tool do exactly this as external post processing. Shrinkwrap is described in the paper Mapping Out the HPC Dependency Chaos (Zakaria, Scogland, Gamblin, Maltzahn, 2022; arXiv:2211.05118), which measures the storm directly: an Emacs launch drops from 1823 stat/openat syscalls to 104, a 36 times speedup, and a 900 library MPI application starting across 2048 processes on NFS goes from 344.6s to 47.8s, 7.2 times faster. Those NFS numbers are the clearest evidence that this overhead, invisible on a warm local cache, becomes brutal on a network or cold filesystem.
patchelf PR #357 (--shrink-wrap, open since 2021) pulls all transitive DT_NEEDED up onto the top binary and rewrites them to absolute paths.
Spack has a similar bind feature in the HPC world.
Inside nixpkgs, this mechanism is already used ad hoc in dozens of packages.

The cost is steep on the checklist. Absolute paths lose the LD_LIBRARY_PATH override, so the glvnd driver swap stops working, and you need an exemption list for libc, the loader itself, the GL stack, and initrd. There is also no runtime fallback: if the pinned path is gone, the program does not start.

There is also a build time fork in the road here. To rewrite a soname to an absolute path you first have to resolve it, and there are two ways to do that: run the binary’s own loader and record what glibc actually picks, or walk DT_RUNPATH statically and resolve it yourself. The first is exact but executes target code, so it cannot cross compile; the second cross compiles cleanly. The absolute path tooling only ever did the first, which is why it stays a manual, per package tool rather than a default. The static walk is the same technique the ELF note cache (approach 3) later builds on.

So absolute paths are the zero disk, maximum speed option, attractive for self contained leaf applications, but wrong as a default because of the override semantics.

Approach 2: the RUNPATH symlink farm

If the problem is that the loader searches many directories, give it one. The farm idea, floated early on by Linus Heckemann (see #24844), is: for each ELF, create a single directory of symlinks pointing at exactly the libraries that ELF needs, and set its DT_RUNPATH to that one directory.

The crucial detail is that the sonames in DT_NEEDED stay short. The farm only changes where they are found, not how. Because the farm lives in DT_RUNPATH, which the loader consults after LD_LIBRARY_PATH, every override keeps working. And it builds with nothing but stock patchelf --set-rpath and symlinks, with no glibc or patchelf fork, and never executes the target binary, so it cross compiles.

But keeping the sonames short is also where it breaks the Nix model. A farm directory is a flat namespace keyed by soname, so it can hold exactly one libfoo.so.1. When a closure legitimately pulls two different builds of the same soname (the case Nix exists to allow), the farm cannot represent both, and glibc’s soname based dedup collapses them to whichever loads first. Absolute paths (approach 1) sidestep this because the store path becomes the key; the farm, which deliberately keeps the bare soname, cannot.

The remaining costs are store pollution and the hwcaps floor. Every ELF gains its own extra directory of symlinks, so the store fills up with farm directories that shadow the real libraries. And the farm collapses the per directory multiplier but not the per hwcaps multiplier: the loader still probes glibc-hwcaps inside the one farm directory. So it is a large constant factor win, not an asymptotic one.

How large depends entirely on how much of the graph you farm:

Farmed scope	Failing opens	Reduction
`imagemagick`, binary only (wide 35 dir `DT_RUNPATH`)	1225 → ~213	83%
`devenv`, leaf binary only (narrow 12 dir `DT_RUNPATH`)	486 → 392	19%
`devenv`, whole graph (every dep built with the hook)	486 → 88	82%

The two devenv rows are the lesson. Farming the leaf alone barely moves the needle because the storm there is dominated by the 83 libraries resolving each other, which a leaf only farm never touches. Only whole graph adoption reaches 82%, and the residual 88 are irreducible hwcaps probes rather than real library searches. So the farm pays off immediately when a package’s own binary has a wide DT_RUNPATH, but needs whole graph adoption for closure heavy applications.

Approach 3: a per DSO resolution cache in an ELF note

This is the most ambitious approach and, on the checklist, the best. The idea, designed by pennae in #207893: have patchelf write a small PT_NOTE into each library that records, for each DT_NEEDED soname, where the loader should find it. A patched glibc reads that note during loading, between the LD_LIBRARY_PATH step and the DT_RUNPATH walk, and resolves the dependency straight from it.

Placing the read after LD_LIBRARY_PATH is what makes it safe: overrides, LD_PRELOAD, and the glvnd swap all keep winning, and soname based dedup is unchanged because the sonames stay short. Each cache entry is either an exact path, which is opened directly with no search and therefore no hwcaps probing, or a directory hint for the rare cases that cannot be resolved at build time ($ORIGIN relative entries, or directories that themselves contain a glibc-hwcaps tree).

This is the only approach that preserves every semantic, adds zero closure references, and eliminates the hwcaps floor as well. pennae’s original benchmark showed an armv7 workload dropping from 44s to 29s (seconds, not ms, measured under strace -cf) with about 24000 fewer syscalls. In our own end to end test of a revived, cleaned up version, a note bearing binary resolved its dependency with zero failing search probes, versus the full storm for the same binary without the note, while the LD_LIBRARY_PATH override still took precedence.

The price is the heaviest of any approach. It needs two source changes: a glibc patch so the loader understands the note, and a patchelf change to write it. It is a staging mass rebuild, because patching glibc rebuilds the world. pennae’s draft was closed for lack of a go or no go decision rather than any technical failure; the main worry raised was the long term maintenance of a glibc patch.

Approach 4: a Guix style per package ld.so.cache

Guix solves the same problem in production by shipping a per package ld.so.cache, the same binary format ldconfig produces, and having a patched loader consult it (written up in their Taming the ‘stat’ storm with a loader cache; #207061 proposed it for nixpkgs). It preserves LD_LIBRARY_PATH and is proven at scale, but building the cache needs ldconfig/ldd for the target architecture, which breaks cross compilation, and it hits buildEnv collisions and dlmopen namespace issues. The ELF note (approach 3) was in part a response: it reads DT_NEEDED and DT_RUNPATH statically and never runs a foreign binary, so it keeps the same LD_LIBRARY_PATH guarantee without those costs.

Approach 5: delete the loader with static linking

The four approaches above all make the loader’s job easier. Static linking removes the loader instead. For devenv, a self contained CLI, we spiked it: building the whole closure through pkgsStatic (which means musl, since glibc doesn’t support a complete static link) drops devenv version and hook-should-activate from about 70ms to about 16ms.

Build	Loaded libraries	startup
Baseline (all dynamic, glibc)	83	~70ms
Fully static (musl)	0	~16ms

This is not a nixpkgs fix and was never meant to be. Deleting the loader also deletes everything the loader does at runtime: loading plugins on demand, honouring driver and interposer overrides, swapping in the GPU vendor’s GL stack. A lot of nixpkgs depends on that, so static linking can never be a general default. It works for devenv only because devenv is a self contained CLI that talks to Nix through its own linked in C API and needs none of it.

One thing surprised us: at 16ms, with the loader gone, devenv is still far above the ~2ms a static musl hello world starts in, the rest being execve mapping the image and devenv’s own startup work. Even so, 16ms is fast enough for the shell hook to drop its per directory activation cache and just run the check every prompt.

What about macOS?

macOS uses a different loader, dyld, and the storm isn’t there. Nix on Darwin already ships approach 1: every Mach-O records its dependencies as absolute store paths in LC_LOAD_DYLIB rather than bare sonames, and carries no LC_RPATH. So dyld opens each library directly on the first path it tries, and system frameworks come straight from the in memory dyld shared cache without touching disk. Where the glibc devenv made ~486 failing opens, the macOS one makes essentially none.

The startup cost macOS does have is specific to Nix. To decide whether to advertise x86_64-darwin as an extra platform, libstore forked a child running arch -arch x86_64 /usr/bin/true on startup, costing ~13ms on every Nix process on Apple silicon. The fix answers the same question with a stat of Rosetta 2’s fixed install path in ~0.01ms (NixOS/nix#16067).

Side by side

Every column is framed as a property you want, so ✅ is always good and ❌ always a cost. Legend: ✅ yes · ⚠️ with caveats · ❌ no · ➖ not applicable. Caveats marked ⚠️ or worth a word are footnoted below.

Approach	No glibc fork	No patchelf change	Cheap on disk	Keeps `LD_LIBRARY_PATH` / glvnd	Keeps dup sonames	Kills hwcaps floor	Cross safe
Absolute `DT_NEEDED`	✅	✅ ^a	✅	❌	⚠️ ^b	✅	⚠️ ^c
RUNPATH symlink farm	✅	✅ ^d	❌ ^e	✅	❌	❌	✅
Per DSO ELF note	❌	❌	✅	✅	✅	✅	✅
Per package ld.so.cache	❌	✅	✅	✅	⚠️ ^f	✅	❌
Static linking (musl)	✅ ^g	✅	❌ ^h	❌	➖	✅	✅ ⁱ

^a stock patchelf --replace-needed · ^b breaks on the rare duplicate soname · ^c only the static-resolution variant cross compiles, and it is unbuilt · ^d stock patchelf --set-rpath · ^e every ELF gains its own symlink directory in the store · ^f buildEnv collisions · ^g uses musl, not glibc, so no glibc fork to maintain · ^h ~82MB binary · ⁱ via pkgsStatic

The final approach

Over the week at Tacosprint we revived the ELF note cache, cleaned it up, and got it built and tested end to end. After a decade in limbo it now works: the note writer, patchelf --build-resolution-cache (#647), shipped in patchelf 0.19.0, the first patchelf release since 0.18.0 in April 2023.

The last thing to land is nixpkgs#535735, which turns the note on across the whole package set. Because it patches glibc it has to go through staging, which rebuilds the world, so every binary in nixpkgs comes out the other side resolving its libraries straight from the note. That is also where it gets exercised at scale, and we’re committed to fixing whatever shakes out as we go.

Once it has proven itself there, the longer term goal is to upstream the loader patch into glibc itself, so the fix isn’t a nixpkgs carry but something every store based, nix style package manager, guix included, can rely on.

devenv 2.1: Nix with zsh, fish, and nushell via libghostty

Thu, 07 May 2026 00:00:00 GMT

devenv 2.0 gave you hot reload, the status line, and instant cache hits, but devenv shell always dropped you into bash, and you still needed direnv for activation on cd.

devenv 2.1 closes both gaps and adds structured handles for coding agents.

Every shell, first class

Native zsh, fish, and nushell

devenv 2.1 adds native support for zsh, fish, and nushell (devenv#2718) with rcfile generation, environment diff tracking, reload hooks, and prompt integration implemented per shell rather than shimmed through bash. The shell is picked from $SHELL, or set explicitly:

$ devenv shell
$ SHELL=/bin/zsh devenv shell

Closes devenv#36 (open since November 2022), devenv#2487, and devenv#2592.

libghostty under the hood

The virtual terminal emulator was replaced with libghostty, the terminal engine from Ghostty, giving devenv a single VT parser that handles every shell the same way.

Building libghostty reliably on Nix took upstream patches in libghostty-rs#27, ghostty#12364, and ghostty#12548. Thanks to the Ghostty maintainers for landing them.

Auto reload

2.0 required Ctrl+Alt+R to apply environment changes after a rebuild, and that keybind clashed with reverse search on macOS. 2.1 re evaluates in the background on file changes and applies the new environment at the next prompt (devenv#2595).

Auto activation without direnv

devenv hook replaces direnv for cd based activation. Add one line to your shell config:

~/.bashrc

eval "$(devenv hook bash)"

~/.zshrc

eval "$(devenv hook zsh)"

~/.config/fish/config.fish

devenv hook fish | source

config.nu

devenv hook nu | save --force ~/.cache/devenv/hook.nu
source ~/.cache/devenv/hook.nu

Activation happens on cd into a trusted directory and reverses on the way out. No .envrc, no external dependencies. Trust is managed with devenv allow and devenv revoke.

For coding agents

In 2.0, an agent that wanted to restart your API after a config change had to kill the whole devenv session or scrape the TUI through ANSI codes. 2.1 replaces that with structured handles.

Process management from the command line

New subcommands act on a running devenv up (devenv#2621):

$ devenv processes list
$ devenv processes status
$ devenv processes logs api
$ devenv processes restart api
$ devenv processes stop worker
$ devenv processes start worker

These work with the native process manager and are also exposed as MCP tools.

Quiet mode by default

devenv detects agents via CLAUDECODE, OPENCODE_CLIENT, and AI_AGENT and switches to quiet mode automatically, suppressing TUI progress output that would waste tokens (devenv#2723). Override with --verbose or --tui.

OpenTelemetry trace export

devenv 2.1 exports OTLP traces (devenv#2415). Every Nix evaluation, derivation build, task run, and managed process becomes a span with attributes like devenv.activity.kind, devenv.derivation_path, devenv.url, and devenv.outcome.

Enable it through the new unified --trace-to flag:

$ devenv --trace-to otlp-grpc shell
$ devenv --trace-to otlp-http-protobuf:http://localhost:4318 shell

Three OTLP formats are supported: otlp-grpc (built in), otlp-http-protobuf, and otlp-http-json (opt in via cargo features). Endpoints can be set on the flag or via the standard OTEL_EXPORTER_OTLP_* variables.

Trace context propagates across process boundaries: spawned tasks, shell commands, and processes inherit TRACEPARENT and TRACESTATE, so instrumented children show up on the same trace as the parent devenv up run.

--trace-to replaces --trace-output and --trace-format with a single [format:]destination syntax, and accepts multiple destinations:

$ devenv --trace-to pretty:stderr --trace-to otlp-grpc shell
$ DEVENV_TRACE_TO=json:file:/tmp/trace.json,otlp-grpc devenv shell

Tasks and processes

devenv tasks run defaults to before mode, so dependencies run too (devenv#2551); --mode single restores the old behavior. The same --mode flag now also controls which processes devenv up starts (devenv#2721).

Tasks can print messages on shell entry by writing to $DEVENV_TASK_OUTPUT_FILE (devenv#2500).

And more

Nix 2.34. Multithreaded tarball unpacking, evaluator performance improvements, and REPL enhancements.

require_version in devenv.yaml. Enforce a minimum devenv CLI version for your project. Set require_version: true to match the modules version, or use a constraint string like ">=2.1" (devenv#2391).

ROCm support. New nixpkgs.rocmSupport option for enabling ROCm in nixpkgs configuration.

Full stack traces on error. show-trace is now always enabled, so evaluation errors include the full stack trace instead of a truncated message suggesting a nonexistent --show-trace flag (devenv#2725).

Ctrl+X to stop processes. Stop individual processes from the TUI while keeping them visible and restartable.

Ctrl+H to hide stopped processes. Toggle hiding stopped processes in the TUI to focus on what’s still running. Failed processes stay visible, and the process count shows how many are hidden (devenv#2692).

Port allocation fixes. Port values (config.processes.<name>.ports.<port>.value) now resolve correctly in devenv shell and devenv tasks run, matching the ports allocated by devenv up (devenv#2710). Ports bound to 0.0.0.0 or [::] are now detected, preventing multiple devenv instances from allocating the same port (devenv#2567). Strict port restarts no longer fail with “port already in use” during kernel socket teardown (devenv#2647).

Dozens of other bug fixes. File watcher deduplication, import precedence, eval cache consistency, process lifecycle fixes, and terminal compatibility improvements. See the full changelog for details.

Breaking changes

devenv tasks run now runs dependencies by default (before mode instead of single). Use --mode single for the old behavior.

Final words

Open an issue or join the Discord with feedback.

Domen

devenv 2.0: A Fresh Interface to Nix

Thu, 05 Mar 2026 00:00:00 GMT

You type nix develop. The terminal fills with a single cryptic line: copying path, 47 of 312, 28.3 MiB, something something NAR. Five seconds. Ten. Is it evaluating? Downloading? Both? You change one line in your config and wait again. When it finally drops you into a shell, you switch to another branch and direnv hijacks your prompt for a rebuild you didn’t ask for. You switch back, and Nix evaluates everything from scratch, even though nothing changed.

Nix gives you reproducibility that nothing else can match. But the moment to moment experience of using it has never matched the power underneath.

devenv 2.0 polishes Nix developer experience. Keeps the power, removes frictions. Here’s what that looks like.

Interactive

To fully leverage what’s going on in your development shell, we’ve made it fully interactive.

Terminal UI

Every devenv command now shows a live terminal interface. Instead of scrolling Nix build logs, you see structured progress: what Nix is evaluating, how many derivations need to be built and downloaded, task execution with dependency hierarchy, and error details that expand automatically on failure.

Native shell reloading

You save a file, direnv fires, your prompt locks up for thirty seconds while Nix rebuilds, and you sit there staring at a frozen terminal.

With native shell, you save a file, devenv rebuilds in the background, a status line at the bottom of your terminal shows progress, and you press Ctrl+Alt+R when you’re ready to apply the new environment. Your shell stays interactive the entire time. If the rebuild fails, the error appears in the status line without disrupting your session.

An example empty environment with only joe package:

devenv.nix

{ pkgs, ... }:

{
  packages = [ pkgs.joe ];
}

Shell reloading is currently supported for bash, with fish and zsh coming soon (#2487).

direnv isn’t needed anymore with devenv shell but it’s still supported for automatic activation when switching directories; see the direnv integration

Native process manager

devenv 2.0 ships a built in Rust process manager that replaces process-compose.

Dependency ordering, restart policies, readiness probes (exec, HTTP, and systemd notify), systemd socket activation, watchdog heartbeats, file watching, and port allocation. All declarative, all in one place. Dependencies use @ready by default (wait for the probe to pass) or @completed (wait for the process to exit). You can freely mix processes and tasks in the same dependency chains.

devenv.nix

{ pkgs, config, ... }:

{
  services.postgres.enable = true;

  processes = {
    api = {
      exec = "${pkgs.python3}/bin/python -m http.server ${toString config.processes.api.ports.http.value}";
      after = [ "devenv:processes:postgres" ];
      ports.http.allocate = 8080;
      ready.http.get = {
        port = config.processes.api.ports.http.value;
        path = "/";
      };
    };

    worker = {
      exec = ''
        echo "Worker connected to API on port ${toString config.processes.api.ports.http.value}"
        exec sleep infinity
      '';
      after = [ "devenv:processes:api" ];
    };
  };
}

This foundation opens the door to a fully integrated development loop: running processes in the background directly from your shell session, and automatically restarting them when the shell reloads.

process-compose is still available via process.manager.implementation = "process-compose". If something is missing from the native manager, let us know.

Instant

Run devenv shell. Wait a few seconds while Nix evaluates your configuration and builds what’s needed. Now run it again.

This time it takes milliseconds.

Most of the performance gain comes from replacing multiple nix CLI invocations with a C FFI backend built on nix-bindings-rust. Instead of spawning five or more separate Nix processes per command, devenv 2.0 calls the Nix evaluator and store directly through the C API, evaluating one attribute at a time. This also gives us better error messages and real time progress in the TUI. We currently carry patches against Nix to extend the C FFI interface, but these are fully upstreamable and we plan to contribute them back. Thanks to Robert Hensing for creating nix-bindings-rust and making this possible.

This makes the evaluation cache incremental. Each evaluated attribute is cached individually along with the files and environment variables it touched. When you change one thing, only the attributes that depend on that change are re-evaluated; everything else is served from cache. A single evaluation now covers devenv shell, devenv test, devenv build, and every other command. When nothing changed (verified by content hash), the cached result is returned immediately without invoking Nix at all.

The cache invalidates when:

Any source file that was read during evaluation changes
Environment variables that were accessed during evaluation change
The devenv version, system, or configuration options change

You can force a refresh with --refresh-eval-cache or disable caching with --no-eval-cache.

Polyrepo support

Most teams don’t live in a single repo. You have a backend in one repository, a frontend in another, shared libraries in a third.

Referencing outputs from another devenv project was the third most upvoted issue. Now you can reference any option or output from another project through inputs.<name>.devenv.config:

devenv.yaml

inputs:
  my-service:
    url: github:myorg/my-service
    flake: false

devenv.nix

{ inputs, ... }:
let
  my-service = inputs.my-service.devenv.config.outputs.my-service;
in {
  packages = [ my-service ];
  processes.my-service.exec = "${my-service}/bin/my-service";
}

This builds on the existing monorepo support and extends it to multi-repository workflows. See the polyrepo guide for full documentation.

Out of tree devenvs

Not every project has a devenv.nix checked in, and sometimes you want one configuration to serve multiple repositories. This was the fourth most upvoted issue. devenv 2.0 adds --from:

$ devenv shell --from github:myorg/devenv-configs?dir=rust-web
$ devenv shell --from path:../shared-config

Works with devenv shell, devenv test, and devenv build. Currently --from only works with projects that use devenv.nix alone; projects that also rely on devenv.yaml for extra inputs aren’t supported yet.

For coding agents

A coding agent spins up your project in the background. It starts the dev server. Port 8080 is already taken by another agent running the same project. The process crashes. The agent retries, hits the same port, crashes again.

Meanwhile, that agent has full read access to every .env file in your project. Your API keys, database credentials, third party tokens. It never asks permission. It never tells you what it read.

devenv 2.0 fixes both problems.

Automatic port allocation

Define named ports and devenv finds free ones automatically:

devenv.nix

{ config, ... }:

{
  processes.server = {
    ports.http.allocate = 8080;
    exec = "python -m http.server ${toString config.processes.server.ports.http.value}";
  };
}

If port 8080 is taken, devenv tries 8081, 8082, and so on. Ports are held during evaluation to prevent races, then released just before the process starts. Use devenv up --strict-ports to fail instead of searching.

Secret isolation with SecretSpec

devenv 2.0 ships with SecretSpec 0.7.2 for declarative, provider-agnostic secrets management. Declare what secrets your project needs in secretspec.toml, and each developer provides them from their preferred backend: keyring, dotenv, 1Password, or environment variables.

Here’s the thing: because password managers prompt for credentials before giving them out, secrets are never silently leaked to agents running in the background. This is a fundamental difference from .env files that any process can read.

Let’s declare some secrets:

secretspec.toml

[project]
name = "myapp"
revision = "1.0"

[profiles.default]
DATABASE_URL = { description = "PostgreSQL connection string", required = true }
STRIPE_KEY = { description = "Stripe API secret key", required = true }
SENTRY_DSN = { description = "Sentry error tracking DSN", required = false }

And see how devenv asks for them and starts:

MCP server

The devenv MCP server exposes package and option search over stdio and HTTP:

$ devenv mcp --http 8080

We host a public instance at mcp.devenv.sh that any MCP compatible tool can query without needing a local devenv installation.

devenv.new is a coding agent powered by the same package and option search that generates devenv.nix files for you.

And more

Language servers for your code. Most language modules now have lsp.enable and lsp.package options, giving you a language server for your project out of the box.

Language server for devenv.nix. Get completion and diagnostics while editing your devenv configuration:

$ devenv lsp

devenv eval. Evaluate any attribute in devenv.nix and return JSON:

$ devenv eval languages.rust.channel services.postgres.enable
{
  "languages.rust.channel": "stable",
  "services.postgres.enable": true
}

devenv build returns JSON. devenv build now outputs structured JSON mapping attribute names to store paths:

$ devenv build languages.rust.channel services.postgres.enable
{
  "languages.rust.channel": "/nix/store/...-stable",
  "services.postgres.enable": "/nix/store/...-postgresql-16.6"
}

NIXPKGS_CONFIG. devenv now sets a global NIXPKGS_CONFIG environment variable, ensuring that nixpkgs configuration (like allowUnfree, CUDA settings) is consistently applied across all Nix operations within the environment.

Breaking changes

For a step by step upgrade guide, see Migrating to devenv 2.0.

The git-hooks input is no longer included by default. If you use git-hooks.hooks, add it to your devenv.yaml.
devenv container --copy <name> has been removed. Use devenv container copy <name>.
devenv build now outputs JSON instead of plain store paths. Update any scripts that parse the output.
The native process manager is now the default. Set process.manager.implementation = "process-compose" if you need the old behavior.

Deprecation of devenv 0.x

devenv 0.x is now deprecated. Support will be dropped entirely in devenv 3.

Final words

Over the next few weeks we will be focused on fixing bugs and stabilizing the release. If you run into any issues, please open a report and we will prioritize it. Join the devenv Discord community to share feedback!

Domen

SecretSpec 0.7: Declarative Secret Generation

Mon, 09 Feb 2026 00:00:00 GMT

If you haven’t tried SecretSpec yet, see Announcing SecretSpec for an introduction.

SecretSpec 0.7 introduces declarative secret generation — declare that secrets should be auto-generated when missing, directly in your secretspec.toml.

The Problem

When onboarding to a project, developers typically need to:

Read docs to understand which secrets are needed
Manually generate passwords and tokens
Store them in the right provider

Some secrets — like local database passwords or session keys — don’t need to be shared at all. They just need to exist.

The Solution: `type` + `generate`

Add type and generate to any secret declaration, and SecretSpec handles the rest:

[project]
name = "my-app"
revision = "1.0"

[profiles.default]
DB_PASSWORD = { description = "Database password", type = "password", generate = true }
API_TOKEN = { description = "Internal API token", type = "hex", generate = { bytes = 32 } }
SESSION_KEY = { description = "Session signing key", type = "base64", generate = { bytes = 64 } }
REQUEST_ID = { description = "Request ID prefix", type = "uuid", generate = true }

Run secretspec check or secretspec run, and any missing secret with generate configured is automatically created and stored in your provider:

$ secretspec check
Checking secrets in my-app (profile: default)...

✓ DB_PASSWORD - generated and saved to keyring (profile: default)
✓ API_TOKEN - generated and saved to keyring (profile: default)
✓ SESSION_KEY - generated and saved to keyring (profile: default)
✓ REQUEST_ID - generated and saved to keyring (profile: default)

Summary: 4 found, 0 missing

On subsequent runs, the stored values are reused — generation is idempotent.

Five Generation Types

Type	Default Output	Options
`password`	32 alphanumeric characters	`length`, `charset` (`"alphanumeric"` or `"ascii"`)
`hex`	64 hex characters (32 bytes)	`bytes`
`base64`	44 characters (32 bytes)	`bytes`
`uuid`	UUID v4	none
`command`	stdout of a shell command	`command` (required)

Custom Options

Use a table instead of true for fine-grained control:

# 64-character password with printable ASCII
ADMIN_PASSWORD = { description = "Admin password", type = "password", generate = { length = 64, charset = "ascii" } }

# 64 random bytes, hex-encoded (128 chars)
ENCRYPTION_KEY = { description = "Encryption key", type = "hex", generate = { bytes = 64 } }

Shell Commands

The command type runs arbitrary shell commands, covering any generation need:

# WireGuard private key
WG_PRIVATE_KEY = { description = "WireGuard key", type = "command", generate = { command = "wg genkey" } }

# MongoDB keyfile
MONGO_KEYFILE = { description = "MongoDB keyfile", type = "command", generate = { command = "openssl rand -base64 765" } }

# SSH public key (from existing key)
SSH_PUBKEY = { description = "SSH public key", type = "command", generate = { command = "ssh-keygen -y -f ~/.ssh/id_ed25519" } }

Design Decisions

Generate if missing, never overwrite. Existing secrets are always preserved. This makes generation safe to declare in shared config files — it only fills in gaps.

No separate generate command. Generation happens automatically during check and run. A dedicated CLI command for rotation is planned for a future release.

type without generate is valid. You can annotate secrets with a type for documentation purposes without enabling generation. This is useful for secrets that must be manually provisioned but benefit from type metadata.

Conflicts are caught early. generate + default on the same secret is an error (which value should win?). type = "command" with generate = true (no command string) is also an error.

Upgrading

Update to SecretSpec 0.7 and add type/generate to any secrets you want auto-generated. Existing configurations continue to work without changes — both fields are optional.

curl -sSL https://install.secretspec.dev | sh

See the configuration reference for full documentation.

Share your thoughts on our Discord community or open an issue on GitHub.

Domen

devenv 1.11: Module changelogs and SecretSpec 0.4.0

Wed, 26 Nov 2025 00:00:00 GMT

devenv 1.11 brings the following improvements:

Module changelogs for communicating breaking changes
Profile configuration in devenv.yaml
SecretSpec 0.4.0 with multiple provider support and file-based secrets

Module changelogs

The Nix module system already handles renames and deprecations well—you get clear warnings when using old option names. But communicating behavior changes is harder. When a default value changes or a feature works differently, users often discover this through unexpected behavior rather than explicit notification.

Recently we’ve wanted to change git-hooks.package from pkgs.pre-commit to pkgs.prek, a reimplementation in Rust.

The new changelog option lets module authors declare important changes directly in their modules:

devenv.nix

{ config, ... }: {
  changelogs = [
    {
      date = "2025-11-26";
      title = "git-hooks.package now defaults to pkgs.prek";
      when = config.git-hooks.enable;
      description = ''
        The git-hooks integration now uses [prek](https://github.com/cachix/prek) by default for speed and smaller binary size.

        If you were using pre-commit hooks, update your configuration:
        ```nix
        git-hooks.package = pkgs.pre-commit;
        ```
      '';
    }
  ];
}

Each entry includes:

date: When the change was introduced (YYYY-MM-DD)
title: Short summary of what changed
when: Condition for showing this changelog (show only to affected users)
description: Markdown-formatted details and migration steps

After running devenv update, relevant new changelogs are displayed automatically:

$ devenv update
...

📋 changelog

2025-11-24: **git-hooks.package now defaults to pkgs.prek**

  The git-hooks integration now uses prek by default.

  If you were using pre-commit hooks, update your configuration:
    git-hooks.package = pkgs.pre-commit;

The when condition ensures changelogs only appear to users who have the relevant feature enabled. A breaking change to PostgreSQL configuration won’t bother users who don’t use PostgreSQL.

View all relevant changelogs anytime with:

$ devenv changelogs

For module authors

If you maintain devenv modules (either in-tree or as external imports), add changelog entries when making breaking changes. This helps your users stay informed without requiring them to read through commit history or release notes.

See the contributing guide for details.

Profile configuration in devenv.yaml

You can now specify the default profile in devenv.yaml or devenv.local.yaml:

devenv.yaml

profile: fullstack

This can be overridden with the --profile CLI flag.

SecretSpec 0.4.0

We’ve released SecretSpec 0.4.0 with two major features: multiple provider support and file-based secrets.

Multiple providers with fallback chains

You can now configure different providers for individual secrets, with automatic fallback:

secretspec.toml

[profiles.production]
DATABASE_URL = { description = "Production DB", providers = ["prod_vault", "keyring"] }
API_KEY = { description = "API key", providers = ["env"] }

Define provider aliases in your user config:

$ secretspec providers add prod_vault onepassword://vault/Production
$ secretspec providers add shared_vault onepassword://vault/Shared

When multiple providers are specified, SecretSpec tries each in order until it finds the secret. This enables:

Shared vs local: Try a team vault first, fall back to local keyring
Migration: Gradually move secrets between providers
Multi-source setups: Projects that need to source secrets from different providers

Combine that with profile-level defaults to avoid repetition:

[profiles.production.defaults]
providers = ["prod_vault", "keyring"]
required = true

[profiles.production]
DATABASE_URL = { description = "Production DB" }  # Uses default providers
API_KEY = { description = "API key", providers = ["env"] }  # Override

Provisioning secrets as a file

Some tools require secrets as file paths rather than values—certificates, SSH keys, service account credentials.

[profiles.default]
TLS_CERT = { description = "TLS certificate", as_path = true }

With as_path = true, SecretSpec writes the secret value to a secure temporary file and returns the path instead:

$ secretspec get TLS_CERT
/tmp/secretspec-abc123/TLS_CERT

In Nix, we don’t want to leak secrets into the world-readable store, so passing them as paths avoids this issue:

devenv.nix

{ pkgs, config, ... }: {
  services.myservices.certPath = config.secretspec.secrets.TLS_CERT;
}

Temporary files are automatically cleaned up when the resolved secrets are dropped.

If you haven’t tried SecretSpec yet, see Announcing SecretSpec for an introduction.

Getting started

New to devenv? Check out the getting started guide.

Join the devenv Discord community to share feedback!

Domen

devenv 1.10: monorepo Nix support with devenv.yaml imports

Tue, 07 Oct 2025 00:00:00 GMT

devenv 1.10 brings new capabilities for structuring monorepo projects:

absolute/parent path imports
git root prefixing
devenv.yaml imports
devenv.local.yaml support
monorepo guide

Absolute / parent path imports

Paths starting with / are now resolved from your git repository root, and parent imports are also supported (#998).

This lets services consistently reference shared configurations:

services/worker/devenv.yaml

imports:
  - /nix/devenv.nix
  - ../api/devenv.nix

This is particularly handy in monorepos where projects are nested at different depths:

my-monorepo/
├── nix/
│   └── devenv.nix       # Shared base configuration
├── services/
│   ├── api/
│   │   └── devenv.yaml  # imports: [/nix]
│   └── worker/
│       └── devenv.yaml  # imports: [/nix]
└── apps/
    └── web/
        └── devenv.yaml  # imports: [/nix]

All three projects reference /nix regardless of their location.

Git root prefixing

The new config.git.root variable provides the git repository root path for specifying working directories in tasks and processes (#1850, #316).

services/api/devenv.nix

{ config, ... }: {
  tasks."db:migrate" = {
    exec = "npm run migrate";
    cwd = "${config.git.root}/services/api";
  };

  processes.api = {
    exec = "npm start";
    cwd = "${config.git.root}/services/api";
  };
}

Useful when reusing modules across different directories.

devenv.yaml imports

Most upvoted feature with 75 votes (#14) is here!

Local imports now load and merge both devenv.nix and devenv.yaml configurations:

shared/devenv.yaml

allowUnfree: true
inputs:
  nixpkgs:
    url: github:NixOS/nixpkgs/nixpkgs-unstable

services/api/devenv.yaml

imports:
  - /shared

The API service inherits the allowUnfree setting and nixpkgs input. Note that this merging only applies to local filesystem imports — imports from inputs still only load Nix configurations (#2205).

devenv.local.yaml support

Just like devenv.local.nix, you can now use devenv.local.yaml for developer-specific overrides (#817).

Both files are git-ignored for local overrides:

devenv.local.yaml

allowUnfree: true

Monorepo guide

Check out the new Monorepo Guide for detailed examples and patterns.

Join the devenv community to share your monorepo experience!

Domen

devenv 1.9: Scaling Nix projects using modules and profiles

Wed, 17 Sep 2025 00:00:00 GMT

Profiles are a new way to organize and selectively activate parts of development environment.

While we try our best to ship sane defaults for languages and services, each team has its own preferences. We’re still working on uniform interface for language configuration so you’ll be able to customize each bit of the environment.

Typically, these best practices are created using scaffolds, these quickly go out of date and don’t have the ability to ship updates in a central place.

On top of that, when developing in a repository with different components, it’s handy to be able to activate only part of the development environment.

Extending devenv modules

Teams can define their own set of recommended best practices in a central repository to create even more opinionated environments:

devenv.nix

{ lib, config, pkgs, ... }: {
  options.myteam = {
    languages.rust.enable = lib.mkEnableOption "Rust development stack";
    services.database.enable = lib.mkEnableOption "Database services";
  };

  config = {
    packages = lib.mkIf config.myteam.languages.rust.enable [
      pkgs.cargo-watch
    ];

    languages.rust = lib.mkIf config.myteam.languages.rust.enable {
      enable = true;
      channel = "nightly";
    };

    services.postgres = lib.mkIf config.myteam.services.database.enable {
      enable = true;
      initialScript = "CREATE DATABASE myapp;";
    };
  };
}

We have defined our defaults for myteam.languages.rust and myteam.services.database.

Using Profiles

Once you have your team module defined, you can start using it in new projects:

devenv.yaml

inputs:
  myteam:
    url: github:myorg/devenv-myteam
    flake: false
imports:
- myteam

This automatically includes your centrally managed module.

Since options default to false, you’ll need to enable them per project. You can enable common defaults globally and use profiles to activate additional components on demand:

devenv.nix

{ pkgs, config, ... }: {
  packages = [ pkgs.jq ];

  profiles = {
    backend.module = {
      myteam.languages.rust.enable = true;
      myteam.services.database.enable = true;
    };

    frontend.module = {
      languages.javascript.enable = true;
    };

    fullstack.extends = [ "backend" "frontend" ];
  };
}

Let’s do some Rust development with the base configuration:

$ devenv --profile backend shell

Using backend profile to launch the database:

$ devenv --profile backend up

Using frontend profile for JavaScript development:

$ devenv --profile frontend shell

Using fullstack profile to get both backend and frontend tools (extends both profiles):

$ devenv --profile fullstack shell

The fullstack profile automatically includes everything from both the backend and frontend profiles through extends. Use ad-hoc environment options to further customize:

$ devenv -P fullstack -O myteam.languages.rust.enable:bool false shell

User and Hostname Profiles

Profiles can activate automatically based on hostname or username:

{
  profiles = {
    hostname."dev-server".module = {
      myteam.services.database.enable = true;
    };

    user."alice".module = {
      myteam.languages.rust.enable = true;
    };
  };
}

When user alice runs devenv shell on dev-server hostname, both her user profile and the hostname profile automatically activate.

This gives teams fine-grained control over development environments while keeping individual setups simple and centralized.

Profile priorities

To keep profile-heavy projects from fighting each other we wrap every profile module in an automatic override priority. The base configuration is applied first, hostname profiles stack on top, then user profiles, and finally any manual --profile flags—if you pass several, the last flag wins. Extends chains apply parents before children so overrides land where you expect.

Here is a simple example where every tier toggles the same option, yet the final value stays deterministic:

{ config, ... }: {
  myteam.services.database.enable = false;

  profiles = {
    hostname."dev-server".module = {
      myteam.services.database.enable = true;
    };

    user."alice".module = {
      myteam.services.database.enable = false;
    };

    qa.module = {
      myteam.services.database.enable = true;
    };
  };
}

Alice starting a shell on dev-server will see the base configuration turn the database off, the hostname profile enable it, her user profile disable it again, and a manual devenv --profile qa shell flip it back on. Even with conflicting assignments, priorities make the outcome predictable and avoid merge conflicts.

Building Linux containers on macOS

Oh, we’ve also removed restriction so you can now build containers on macOS if you configure a linux builder.

Containers are likely to get a simplification redesign, as we’ve learned a lot since they were introduced in devenv 0.6.

Getting Started

New to devenv? Start with the getting started guide to learn the basics.

Check out the profiles documentation for complete examples.

Join the devenv Discord community to share how your team uses profiles!

Domen

Closing the Nix Gap: From Environments to Packaged Applications for Rust

Fri, 22 Aug 2025 00:00:00 GMT

Should I use crate2nix, cargo2nix, or naersk for packaging my Rust application?
— (@jvmncs) January 21, 2025

This tweet shows a common problem in Nix: “Should I use crate2nix, cargo2nix, or naersk for packaging my Rust application?”

devenv solved this for development environments differently: instead of making developers package everything with Nix, we provide tools through a simple languages.rust.enable. You get cargo, rustc, and rust-analyzer in your shell without understanding Nix packaging.

But when you’re ready to deploy, you face the same problem: which lang2nix tool should you use? Developers don’t want to compare crate2nix vs cargo2nix vs naersk vs crane—they want a tested solution that works.

devenv now provides languages.rust.import, which packages Rust applications using crate2nix. We evaluated the available tools and chose crate2nix, so you don’t have to.

We’ve done this before. In PR #1500, we replaced fenix with rust-overlay for Rust toolchains because rust-overlay was better maintained. Users didn’t need to change anything—devenv handled the transition while keeping the same languages.rust.enable = true interface.

One Interface for All Languages

The typical workflow:

Development: Enable the language (languages.rust.enable = true) to get tools like cargo, rustc, and rust-analyzer.
Packaging: When ready to deploy, use languages.rust.import to package with Nix.

The same pattern works for all languages:

{ config, ... }: {
  # https://devenv.sh/languages
  languages = {
    rust.enable = true;
    python.enable = true;
    go.enable = true;
  };

  # https://devenv.sh/outputs
  outputs = {
    rust-app = config.languages.rust.import ./rust-app {};
    python-app = config.languages.python.import ./python-app {};
    go-app = config.languages.go.import ./go-app {};
  };
}

Starting with Rust

languages.rust.import automatically generates Nix expressions from Cargo.toml and Cargo.lock.

Add the crate2nix input:

$ devenv inputs add crate2nix github:nix-community/crate2nix --follows nixpkgs

Import your Rust application:

{ config, ... }:
let
  # ./app is the directory containing your Rust project's Cargo.toml
  myapp = config.languages.rust.import ./app {};
in
{
  # Provide developer environment
  languages.rust.enable = true;

  # Expose our application inside the environment
  packages = [ myapp ];

  # https://devenv.sh/outputs
  outputs = {
    inherit myapp;
  };
}

Build your application:

$ devenv build outputs.myapp

Other Languages

This API extends to other languages, each using the best packaging tool:

We’ve also started using uv2nix to provide a similar interface for Python in PR #2115.

That’s it

For feedback, join our Discord community.

Domen

devenv devlog: Processes are now tasks

Fri, 25 Jul 2025 00:00:00 GMT

Building on the task runner, devenv now exposes all processes as tasks named devenv:processes:<name>.

Now you can run tasks before or after a process runs - addressing a frequently requested feature for orchestrating the startup sequence.

Usage

Execute setup tasks before the process starts

devenv.nix

{
  processes.backend = {
    exec = "cargo run --release";
  };

  tasks."db:migrate" = {
    exec = "diesel migration run";
    before = [ "devenv:processes:backend" ];
  };
}

When you run devenv up or the individual process task, migrations run first.

Run cleanup after the process stops

devenv.nix

{
  processes.app = {
    exec = "node server.js";
  };

  tasks."app:cleanup" = {
    exec = ''
      rm -f ./server.pid
      rm -rf ./tmp/*
    '';
    after = [ "devenv:processes:app" ];
  };
}

Implementation

Under the hood, process-compose now runs processes through devenv-tasks run --mode all devenv:processes:<name> instead of executing them directly. This preserves all existing process functionality while adding task capabilities.

The --mode all flag ensures that both before and after tasks are executed, maintaining the expected lifecycle behavior.

What’s next?

Future work on process dependencies (#2037) will also address native health check support (process-compose#371), eliminating the need for manual polling scripts.

Domen

devenv 1.8: Progress TUI, SecretSpec Integration, Listing Tasks, and Smaller Containers

Tue, 22 Jul 2025 00:00:00 GMT

devenv 1.8 fixes a couple of ~~annoying~~ regressions since the 1.7 release, but also includes several new features:

Progress TUI with async core
SecretSpec integration for declarative secrets management
Task improvements with task listing
CLI improvements with package options support
Smaller containers with 67% smaller images

Progress TUI

We’ve rewritten our tracing integration to improve reporting on what devenv is doing.

More importantly, devenv is now fully asynchronous under the hood, enabling parallel execution of operations. This means faster performance in scenarios where multiple independent tasks can run simultaneously.

The new progress interface provides real-time feedback on what devenv is doing:

We’re continuing to improve visibility into Nix operations to give you even better insights into the build process.

SecretSpec Integration

We’ve integrated SecretSpec, a new standard for declarative secrets management that separates secret declaration from provisioning.

This allows teams to define what secrets applications need while letting each developer, CI system, and production environment provide them from their preferred secure provider.

Learn more in Announcing SecretSpec Declarative Secrets Management.

Task improvements

Listing tasks

The devenv tasks list command now groups tasks by namespace, providing a cleaner and more organized view:

$ devenv tasks list
backend:
  └── lint (has status check)
      └── test
          └── build (watches: src/backend/**/*.py)
deploy:
  └── production
docs:
  └── generate (watches: docs/**/*.md)
      └── publish
frontend:
  └── lint
      └── test (has status check)
          └── build

Running multi-level tasks

You can now run tasks at any level in the hierarchy. By default, tasks run in single mode (only the specified task):

# Run only frontend:build (default single mode)
$ devenv tasks run frontend:build
Running tasks     frontend:build
Succeeded         frontend:build                           5ms
1 Succeeded                         5.75ms

# Run frontend:build with all its dependencies (before mode)
$ devenv tasks run frontend:build --mode before
Running tasks     frontend:build
Succeeded         frontend:lint                            4ms
Succeeded         frontend:test                            10ms
Succeeded         frontend:build                           4ms
3 Succeeded                         20.36ms

# Run frontend:build and all tasks that depend on it (after mode)
$ devenv tasks run frontend:build --mode after
Running tasks     frontend:build
Succeeded         frontend:build                           5ms
Succeeded         deploy:production                        5ms
2 Succeeded                         11.44ms

CLI improvements

Package options support

The CLI now supports specifying single packages via the --option flag (#1988). This allows for more flexible package configuration directly from the command line:

$ devenv shell --option "languages.java.jdk.package:pkg" "graalvm-oracle"

Container optimizations

The CI container ghcr.io/cachix/devenv/devenv:v1.8 has been reduced (uncompressed) from 1,278 MB in v1.7 to 414 MB in v1.8—that’s a reduction of over 860 MB (67% smaller!).

This makes devenv container much faster to pull and more efficient in CI/CD pipelines.

Thank You

Join our Discord community to share your experiences and help shape devenv’s future!

Domen

Announcing SecretSpec: Declarative Secrets Management

Mon, 21 Jul 2025 00:00:00 GMT

We’ve supported .env integration for managing secrets, but it has several issues:

Apps are disconnected from their secrets - applications lack a clear contract about which secrets they need
Parsing .env is unclear - comments, multiline values, and special characters all have ambiguous behavior across different parsers
Password manager integration is difficult - requiring manual copy-paste or template workarounds
Vendor lock-in - applications use custom parsing logic, making it hard to switch providers
No encryption - .env files are stored as plain text, vulnerable to accidental commits or unauthorized access

While we could recommend solutions like dotenvx to encrypt .env files or sops for general secret encryption, these bring new challenges:

Don't you feel some anxiety given we've normalized committing encrypted secrets to git repos?
— Domen Kožar (@domenkozar) July 18, 2025

Single key management - requires distributing and managing a master key
Trust requirements - everyone with the key can decrypt all secrets
Rotation complexity - departing team members require key rotation and re-encrypting all secrets

Larger teams often adopt solutions like OpenBao (the open source fork of HashiCorp Vault), requiring significant infrastructure and operational overhead. Smaller teams face a gap between simple .env files and complex enterprise solutions.

What if instead of choosing one tool, we declared secrets uniformly and let each environment use its best provider?

The Hidden Problem: Conflating Three Concerns

We’ve created SecretSpec and integrated it into devenv. SecretSpec separates secret management into three distinct concerns:

WHAT - Which secrets does your application need? (DATABASE_URL, API_KEY)
HOW - Requirements (required vs optional, defaults, validation, environment)
WHERE - Where are these secrets stored? (environment variables, Vault, AWS Secrets Manager)

By separating these concerns, your application declares what secrets it needs in a simple TOML file. Each developer, CI system, and production environment can provide those secrets from their preferred secure storage - without changing any application code.

One Spec, Multiple Environments, Different Providers

Imagine you commit a secretspec.toml file that declares:

# secretspec.toml - committed to your repo
[project]
name = "my-app"
revision = "1.0"

[profiles.default]
DATABASE_URL = { description = "PostgreSQL connection string", required = true }
REDIS_URL = { description = "Redis connection string", required = false }
STRIPE_API_KEY = { description = "Stripe API key", required = true }

[profiles.development]
# Inherits from default profile - only override what changes
DATABASE_URL = { default = "postgresql://localhost/myapp_dev" }
REDIS_URL = { default = "redis://localhost:6379" }
STRIPE_API_KEY = { description = "Stripe API key (test mode)" }

[profiles.production]
# Production keeps strict requirements from default profile

Now, here’s the magic:

You (on macOS): Store it in Keychain, retrieve with secretspec --provider keyring run -- cmd args
Your teammate (on Linux): Store it in GNOME Keyring, same command works
That one developer: Still uses a .env file locally (we don’t judge, we’ve been there)
CI/CD: Reads from environment variables in GitHub Actions secretspec --provider env run -- cmd args
Production: Secrets get provisioned using AWS Secret Manager

Same specification. Different providers. Zero code changes.

Example: One Spec, Three Environments

Let’s walk through migrating from .env to SecretSpec.

Setting up secretspec for development

First, choose your default provider and profile:

$ secretspec config init
? Select your preferred provider backend:
> keyring: Uses system keychain (Recommended)
  onepassword: OnePassword password manager
  dotenv: Traditional .env files
  env: Read-only environment variables
  lastpass: LastPass password manager
? Select your default profile:
> development
  default
  none
✓ Configuration saved to ~/.config/secretspec/config.toml

Importing secrets

Create secretspec.toml from your existing .env:

$ secretspec init --from dotenv

1. Local Development with devenv (You’re on macOS)

Enable SecretSpec in devenv.yaml:

secretspec:
  enable: true

In devenv.nix:

{ pkgs, lib, config, ... }:

{
  languages.rust.enable = true;

  services.minio = {
    enable = true;
    buckets = [ config.secretspec.secrets.BUCKET_NAME ];
  };
}

Start the minio process:

$ devenv up
✓ Starting minio...

2. CI/CD (GitHub Actions)

.github/workflows/test.yml

- name: Run tests
  env:
    DATABASE_URL: {{ secrets.TEST_DATABASE_URL }}
    STRIPE_API_KEY: {{ secrets.STRIPE_TEST_KEY }}
  run: |
    secretspec run --provider env --profile production -- npm test

3. Production (Fly.io)

fly.toml

[processes]
web = "secretspec run --provider env --profile production -- npm start"

# Set secrets using fly CLI:
# fly secrets set DATABASE_URL=postgresql://... STRIPE_API_KEY=sk_live_...
# SecretSpec will read these from environment variables

Notice what didn’t change? Your secretspec.toml. Same specification, different providers, zero code changes.

Loading secrets in your application

While secretspec run provides secrets as environment variables, your application remains disconnected from knowing which secrets it requires. The Rust SDK bridges this gap by providing type-safe access to your declared secrets.

The Rust SDK provides compile-time guarantees:

// Generate typed structs from secretspec.toml
secretspec_derive::declare_secrets!("secretspec.toml");

fn main() -> Result<(), Box<dyn std::error::Error>> {
    // Load secrets using the builder pattern
    let secretspec = SecretSpec::builder()
        .with_provider("keyring")  // Can use provider name or URI like "dotenv:/path/to/.env"
        .with_profile(Profile::Production)  // Can use string or Profile enum
        .load()?;

    // Access secrets (field names are lowercased)
    println!("Database: {}", secretspec.secrets.database_url);  // DATABASE_URL → database_url
    println!("Stripe: {}", secretspec.secrets.stripe_api_key);  // STRIPE_API_KEY → stripe_api_key

    // Optional secrets are Option<String>
    if let Some(redis) = &secretspec.secrets.redis_url {
        println!("Redis: {}", redis);
    }

    // Access profile and provider information
    println!("Using profile: {}", secretspec.profile);
    println!("Using provider: {}", secretspec.provider);

    // For backwards compatibility, export as environment variables
    secretspec.secrets.set_as_env_vars();

    Ok(())
}

Add to your Cargo.toml:

[dependencies]
secretspec = "0.2.0"
secretspec_derive = "0.2.0"

The application code never specifies where to get secrets - only what it needs through the TOML file. This keeps your application logic clean and portable.

Building SDKs for Other Languages

We’d love to see more SDKs that bring this same declarative approach to Python, JavaScript, Go, and other languages.

A world of possibilities

We’re exploring features for future workflows:

Final words

Let’s make secret management as declarative as package management. Let’s stop sharing .env files over Slack. Let’s build better tools for developers.

Share your thoughts on our Discord community or open an issue on GitHub. We’d love to hear how you handle secrets in your team.

Domen

devenv 1.7: CUDA Support, Enhanced Tasks, and MCP support

Thu, 03 Jul 2025 00:00:00 GMT

devenv 1.7 brings several practical improvements:

CUDA support that works across platforms
MCP support that understands devenv configurations
Tasks that only run when their inputs change
Groundwork for Snix, Rust-based Nix implementation

Progress on Snix Support

We’ve started work on supporting multiple Nix implementations in devenv. The codebase now includes a backend abstraction layer that will allow users to choose between different Nix implementations.

This architectural change paves the way for integrating Snix (our development fork). While the Snix backend isn’t functional yet, the groundwork is in place for building out this Rust-based reimplementation to the C++ Nix implementation. See PR #1950 for implementation details.

Platform-Specific Configuration

Here’s how to enable CUDA support only on Linux systems while keeping your environment working smoothly on macOS:

CUDA-enabled packages are built with GPU support on Linux
macOS developers can still work on the same project without CUDA
The correct CUDA capabilities are set for your target GPUs

devenv.yaml

nixpkgs:
  config:
    allowUnfree: true
    x86_64-linux:
      cudaSupport: true
      cudaCapabilities: ["7.5", "8.6", "8.9"]

Tasks Enhancements

Tasks now skip execution when their input files haven’t changed, using the new execIfModified option:

{
  tasks = {
    "frontend:build" = {
      exec = "npm run build";
      execIfModified = [ "src/**/*.tsx" "src/**/*.css" "package.json" ];
    };

    "backend:compile" = {
      exec = "cargo build --release";
      execIfModified = [ "src/**/*.rs" "Cargo.toml" "Cargo.lock" ];
    };
  };
}

This dramatically speeds up incremental builds by skipping unnecessary work.

Namespace-Based Task Execution

Run all tasks within a namespace using prefix matching:

# Run all frontend tasks
$ devenv tasks run frontend

Model Context Protocol (MCP) Support

devenv now includes a built-in MCP server that enables AI assistants like Claude to better understand and generate devenv configurations:

# Start the MCP server
$ devenv mcp

AI assistants can now:

Search for packages and their options
Understand devenv’s configuration format
Generate valid configurations based on your requirements

Quality of Life Improvements

Shell Integration: Your shell aliases and functions now work correctly
Clean Mode: Fixed shell corruption when using --clean
Error Messages: More helpful error messages when commands fail
State Handling: Automatically recovers from corrupted cache files
Direnv Integration: Fewer unnecessary environment reloads

Upcoming 1.8 Release

Standardized Language Tooling Configuration

All language modules will support the same configuration pattern (PR #1974):

{
  languages.rust.dev = {
    lsp.enable = false;
    debugger.enable = false;
    linter.enable = false;
    formatter.enable = false;
  };
}

Rust Import Functionality

Import Rust projects and their dependencies as Nix packages with the new languages.rust.import configuration (PR #1946):

{
  languages.rust.enable = true;
  languages.rust.import = {
    mypackage = {
      root = ./.;
    };
  };
  packages = languages.rust.import.mypackage.packages;
}

That allows us to bridge the gap between developer environments and fully packaged Rust applications using Nix.

Async Core

Operations that can run in parallel will (PR #1970).

Getting Started

Join our Discord community to share your experiences and help shape devenv’s future.

We’re particularly interested in feedback on the standardized language tooling configuration coming in 1.8 - let us know if this approach works for your use cases!

Domen

devenv 1.6: Extensible Ad-Hoc Nix Environments

Fri, 25 Apr 2025 00:00:00 GMT

devenv 1.6 has been tagged, allowing you to:

Create temporary environments directly from the command line without requiring a devenv.nix file.
Temporarily modify existing environments.

Create Environments on the Fly

Developer environments on demand using the new --option (-O) flag:

$ devenv --option languages.python.enable:bool true \
         --option packages:pkgs "ncdu git ripgrep" \
         shell

This command creates a temporary Python environment without writing any configuration files.

Ad-hoc environments are ideal for quickly testing languages or tools without committing to a full project setup:

$ devenv -O languages.elixir.enable:bool true shell iex

Supported Option Types

The --option flag supports multiple data types, making it flexible for various use cases:

:string for text values
:int for integers
:float for decimal numbers
:bool for true/false values
:path for file paths
:pkgs for specifying Nix packages

GitHub Actions with Matrices

One of the most powerful applications of ad-hoc environments is in CI pipelines, where you can easily implement testing matrices across different configurations:

jobs:
  test:
    strategy:
      matrix:
        python-version: ['3.9', '3.10', '3.11']
    steps:
      - uses: actions/checkout@v3
      - uses: cachix/install-nix-action@v31
      - uses: cachix/cachix-action@v16
        with:
          name: devenv
      - name: Install devenv.sh
        run: nix profile install nixpkgs#devenv
      - name: Test with Python {{ '${{ matrix.python-version }}' }}
        run: |
          devenv --option languages.python.enable:bool true \
                 --option languages.python.version:string {{ '${{ matrix.python-version }}' }} \
                 test

This approach lets you validate your code across multiple language versions or dependency combinations without maintaining separate configuration files for each scenario.

Combining with Existing Configurations

When used with an existing devenv.nix file, --option values override the configuration settings in the file, making it easy to temporarily modify your environment.

Switching Between Environment Profiles

Ad-hoc options are perfect for switching between predefined profiles in your development environment:

$ devenv --option profile:string backend up

This enables you to switch between frontend, backend, or other custom profiles without modifying your configuration files.

See our Profiles guide for more details on setting up and using profiles.

For complete documentation on this feature, visit our Ad-hoc Developer Environments guide.

We’re excited to see how you’ll use ad-hoc environments to streamline your development workflow. Share your feedback on GitHub or join our Discord community!

devenv 1.5: Overlays Support and Performance Improvements

Sun, 13 Apr 2025 00:00:00 GMT

In this release, we’re introducing a powerful Nix concept: overlays for modifying and extending the nixpkgs package set, along with significant performance and TLS certificate improvements.

Overlays: Customizing Your Package Set

Overlays allow you to modify or extend the default package set (pkgs) that devenv uses. This is particularly useful when you need to:

Apply patches to existing packages
Use different versions of packages than what’s provided by default
Add custom packages not available in nixpkgs
Use packages from older nixpkgs versions

Here’s an example of using overlays in your devenv.nix file to apply a patch to the hello package:

{ pkgs, ... }:

{
  # Define overlays to modify the package set
  overlays = [
    # Override an existing package with a patch
    (final: prev: {
      hello = prev.hello.overrideAttrs (oldAttrs: {
        patches = (oldAttrs.patches or []) ++ [ ./hello-fix.patch ];
      });
    })
  ];

  # Use the modified packages
  packages = [ pkgs.hello pkgs.my-tool ];
}

Using packages from a different nixpkgs version

You can even use packages from a different nixpkgs version by adding an extra input to your devenv.yaml:

inputs:
  nixpkgs:
    url: github:cachix/devenv-nixpkgs/rolling
  nixpkgs-unstable:
    url: github:nixos/nixpkgs/nixpkgs-unstable

And then using it in your devenv.nix:

{ pkgs, inputs, ... }:

{
  overlays = [
    (final: prev: {
      nodejs = (import inputs.nixpkgs-unstable {
        system = prev.stdenv.system;
      }).nodejs;
    })
  ];

  # Now you can use the unstable version of Node.js
  languages.javascript.enable = true;
}

For more details and examples, check out the overlays documentation.

TLS Improvements: Native System Certificates

We’ve heard from ZScaler how they are using devenv and we’ve fixed their major annoyance by ensuring devenv now respects system certificates that many enterprises rely on.

macOS Development Enhancements: Custom Apple SDK Support

For macOS developers, we’ve added the ability to customize which Apple SDK is used for development:

{ pkgs, ... }:

{
  apple.sdk = pkgs.apple-sdk_15;
}

This allows you to:

Control exactly which version of the SDK to use
Ensure consistency across development environments
Avoid incompatibilities between different macOS versions

Performance Improvements

Sander further tweaked the performance of developer environment activation at OceanSprint when it can be cached:

Linux: ~500ms -> ~150ms
macOS: ~1300ms -> ~300ms

Join our Discord to share feedback and suggestions!

Domen

devenv 1.4: Generating Nix Developer Environments Using AI

Thu, 13 Feb 2025 00:00:00 GMT

One of the main obstacles in using Nix for development environments is mastering the language itself. It takes time to become proficient writing Nix.

How about using AI to generate it instead:

$ devenv generate a Python project using Torch
• Generating devenv.nix and devenv.yaml, this should take about a minute ...

You can also use devenv.new to generate a new environment.

Generating devenv.nix for an existing project

You can also tell devenv to create a scaffold based on your existing git source code:

$ devenv generate
• Generating devenv.nix and devenv.yaml, this should take about a minute ...

Telemetry

To continually enhance the AI’s recommendations, we collect anonymous data on the environments generated. This feedback helps us train better models and improve accuracy.

Of course, your privacy matters—if you prefer not to participate, just add the --disable-telemetry flag when generating environments. We also adhere to the donottrack standard.

Domen

devenv is switching its Nix implementation to Tvix

Tue, 22 Oct 2024 00:00:00 GMT

In February 2020, I went on a 16-day, 1200km moped trip across northern Thailand with a couple of friends.

Somewhere in northern Thailand near Pai.

As we drove for hours on end, I was listening to an audiobook fittingly called Crossing the Chasm. The book explores the challenges faced by nacent technologies on their way to mainstream adoption.

In the years that followed, I couldn’t help noticing the disconnect between Nix’s devoted user base and its apparent lack of widespread adoption in the broader tech community.

Over 2021 and 2022, I focused my efforts and started nix.dev, a resource for practical and accessible Nix tutorials, thinking that good documentation was the thing holding Nix back. Eventually, I came to the realization that improving documentation alone will only get us so far.

We needed to fix the foundations.

We needed to remove things to reduce the cognitive load when using Nix.

The negative feedback loop

Over the years at Cachix we’ve talked to team after team abandoning Nix and have observed a surprisingly consistent pattern.

Nix is initially introduced by someone enthusiastic about the technology. Then, faced with a steep adoption curve, it is abandoned after backlash from the rest of the team.

Making it trivial for a project to adopt and maintain a development environment is crucial for other team members to see the benefits of Nix.

For example, Shopify was vocal about Nix way back in 2020, but eventually went quiet. Having companies like Shopify adopt Nix would be a major step forward for the whole ecosystem.

An interface as the heart of the Developer Experience

Since the 0.1 release two years ago, we’ve been rapidly iterating on a declarative interface for developer environments. We now have support for over 50 languages and 30 services:

devenv.nix

{ pkgs, config, ... }: {
  packages = [
    pkgs.cargo-watch
  ];

  languages.rust = {
    enable = true;
    channel = "nightly";
    rustflags = "-Z threads=8";
    targets = [ "wasm32-unknown-unknown" ];
  };

  processes = {
    backend.exec = "cargo watch -x run";
  };

  services = {
    postgresql.enable = true;
  };
}

With the introduction of tasks in the 1.2 release and Nix caching in 1.3, we’re pretty happy with the devenv command-line interface and the extensible nature of the module system.

The modular architecture of the module system allows for seamless addition, modification, and removal of configuration options. This flexibility extends to defining your own options for the software you’re writing.

Why do we need a Nix rewrite?

We’ve been using the Nix command-line interface under the hood as a low-level API to the evaluator and Nix store. We would’ve preferred to use something akin to an SDK instead, however the command-line interface was the most sensible interface two years ago out of the available options.

The new C FFI (Foreign Function Interface) could potentially grow into a viable solution, but it would necessitate substantial development effort and still leave us vulnerable to memory-safety issues. Moreover, the architecture of the Nix codebase is structured more as a monolithic framework rather than a modular library.

Ideally, if we’re committing to fixing the developer experience over the next years, we’d want to have Nix implemented as a library in Rust.

Fortunately, such a project already exists and it’s called Tvix. Started by flokli and tazjin in “Rewriting Nix”, Tvix is a re-implementation of Nix in Rust, offering both memory-safety and a library-oriented architecture with independently usable components. Leveraging Rust’s abstractions and ecosystem (e.g. tracing.rs), Tvix is positioned to significantly enhance the developer experience for devenv developers and users.

There are many architectural differences besides the obvious “Rewrite In Rust” cliche, so we’ll talk about them as we start replacing our Nix command-line calls with Tvix libraries, starting with the evaluator.

Integrating the Tvix evaluator

The Nix evaluator directly traverses the abstract syntax tree (AST) during evaluation, while Tvix uses a bytecode virtual machine crafted according to the Crafting Interpreters book.

Tvix compiles Nix code into compact bytecode, then executes it in a virtual machine. This two-step approach offers potential performance benefits and optimization opportunities, like many other interpreted languages.

When you re-evaluate devenv.nix, you’re most likely changing devenv.nix and not one of the few dozen Nix files that come from the devenv repository, or even the few thousand Nix files from the nixpkgs repository that could all be cached as bytecode.

In order to integrate the Tvix evaluator with devenv we’ll need to:

Finish implementing builtins.fetchTree, where we have some ideas on how to simplify the caching layer and get rid of the annoying dependency on GitHub’s rate-limited api.github.com endpoint.
Implement an evaluation debugger that will allow inspecting a program’s state in case of errors.
Finish implementing tvix-eval-jobs that will be used for regression tests against nixpkgs to make sure that the evaluator behaves correctly.
Create debug tooling for when we discover regressions in the evaluator.
Integrate a nix-daemon layer to schedule builds.

We also recently streamed a Let’s explore the Tvix evaluator video for those interested in digging into the code.

Using language-specific package managers as the build system

Once we’ve integrated the evaluator, we can finally generalize building languages using Nix reproducible builds by running the underlying build system to generate Nix expressions:

graph TD
A[devenv];
A -->|Rust| C[Cargo];
A -->|JavaScript| D[npm];
A -->|PHP| E[Composer];
C -->|Cargo.lock| F{Nix};
D -->|package.json| F{Nix};
E -->|composer.lock| F{Nix};

In Build Systems à la Carte, Nix is labelled as a suspending task scheduler.

In the general case, the dependency graph is computed statically, but a dependency can declare its dependencies dynamically as part of the build by returning more Nix code.

That’s when evaluation and build phases start to mix, with evaluation depending on the result of a build, which is typically called import from derivation (as the naming comes from the implementation).

sequenceDiagram
    autonumber
    participant NixEvaluator as Nix evaluator
    participant NixStore as Nix store

    NixEvaluator->>NixEvaluator: evaluate
    NixEvaluator->>NixStore: write derivation
    NixStore->>NixStore: build
    NixStore->>NixEvaluator: read derivation output
    NixEvaluator->>NixEvaluator: evaluate

Since evaluation in Nix is single-threaded, the process described above gets blocked on each build requested during evaluation.

Implementing parallel evaluation in Tvix, after we figure out the architectural details of how it should work, will unlock the ability to support automatic conversion of language-specific build systems into Nix without sacrificing neither the developer experience, nor memory safety.

Final Words

As we embark on this new chapter with Tvix, I’m reminded of the journey that brought us here. It’s been a decade since I wrote the we can do better blog post, highlighting the potential for improvement in configuration management and development environments, and I’m glad to see it all finally coming together.

Keep an eye out for updates and join the discussion:

Attend “devenv is switching to Tvix” talk at NixCon to learn more about our progress and plans.
If you’d like to help out by hacking on Rust and Tvix, join us at OceanSprint for a week of hacking.
Join the devenv Discord community.
Join #tvix-dev on Matrix
Subscribe to the mailing list for future announcements at the bottom of the page.

Domen

devenv 1.3: Instant developer environments with Nix caching

Thu, 03 Oct 2024 00:00:00 GMT

Hot on the heels of the previous release of tasks, we’re releasing devenv 1.3! 🎉

This release brings precise caching to Nix evaluation, significantly speeding up developer environments.

Once cached, the results of a Nix eval or build can be recalled in single-digit milliseconds.

If any of the automatically-detected inputs change, the cache is invalidated and the build is performed.

How does it work?

Behind the scenes, devenv now parses Nix’s internal logs to determine which files and directories were accessed during evaluation.

This approach is very much inspired by lorri, but doesn’t require a daemon running in the background.

The caching process works as follows:

During Nix evaluation, devenv parses the Nix logs for any files and directories that are accessed.
For each accessed path, we store:
- the full path
- a hash of the file contents
- the last modification timestamp

This metadata is then saved to a SQLite database for quick retrieval.

When you run a devenv command, we:

Check the database for all previously accessed paths
Compare the current file hashes and timestamps to the stored values
If any differences are detected, we invalidate the cache and perform a full re-evaluation
If no differences are found, we use the cached results, significantly speeding up the process

This approach allows us to efficiently detect changes in your project, including:

Direct modifications to Nix files
Changes to imported files or directories
Updates to files read using Nix built-ins, like readFile or readDir

Comparison with Nix’s built-in flake evaluation cache

Nix’s built-in flake evaluation caches outputs based on the lock of the inputs, ignoring changes to Nix evaluation that often happen during development workflow.

Comparison with existing tools

Let’s take a closer look at how devenv’s new caching system compares to other popular tools in the Nix ecosystem. Running our own cache gives us more control and visibility over the caching process, and allows us to improve our integration with other tools, like direnv.

lorri

While lorri pioneered the approach of parsing Nix’s internal logs for caching, devenv builds on this concept, integrating caching as a built-in feature that works automatically without additional setup.

direnv and nix-direnv

These tools excel at caching evaluated Nix environments, but have limitations in change detection:

Manual file watching: Users often need to manually specify which files to watch for changes.
Limited scope: They typically can’t detect changes in deeply nested imports or files read by Nix built-ins.

To leverage devenv’s caching capabilities with direnv, we’ve updated the .envrc file to utilize devenv’s new caching logic.

If you currently enjoy the convenience of our direnv integration to reload your development environment, make sure to update your .envrc to:

source_url "https://raw.githubusercontent.com/cachix/devenv/82c0147677e510b247d8b9165c54f73d32dfd899/direnvrc" "sha256-7u4iDd1nZpxL4tCzmPG0dQgC5V+/44Ba+tHkPob1v2k="

use devenv

to benefit from the new caching system.

What’s next?

nix develop currently remains the last bit that’s rather slow and uncacheable, particularly on macOS. We’re working on bringing its functionality in-house to further bring down the overhead of launching a cached shell to under 100ms.

Join us on Discord if you have any questions,

Domen & Sander

devenv 1.2: Tasks for convergent configuration with Nix

Tue, 24 Sep 2024 00:00:00 GMT

For devenv, our mission is to make Nix the ultimate tool for managing developer environments. Nix excels at congruent configuration, where the system state is fully described by declarative code.

However, the real world often throws curveballs. Side-effects like database migrations, one-off tasks such as data imports, or external API calls don’t always fit neatly into this paradigm. In these cases, we often resort to convergent configuration, where we define the desired end-state and let the system figure out how to get there.

To bridge this gap and make Nix more versatile, we’re introducing tasks. These allow you to handle those pesky real-world scenarios while still leveraging Nix’s powerful ecosystem.

Usage

For example if you’d like to execute python code after virtualenv has been created:

devenv.nix

{ pkgs, lib, config, ... }: {
  languages.python.enable = true;
  languages.python.venv.enable = true;

  tasks = {
    "python:setup" = {
      exec = "python ${pkgs.writeText "setup.py" ''
          print("hello world")
      ''}";
      after = [ "devenv:python:virtualenv" ];
    };
    "devenv:enterShell".after = [ "python:setup" ];
  };
}

python:setup task executes before devenv:enterShell but after python:virtualenv task:

For all supported use cases see tasks documentation.

Task Server Protocol for SDKs

We’ve talked to many teams that dropped Nix after a while and they usually fit into two categories:

1. Maintaining Nix was too complex and the team didn’t fully onboard, creating friction inside the teams.
1. Went all-in Nix and it took a big toll on the team productivity.

While devenv already addresses (1), bridging the gap between Nix provided developer environments and existing devops tooling written in your favorite language is still an unsolved problem until now.

We’ve designed Task Server Protocol so that you can write tasks using your existing automation by providing an executable that exposes the tasks to devenv:

devenv.nix

{ pkgs, ... }:
let
  myexecutable = pkgs.rustPlatform.buildRustPackage rec {
    pname = "foo-bar";
    version = "0.1";
    cargoLock.lockFile = ./myexecutable/Cargo.lock;
    src = pkgs.lib.cleanSource ./myexecutable;
  }
in {
  task.serverProtocol = [ "${myexecutable}/bin/myexecutable" ];
}

In a few weeks we’re planning to provide Rust TSP SDK with a full test suite so you can implement your own abstraction in your language of choice.

You can now use your preferred language for automation, running tasks with a simple devenv tasks run <names> command. This flexibility allows for more intuitive and maintainable scripts, tailored to your team’s familiarity.

For devenv itself, we’ll slowly transition from bash to Rust for internal glue code, enhancing performance and reliability. This change will make devenv more robust and easier to extend, ultimately providing you with a smoother development experience.

Upgrading

If you run devenv update on your existing repository you should already be using tasks, without needing to upgrade to devenv 1.2.

Domen

devenv 1.1: Nested Nix outputs using the module system

Wed, 11 Sep 2024 00:00:00 GMT

devenv 1.1 brings support for Nix outputs, matching the last missing piece of functionality with Flakes.

It was designed to make outputs extensible, nested, and buildable as a whole by default.

This allows exposing Nix packages for installation/consumption by other tools.

Nested Nix outputs

If you have a devenv with outputs like this:

devenv.nix

{ pkgs, ... }: {
  outputs = {
    myproject.myapp = import ./myapp { inherit pkgs; };
    git = pkgs.git;
  };
}

You can build all outputs by running:

$ devenv build
/nix/store/mzq5bpi49h26cy2mfj5a2r0q69fh3a9k-git-2.44.0
/nix/store/mzq5bpi49h26cy2mfj5a2r0q71fh3a9k-myapp-1.0

Or build specific attribute(s) by listing them explicitly:

$ devenv build outputs.git
/nix/store/mzq5bpi49h26cy2mfj5a2r0q69fh3a9k-git-2.44.0

This is useful for tools that need to find and install specific outputs.

Defining outputs as module options

By default, any derivation specified in outputs nested attributes set is recognized as an output.

You can define custom options as output types in devenv. These will be automatically detected and built:

devenv.nix

{ pkgs, lib, config, ... }: {
  options = {
    myapp.package = lib.mkOption {
        type = config.lib.types.outputOf lib.types.package;
        description = "The package for myapp";
        default = import ./myapp { inherit pkgs; };
        defaultText = "myapp-1.0";
    };
  };

  config = {
    outputs.git = pkgs.git;
  }
}

Building will pick up all outputs, in this case myapp.package and outputs.git:

$ devenv build
/nix/store/mzq5bpi49h26cy2mfj5a2r0q69fh3a9k-myapp-1.0
/nix/store/mzq5bpi49h26cy2mfj5a2r0q69fh3a9k-git-2.44.0

If you don’t want to specify the output type, you can just use config.lib.types.output.

Referencing outputs from another devenv

If you import another devenv.nix file, the outputs will be merged together, allowing you to compose a developer environment and outputs in one logical unit.

You could also import outputs from other applications as inputs instead of composing them.

Leave a thumbs on the issue if you’d like to see it happen.

Documentation

See Outputs section in documentation for the latest comprehensive guide to outputs.

We’re on Discord if you need help, Domen

devenv | Blog

devenv 2.2: attach to running processes and persistent out-of-tree environments

One process manager, many terminals

Configure an environment once, use it anywhere

Shell activation gets out of the way

SecretSpec 0.17 and Cachix integration

TUI: calmer, sturdier

Evaluation cache fixes

For automation and coding agents

Smaller installs and better diagnostics

Breaking changes

Final words

Making devenv start fast, and the whole nixpkgs with it

Why Nix makes the loader work so hard

What a good fix has to preserve

Approach 1: freeze the resolution with absolute paths

Approach 2: the RUNPATH symlink farm

Approach 3: a per DSO resolution cache in an ELF note

Approach 4: a Guix style per package ld.so.cache

Approach 5: delete the loader with static linking

What about macOS?

Side by side

The final approach

devenv 2.1: Nix with zsh, fish, and nushell via libghostty

Every shell, first class

Native zsh, fish, and nushell

libghostty under the hood

Auto reload

Auto activation without direnv

For coding agents

Process management from the command line

Quiet mode by default

OpenTelemetry trace export

Tasks and processes

And more

Breaking changes

Final words

devenv 2.0: A Fresh Interface to Nix

Interactive

Terminal UI

Native shell reloading

Native process manager

Instant

Polyrepo support

Out of tree devenvs

For coding agents

Automatic port allocation

Secret isolation with SecretSpec

MCP server

And more

Breaking changes

Deprecation of devenv 0.x

Final words

SecretSpec 0.7: Declarative Secret Generation

The Problem

The Solution: type + generate

Five Generation Types

Custom Options

Shell Commands

Design Decisions

Upgrading

devenv 1.11: Module changelogs and SecretSpec 0.4.0

Module changelogs

For module authors

Profile configuration in devenv.yaml

SecretSpec 0.4.0

Multiple providers with fallback chains

Provisioning secrets as a file

Getting started

devenv 1.10: monorepo Nix support with devenv.yaml imports

Absolute / parent path imports

Git root prefixing

devenv.yaml imports

devenv.local.yaml support

Monorepo guide

devenv 1.9: Scaling Nix projects using modules and profiles

Extending devenv modules

Using Profiles

User and Hostname Profiles

Profile priorities

The Solution: `type` + `generate`