mise vs asdf
mise and asdf compared as polyglot version managers: .tool-versions compatibility, plugins vs backends, environment variables, tasks, lockfiles, Windows support, security and migration as of October 2026.
Quick Answer
asdf is the original one-file, plugin-based version manager: a Go binary (since 0.16) that reads .tool-versions and resolves every tool through shims, with roughly 845 community plugins in its short-name index. mise is a Rust CLI that reads the same .tool-versions files but installs most tools through built-in backends (aqua, GitHub releases, npm, pypi, cargo and more, 1,000+ registry tools), and adds per-project environment variables, a task runner, a lockfile and native Windows support. Both are MIT-licensed and free. Pick asdf if you want a small, stable tool that only manages versions; pick mise if you want versions, env vars and tasks in one mise.toml, or you need Windows.
Last updated October 31, 2026. Covers mise v2026.10.24 (30 Oct 2026) and asdf v0.20.2 (22 Sep 2026), with mise's backends, env, tasks, lockfile and asdf migration docs, and asdf's 0.16 Go rewrite and plugin security notes, as of 31 Oct 2026.
| Feature | mise | asdf |
|---|---|---|
| Licence | MIT | MIT |
| Written In | Rust | Go (Bash up to 0.15) |
| Config File | mise.toml (plus mise.local.toml, per-environment files like mise.production.toml, ~/.config/mise/config.toml) | .tool-versions (plus ~/.asdfrc for machine settings) |
| Reads .tool-versions | Yes, as is; .nvmrc and .python-version once enabled | Yes (native format); legacy files like .ruby-version via legacy_version_file = yes where plugins support it |
| How Tools Are Installed | Built-in backends: core, packslip, aqua, github/gitlab/forgejo, http/s3, cargo, go, npm, pypi, gem, dotnet, spm, conda, vfox; legacy asdf plugins on Unix | Shell-script plugins added by short name or Git URL |
| Tool / Plugin Index | 1,000+ tools in the registry; any backend identifier works without a registry entry | About 845 plugins in the asdf-plugins short-name index (Oct 2026) |
| How Versions Are Activated | Shell activation updates PATH at each prompt/cd; optional shims; mise exec and mise run for scripts and CI | Shims for every installed executable resolve the version on each call |
| Per-Project Environment Variables | Yes: [env], .env files, defaults, required variables, secrets | No (asdf-direnv plugin suggested) |
| Built-in Task Runner | Yes: mise run with dependencies, parallelism, arguments, caching | No |
| Lockfile with Checksums | Yes: mise.lock with versions, URLs and checksums where the backend provides them | No (exact versions in .tool-versions only) |
| Native Windows | Yes, for tools and backends that publish Windows builds (asdf plugins excluded) | No: binaries for macOS and Linux (amd64, arm64; Linux 386) |
| Self-Update | Yes: mise self-update for official release binaries | No: asdf update was removed in 0.16; use a package manager or download |
| Latest Release (Oct 2026) | v2026.10.24 (30 Oct 2026) | v0.20.2 (22 Sep 2026); v0.20.0 on 7 Jul 2026 |
mise
MIT-licensed Rust CLI (pronounced 'meez') that installs a project's dev tools, sets its environment variables and runs its tasks from one mise.toml, while still reading asdf's .tool-versions files.
Pros
- Reads existing .tool-versions files as they are, so a team can switch one developer or one project at a time while others stay on asdf
- Most registry tools install through built-in backends (aqua, GitHub/GitLab/Forgejo releases, npm, pypi, cargo, go, gem and more) with no plugin script to trust
- Per-project [env] variables, .env file loading, required/default values and secrets support replace a separate direnv setup
- Built-in task runner with TOML or file tasks, parallel dependencies, caching and monorepo support
- mise.lock records exact versions plus download URLs and checksums where the backend provides them; mise install --locked reproduces them in CI
- Runs natively on Windows (winget, Scoop, Chocolatey) for tools that publish Windows builds
Cons
- Much larger surface area (tools, env, tasks, bootstrap, daemons) means more to learn and more configuration that can run code, hence its trust prompts
- Releases several times a week; pin MISE_VERSION or a package version if you need a fixed CLI across a team
- Not a full asdf emulator: scripts should use mise syntax, and mise-only entries must be kept out of a .tool-versions file asdf users still read
- Tools listed only in .tool-versions are not written to mise.lock, so locking requires moving them to mise.toml
Best For
Developers and teams who want tool versions, environment variables and project commands defined in one committed file, reproducible in CI, including on Windows.
asdf
MIT-licensed tool version manager that keeps every tool version in one .tool-versions file and extends to any runtime through shell-script plugins; rewritten from Bash to a Go binary in version 0.16.
Pros
- Does one job: a single .tool-versions file pins every runtime and CLI for the team, with very little else to configure
- Huge plugin ecosystem built over many years; the asdf-plugins short-name index lists about 845 plugins, and any Git URL works too
- Version formats cover real-world cases: exact versions, ref: to build from a tag or commit, path: for a local build, system passthrough and ordered fallbacks
- Since 0.16 it is a single Go binary: install via Homebrew, Zypper, AUR, a release archive or go install, then add the shims directory to PATH
- Slow, predictable release cadence (0.19 in April, 0.20 in July, 0.20.2 in September 2026) suits teams that rarely want to touch their tooling
Cons
- Every plugin is a shell script that runs on install; plugins are outside asdf's own security policy, so you review and trust each maintainer
- No environment-variable management (the docs point to the asdf-direnv plugin) and no task runner
- No native Windows support: release binaries are macOS and Linux only, and plugins need Bash and Unix tools
- No lockfile with checksums and no self-update; upgrades go through your OS package manager or a manual binary download
Best For
Teams on macOS and Linux that already standardise on .tool-versions and want a small, stable version manager with no extra features to govern.
Same file, different engines: how each one finds the right version
Both tools start from the same idea: a file in the repository names the tool versions, and entering the directory gives you those versions. asdf does this entirely with shims. When a plugin installs a tool, asdf creates a shim for every executable; each time you run node or terraform, the shim asks asdf which version the nearest .tool-versions selects and executes that one. It is simple, works in any program that reads PATH, and costs a resolution step on every call. mise reads .tool-versions as it is, but its default mode is shell activation. A hook runs at each prompt and directory change and rewrites PATH and environment variables for the current directory, so later commands run the real executables directly. mise also keeps shims for editors and GUI apps that never read your shell startup file; those resolve on each call, as asdf's do. For scripts and CI neither activation nor shims are needed: mise exec -- <command> and mise run <task> load the project config for one command. One practical difference: mise's own config is mise.toml, which can hold tools, env vars and tasks, and a mise.toml in the same directory takes precedence over .tool-versions for the tools it declares. Keep that in mind if both files live side by side during a migration.
Plugins vs backends: where your binaries come from and whom you trust
This is the most important difference for security reviews. An asdf plugin is a shell script that runs on your machine whenever you install a tool, so you trust the plugin's maintainer as well as the tool's publisher. asdf's own documentation is direct about it: plugins are the responsibility of their creators, are not covered by the core security policy, and you should read each plugin's code before use. The asdf-plugins repository maps about 845 short names to Git URLs, and the core team recommends the long form with an explicit URL. mise installs most registry tools through built-in backends instead. The aqua backend installs publisher release assets described by the aqua registry and applies the checksum, cosign, SLSA or attestation checks that registry declares; packslip verifies a signed release manifest and every artifact digest; github:, gitlab: and forgejo: download release assets directly; npm:, pypi:, cargo:, go: and gem: install CLIs from language package registries into their own directories. Legacy asdf plugins still work through the asdf: backend, but not on Windows. Verification depends on what each publisher provides, so check mise tool <name> before you rely on it. The upshot: with mise, most of your tool supply chain stops depending on per-tool shell scripts.
Beyond versions: environment variables, tasks and lockfiles
asdf's introduction states plainly that it does not manage environment variables and is not a package manager; for env vars it points to the asdf-direnv plugin. There is no task runner and no lockfile beyond the exact versions you write in .tool-versions. mise bundles three things many teams previously wired together by hand. The [env] section sets variables for mise exec, tasks, shims and activated shells, can load .env files, mark variables as required with help text, set defaults that respect existing values, and keep secrets out of plaintext config; mise.production.toml-style files switch whole environments. The task runner defines build, test and lint commands next to the tools they need, either as TOML or as executable scripts in mise-tasks/, with parallel dependencies, arguments, caching and monorepo support; mise run installs missing tools first. Finally, mise.lock records the exact version each request resolved to, plus download URLs and checksums where the backend provides them, and mise install --locked reproduces that on every machine. Because a mise.toml can run code and change your environment, mise only loads one once it is trusted; review configs from other people's repositories before running mise install, mise run or mise trust there.
Windows, installation and keeping the tool itself up to date
asdf 0.16 replaced the Bash scripts with a Go binary, which made installation simpler: get the binary from Homebrew, Zypper, the AUR, a release archive or go install, add ${ASDF_DATA_DIR:-$HOME/.asdf}/shims to the front of PATH, and optionally set up completions. The 0.20.2 release ships archives for macOS (amd64, arm64) and Linux (386, amd64, arm64) only, and plugins need git and bash, so Windows users are limited to WSL or similar. There is no self-update: asdf update was removed in 0.16, so you upgrade through your package manager or by replacing the binary. mise's recommended install is curl -fsSL https://mise.run | sh on macOS and Linux and winget install jdx.mise on Windows, with Homebrew, apt, dnf, pacman, Scoop, Chocolatey, Docker images and a GitHub Action as alternatives. The install script verifies checksums from GitHub Releases and, by default, picks the newest stable release that is at least 24 hours old; set MISE_VERSION for a reproducible install. Official binaries can update themselves with mise self-update. mise runs natively on Windows for tools and backends that publish Windows builds, which is often the deciding factor for mixed-OS teams.
Migrating from asdf to mise without breaking teammates
mise's documentation describes an incremental path. Install mise, then in one project run mise config ls and mise ls --current to see how it reads the existing .tool-versions. Run mise install and check a command with mise exec -- <tool> --version. mise installs its own copies of each tool and does not reuse asdf's install directories, so expect a one-time download per tool. Once the project works, remove asdf's shim directory and activation from your shell startup file, activate mise and check mise doctor. Commands map closely: asdf install nodejs 24.0.0 becomes mise install [email protected], asdf set (the 0.16 replacement for asdf local) becomes mise use, asdf set --home becomes mise use -g, and asdf current becomes mise ls --current. Note that mise set is unrelated; it sets environment variables. While some teammates stay on asdf, keep a shared .tool-versions with concrete versions (mise use --path .tool-versions --pin node@24) and keep mise-only syntax such as aqua: identifiers out of it. Personal defaults move from ~/.tool-versions to ~/.config/mise/config.toml. When everyone has switched, preview mise generate config --tool-versions .tool-versions --dry-run, write mise.toml, add mise lock, and uninstall asdf.
Verdict
Choose mise for most new setups in 2026. It reads the .tool-versions files you already have, installs most tools without running a plugin script, and adds what asdf deliberately leaves out: per-project environment variables, a task runner, a checksum lockfile for CI and native Windows support, all from one mise.toml. Teams that juggle Node, Python, Terraform and a dozen CLIs get the most from it, because one file now covers versions, env and commands. Choose asdf if you only want version pinning on macOS or Linux and value a small, slow-moving tool: it is MIT-licensed, now a single Go binary, and its plugin ecosystem covers almost anything. It is also the safer pick when your organisation does not want a tool that can set environment variables or run tasks from a repository file. If a team is split, keep .tool-versions as the shared file with concrete versions, let mise users and asdf users read it, and move to mise.toml only once everyone has switched.