devenv provides community-driven abstractions for developer environments—much like NixOS does for system configuration, and home-manager does for user configuration of the home directory.

You could just take a Nix shell, and define your PostgreSQL configuration with various ENV vars (PGDATA, …) to make a PostgreSQL installation “local”, but with devenv as a minimum you just need to declare:

  services.postgres = {
    enable = true;
  }

In addition to the above, devenv also provides abstractions for:

• background process management
• composable tasks (kind of make replacement)
• building OCI containers
• … and more

In my company we have been using devenv for developer environments for around 2 years now. We have employees on Linux, Windows WSL and MacOS. Each time a new OS came up, there were some env specifics that had to be resolved / improved, but the problems were not devenv related per se. Overall the experience has been overwhelmingly positive, with new employees being able to go from 0 to running a monolith with a large number of binary dependencies and source modified PostgreSQL plugins in minutes.

This is how the setup instructions roughly look like for a new MacOS user with a brand-new laptop:

• Install direnv and setup shell hooks
• Clone repo
• Run a few first time setup scripts to get Nix installed and setup
• direnv allow to allow automatic env var loading / unloading in the directory of the repo
• devenv up to start background processes
• make ci to confirm the application passes various static analyses and tests
• Install Zed (as Zed requires no plugin setup - Zed supports elixir-ls and direnv out of the box. We install elixir-ls via devenv so that all devs have identical version of the language server)
• Write prod code

It might feel like a lot of work, but in general, the amount of time spent is dependent on:

• prior knowledge.
• environment complexity. For a greenfield project, it could be 2 mins of LLM generated devenv config.

Purely on devenv configuration itself, I’ve spent at most a few full-time work days in the last two years, as lot of the time gets spent on things you’d have to do anyway, regardless of devenv:

• PostgreSQL config shows up in devenv, and it’s a big chunk by size, but you’d need that setup no matter how you manage your dev environments.
• If I spend time packaging something with nix, that time would still have to be spent even if there was no nix - trying to get everyone on the same package.
• …

Nix is one of those technologies that have a large learning curve. But that’s the same with many other technologies that are worth learning - you are not going to become proficient in Haskell, Clojure, Prolog, … in a weekend. What I can say, having learned a bunch of Nix/NixOS before the advent of LLMs, is that LLMs make it way faster to develop the fundamental understanding of the Nix ecosystem. But one has to be careful with prompting as the purpose of prompting should be building understanding as opposed to hoping that LLMs can generate some black-box that works.

Super cool! I will try it out later.

One question, did you also setup the variable envs so all created files are encapsuled inside the project directory? For example, in my devenv config, I setup it so all postgres data will live inside the project directory (I think inside .env/.devenv/state/postgres), I also made that all elixir config files like hex, mix, erlang-history, etc are all inside the .env/.devenv/state too.

In other words, running elixir, postgres, erlang, etc never leaks anything outside the scope of the project.

Thank you for the inspiration! I was considering isolating Hex archives, actually.

This is pretty neat! I’ve been planning on getting into nix & devenv at some point, especially considering how important it is getting to be able to run containerized local development. Its on my short list to checkout