Every project pulls a different stack these days, and the classic answer is a drawer full of version managers: nvm for Node, pyenv for Python, rbenv for Ruby, golang for Go, plus direnv for per-project environment variables and make for tasks. That's a lot of tools, each with its own config syntax and its own sharp edges.
mise started as an attempt to slim that drawer down to one. Written in Rust by Jeff Dickey (the maintainer you know as jdx), it began life in late 2022 under the name rtx as a re-implementation of asdf, the polyglot version manager. In January 2024 it was renamed to mise — after the French culinary term mise en place, "put in place," the chef's habit of arranging every ingredient before the stove is lit.
Since then it has grown well past version management. The project now describes itself as "dev tools, env vars, and tasks" in one CLI — a single declarative file that replaces version managers, direnv, and a Makefile in one go.
A drop-in replacement for asdf
The first thing that makes mise painless to adopt is that it reads your existing asdf setup. If a project ships a .tool-versions file — asdf's standard, still the most common format in the wild — mise will pick it up with no migration. It's also compatible with the asdf plugin ecosystem, and it re-implements most tools in Rust rather than shelling out, which is one reason it feels snappier than the tools it replaces.
You can manage versions per directory with mise use:
mise use node@22
That pins Node 22 in a mise.toml file for the current directory, installs it if needed, and puts the right binary on your PATH — no nvm install, no export PATH=..., no re-loading your shell. One nice touch inherited from the community: fuzzy versions. Write node = "20" and mise resolves the latest 20.x, instead of you tracking patch releases by hand.
The bigger bet: your whole environment in one file
Where mise gets genuinely interesting is that version management is only one third of it. Beyond dev tools, your .toml can declare per-project environment variables:
[env]
DATABASE_URL = "postgres://localhost/app_dev"
PORT = "8080"
Those are applied automatically when you enter the directory, so the awkward "direnv allow and pray" dance goes away. And the same file can define tasks in the [tasks] section — mise run build, mise run test — replacing at least the simplest Makefiles project setup tends to accumulate.
You end up with one file that says what a project needs, what environment it expects, and how to run it. Read a repo's mise.toml and you understand the whole setup in under a minute, which is a genuinely nice experience for jumping between codebases.
Worth it?
There are honest trade-offs. mise is a young project holding a lot of responsibility in one binary, and consolidating five tools into one means you're betting on it sticking around. If a project needs truly gnarly per-language tooling, the specialized tool might still fit better. But for the common case — a few languages, some env vars, a couple of repeatable commands — it's one Rust binary, one TOML file, and a real reduction in the mental load of switching context.