But Our Devenv Is In Another Repo

June 10, 2026 Evan Travers

For the past year of software consulting I've been using nix to define the development environments. I had been using flakes, but recently I've been using devenv.sh. Devenv is a system on top of nix that makes creating common dev environment recipes a lot easier. Setting up a language, some dependencies, services… even setting up postgres and ensuring some databases are created is a breeze.

There are several other similar nix-based dev-ex systems, but (so far that I can see) devenv is the only one that insists on using nix to configure it. So many others try to give you nix without making you write nix… which is a nice idea but in my limited experience is a handicap.

When you just devenv init and check in the resulting files, devenv works great. What I've been working through is "what if you don't want to impose devenv on your whole team?" As a contractor I don't really want to foist my development preferences on everyone else.

I can .git/info/exclude the devenv files. However last few projects I've been working are complex. Four or more repositories, env variables shared between two or three but not all, separate languages, constant motion… not tracking the dev environment in git loses a large part of why to use a tool like devenv in the first place.

Here's what I'm currently doing: I'm working a contract with a team that isn't using nix or devenv. Because I want to track the configuration in git and not just .git/info/exclude the important devenv files, I've been:

1. Make a git repo to store the configurations in a sibling folder. I'll call this the Configuration Repo.

2. devenv init in a sibling folder and tracking with git.

3. Defining all the repos/projects for my contract as profiles…

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

  packages = [
    pkgs.acli
  ];

  env = {
    CLAUDE_CONFIG_DIR = "../.claude";
    AWS_CONFIG_FILE = "../.aws/config";
    AWS_SHARED_CREDENTIALS_FILE = "../.aws/credentials";
    ENABLE_LSP_TOOL = 1;
  };

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

      hosts = {
        "local.fake-company-name.com" = "127.0.0.1";
      };
    };

    backend.module = {
      languages = {
        javascript = {
          enable = true;
          package = pkgs.nodejs_24;
          npm.enable = true;
          lsp.enable = true;
        };
      };

      packages = [
        pkgs.vscode-js-debug
      ];

      certificates = [ "local.fake-company-name.com" ];

      aws-vault = {
        enable = true;
        profile = "fake-company-name";
      };
    };
}

1. In the "real" Project Repo folder:

2. devenv init and git excluding all files.

3. Deleting everything out of devenv.nix so that it's a "bare" file.

4. Then I setup the inputs and imports in devenv.yaml:

# yaml-language-server: $schema=https://devenv.sh/devenv.schema.json
inputs:
  nixpkgs:
    url: github:cachix/devenv-nixpkgs/rolling
  fake-company-name:
    url: path:../fake-company-name-devenv/
    flake: false
profile: frontend
allowUnfree: true
imports:
  - fake-company-name

I used to trigger this using direnv with an .envrc, I'm currently playing with using devenv's shell hook and devenv allow. This makes it clearer where the ENV variables should live… now they all are forced into a devenv.nix. If they need to be secret I can still use my .envrc or I can use devenv's new secrets system.

This works… but I've noticed a couple problems: I think that devenv treats the .devenv cache in the Project Repo as a source of truth, so when I update the Configuration Repo I often don't see changes until I rm -rf .devenv in the Configuration Repo.

I'm currently chatting in the discord to see if there's a better way to achieve what I want. So far… it's the best way… but it leaves something to be desired. While it stands up reliably and just works, it's resistant to change because of that local Project Repo cache. If I find something better I'll post it.

---

🔖

Changelog

• 2026-06-10 10:02:11 -0500

• post devenv