mise: Dev Tools, Environment Variables, and Tasks in One CLI

What mise Does and Who It Is For

mise (pronounced "meez") manages three concerns that typically require three separate tools. It installs and switches development tool versions (Node.js, Python, Go, Ruby, Java, and hundreds more), loads project environment variables from `mise.toml` or `.env` files, and runs project tasks with the tools and environment they need.

The README describes the core use case: declare tools, environment variables, and tasks in `mise.toml`, commit the file, and use the same setup in your shell, your editor, and CI. Every developer and every CI run works from the same configuration, without relying on global system packages or per-developer `.bashrc` customizations.

mise is written in Rust and is the successor to rtx, also by Jeff Dickey. It is MIT-licensed and maintained by the `jdx` GitHub organization. Documentation is at mise.jdx.dev.

Tool Management: Installing and Pinning Versions

mise manages tool versions through a registry of hundreds of tools. To try a tool for a single command without configuring it permanently:

mise exec node@24 -- node --version

This installs Node.js 24 if it is not already cached and runs the command. No shell activation is required for `mise exec`.

To give a project its own Node.js version, create `mise.toml` in the project directory:

[tools]
node = "24"

Run `mise install` from that directory to install the configured version. The version string `"24"` selects a release in that series; for exact pinning, a lockfile is available. Run `mise use [email protected]` to add a tool to the current project's `mise.toml` interactively. Run `mise use --global` to set personal defaults that apply outside any project directory.

The `mise ls --current` command shows which versions are active in the current directory. `mise config ls` shows which configuration files are loaded and from where.

Environment Variables and the mise.toml Format

Environment variables are declared in the `[env]` section of `mise.toml`:

[tools]
node = "24"

[env]
NODE_ENV = "development"

[tasks.hello]
description = "Print the project's Node.js version and environment"
run = '''node -e "console.log(process.version, process.env.NODE_ENV)"'''

When `mise run hello` is executed from this project, mise installs Node.js 24 if needed, sets `NODE_ENV` to `development`, and runs the task. The output shows both the Node.js version and `development`.

mise also loads `.env` files from the project directory. The `[env]` section in `mise.toml` is for values committed to the repository; `.env` is for secrets that stay untracked. Configuration files cascade: `mise.toml` in a parent directory applies to all its subdirectories unless overridden. The `conf.d/` folder (as of v2026.9.14) accepts fragment files for splitting large configurations.

Task Runner: Running Commands with Managed Tools

mise tasks are defined in the `[tasks.*]` sections of `mise.toml`. Each task has a `description` and a `run` script. Run `mise tasks ls` to discover a project's tasks:

mise run hello

Tasks run with the project's configured tools on the PATH. If Node.js 24 is in `[tools]` and the task runs `node`, it gets exactly that version. Tasks can call other tasks, accept arguments, and set per-task environment variables.

The README's table of common actions points to `mise.jdx.dev/tasks/` for the task runner documentation. Tasks replace Make targets and shell scripts while guaranteeing that the right tool version is active. The `mise config ls` and `mise ls --current` commands confirm which version is in use before running a task.

For CI pipelines, the `jdx/mise-action` GitHub Action installs mise and runs `mise install` from the project directory. The action is referenced in RELATED SEARCHES as `jdx mise action`, and versions v2, v3, and v4 are in the search data.

Shell Activation and the mise doctor Diagnostic

Shell activation makes mise-managed tools available directly in the shell's PATH when you enter a project directory, without prefixing commands with `mise exec`. For a curl-installed mise on macOS or Linux, add one line to the shell config:

eval "$(~/.local/bin/mise activate bash)"

For zsh, replace `bash` with `zsh`:

eval "$(~/.local/bin/mise activate zsh)"

For fish:

~/.local/bin/mise activate fish | source

After restarting the shell and entering a project directory, running `node --version` (without `mise exec`) should return the project's pinned version. If it does not, run `mise doctor` for a diagnostic report that identifies activation problems, missing configuration, or PATH issues.

Activation is optional. `mise exec` works without it and is the appropriate approach in CI, where activation adds no value over running all commands through `mise exec`.

Installing mise and Supported Platforms

On macOS or Linux, install with:

curl https://mise.run | sh
~/.local/bin/mise --version

The first line downloads and runs the install script. The second line confirms the installation. On Windows, use `winget install jdx.mise`. Package managers are also available: Homebrew, Cargo, and others. The Dockerfile in the repository builds a Docker image with mise pre-installed and configured.

The repository's `Cargo.toml` shows the current version as `2026.9.16` and requires Rust 1.95. The workspace includes several crates: `mise-cache-core`, `mise-shim`, `mise-settings`, `mise-sigstore`, and others that make up the CLI and its supporting infrastructure.

The `completions/` directory holds shell completion scripts for bash, zsh, fish, PowerShell, and other shells. These are generated by the CLI itself and are included in the repository for distribution.

mise Limitations and Comparison to asdf

mise requires installation before it can bootstrap a project's tools. There is no single-file self-installing approach. In CI environments, this means the pipeline must install mise as a first step, either through the GitHub Action or manually.

The Cargo.toml requires Rust 1.95. If mise is being built from source (unusual: most users install the binary), the local Rust toolchain must meet that minimum.

mise has a compatibility layer for asdf plugin format: the README documentation describes loading tools from asdf plugins. asdf is the older, more established tool version manager that mise was designed to replace. The main practical difference is that mise is Rust-based and faster, uses `mise.toml` rather than `.tool-versions`, and includes environment variable management and task running as first-class features that asdf does not have. Teams migrating from asdf can continue using their existing asdf plugins in mise while transitioning.

The `mise-lock.yaml` file (the lockfile format) pins tool versions to exact resolved versions. Without the lockfile, a version request like `"24"` selects the latest 24.x release, which can change between runs.

Editorial conclusion

mise is the right tool for teams that want to replace three separate tools (a version manager like nvm or pyenv, a dotenv loader, and a task runner like Make or just) with one configuration file that CI and every developer's machine reads identically. The `mise.toml` file commits to the repository, so there is no manual setup step when a new team member clones the project. The trade-off is that mise must be installed first (it does not bootstrap itself), and shell activation is required to make project tools available in the shell's PATH without the `mise exec` prefix. Run `mise doctor` to diagnose activation problems. mise v2026.9.16 is the current release as of 2026-09-28.

Frequently asked questions

Official sources

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