Skip to content

2025

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

devenv 1.7 brings several practical improvements:

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

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

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

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