CLI tool
jdx/mise avatar
jdx/mise

mise: One Rust CLI to Replace Your Version Manager, Env Loader, and Task Runner

dev tools, env vars, task runner. mise prepares your development environment before each command runs.

33,916 stars1,431 forksRustMIT

At a glance

What is it?
mise is a single Rust binary that installs dev tools, loads per-project environment variables, and runs tasks from one mise.toml file. It targets developers who want a unified, shim-free workflow, but its breadth comes with a learning curve.
Who is it for?
Adopt mise if you manage multiple projects with differing tool versions and env vars, and you want a single config file that CI and local shells both read. Skip it if you already have a stable combination of asdf, direnv, and Make and don't want to migrate.
Can I use it commercially?
Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
Is it still maintained?
Yes. The repository last received commits 1 day ago.
What is it written in?
Mainly Rust, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on September 14, 2026, and from our analysis. They are not legal advice.

DEEP OPEN-SOURCE ANALYSIS

The problem mise solves: three tools, one config file

Most developers juggle a version manager like nvm or asdf, a directory-based env loader like direnv, and a task runner like Make or npm scripts. Each has its own config format, its own shell hook, and its own quirks. mise collapses all three into a single mise.toml file. The README states that it "prepares your development environment before each command runs," which means every new shell, fresh checkout, or CI job starts from the same setup. The target user is someone who is tired of synchronizing three separate configs and wants a single source of truth. The project is written in Rust, which suggests a focus on speed and a single static binary, though the README does not provide benchmark numbers.

How mise works: real paths, not shims

The core mechanism is the shell hook. You add a line to your shell config, like eval "$(~/.local/bin/mise activate bash)", and mise modifies your PATH and environment before each command runs. The demo shows that calling which node gives a real path to node, not a shim. This is a key difference from tools like nvm that use shell functions or asdf that uses shims. When you run mise exec node@26 -- node -v, mise installs the specified version if needed, then executes the command with that version's bin directory prepended to PATH. The mise.toml file defines tools, env vars, and tasks. For tools, mise installs them on demand; for env, it sets variables in the current shell; for tasks, it runs shell commands with the configured environment. The data flow is straightforward: read mise.toml, resolve tool versions, adjust PATH, set env vars, then execute the task or command.

Getting started: install, hook, and configure

The quickstart is simple. Install with curl https://mise.run | sh, which puts the binary at ~/.local/bin/mise. Then add a shell hook. The README gives exact lines for bash, zsh, fish, and pwsh. For bash it is eval "$(~/.local/bin/mise activate bash)" appended to ~/.bashrc. After that, you can install tools globally with mise use --global node@26 go@1. To set env vars, create a mise.toml with an [env] section and use mise set SOME_VAR=bar to change it. Tasks go in the same file under [tasks.build] with a run key. The example project combines tools, env, and tasks for a Terraform workflow. You run mise install to install all tools listed in mise.toml, then mise run deploy to execute a task that depends on validate and plan. This is a real workflow that replaces separate Makefile and .env files.

The trade-off: one config means one way to do things

mise's strength is also its limitation. By merging tools, env, and tasks into one file, it forces a specific structure. If you have complex shell logic in your Makefile or you rely on direnv's ability to run arbitrary shell commands, mise's [env] section may not cover all cases. The README mentions loading .env files, but it does not give details on how to handle dynamic env values or conditional logic. Another limitation is that mise is a single project with a single maintainer (jdx). The README notes that GitHub Issues became unsustainable, so bug reports go to GitHub Discussions. That is a sign of high volume, but it also means you need to search discussions for known issues. The release notes mention "cleaner temp/prune handling" and "task exclusions," which suggest the tool is still evolving. If you need a stable, long-term tool, this rapid pace might be a concern.

Alternatives: asdf, direnv, and Make, separately

The most direct alternative is to use asdf for tool versions, direnv for environment variables, and Make or a script runner for tasks. asdf uses shims, which mise explicitly avoids. direnv can run arbitrary shell code on directory change, which is more flexible than mise's declarative env section. Make is a battle-tested task runner with pattern rules and parallel execution, while mise tasks are simple run commands. The difference is that with asdf+direnv+Make, you have three configs (.tool-versions, .envrc, Makefile) and three tools to learn, but each is mature and has a large community. mise offers a single binary and a single config, but you trade that for a younger project. If you already use asdf, you can even use asdf as a plugin backend for mise, but the README does not detail that. The choice is between integration and maturity.

Maintenance and licensing: MIT with a fast release cadence

mise is licensed under MIT, which is permissive and allows commercial use without restriction. The repository shows recent releases every few days, like v2026.8.14 on 2026-08-26, with fixes for npm/aube install and temp/prune handling. That is a rapid cadence, which means you get fixes quickly but also need to track updates. The project uses GitHub Discussions for support, not issues, so the maintenance model is community-driven. There is no mention of a long-term support policy. For an engineer adopting mise, the cost is learning the config format and staying current with releases. The Rust implementation means a single binary, but you still need to update it. The README does not mention upgrade procedures, so you likely re-run the install script or use a package manager.

Editorial conclusion

Adopt mise if you manage multiple projects with differing tool versions and env vars, and you want a single config file that CI and local shells both read. Skip it if you already have a stable combination of asdf, direnv, and Make and don't want to migrate. Before adopting, verify that the tools you need exist in the mise registry, check how your shell hook behaves with your existing prompt, and test the task dependency behavior on your CI runner. The project's shift to GitHub Discussions for bug reports means you should search there before filing issues. If you need a mature, battle-tested ecosystem, asdf remains a safer bet; if you want a modern, integrated approach, mise is worth a trial on a non-critical project.

Official sources

  1. Official documentation
  2. Official README
  3. Project repository
  4. Release notes
Community notes

Community notes