Blog

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

Jul 3, 2025

Domen Kožar

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

Apr 25, 2025

Domen Kožar

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

Apr 13, 2025

Domen Kožar

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

Feb 13, 2025

Domen Kožar

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

Oct 22, 2024

Domen Kožar

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

Newer posts

Older posts