Install & Activate

Getting mise on your machine is a one-liner. Understanding the two ways it puts tools on your PATH — and where it reads config from — is what separates “it works on my laptop” from “it works everywhere.” This page covers both.

Install

curl

curl https://mise.run | sh        # → ~/.local/bin/mise

The simplest path. Pin a version or relocate the binary with env vars:

MISE_VERSION=v2026.6.4 MISE_INSTALL_PATH=/usr/local/bin/mise \
  curl https://mise.run | sh

Homebrew

brew install mise

Complementary, not redundant — keep brew for system libs and casks; let mise pin your project toolchains.

Package managers

pacman -S mise          # Arch
apk add mise            # Alpine
dnf install mise        # Fedora (via the mise.en.dev RPM repo)
scoop install mise      # Windows
winget install jdx.mise # Windows
snap install mise       # any snapd distro

GPG-verified

For locked-down environments, install from the official mise.en.dev host, which ships GPG-signed releases and RPM repositories. Import the signing key and verify the download before running it — the supply-chain-conscious option for servers and base images.

It used to be called rtx

If a blog post tells you to install rtx, it’s stale. mise was renamed years ago; the binary, the data dir (~/.local/share/mise), and the config are all mise now.

The installer drops a static binary and does nothing to your shell. That’s the next, crucial step.

Activate your shell

Activation is what makes cd-ing into a project swap your tools automatically. Add the right line to your interactive rc file:

Bash

~/.bashrc

eval "$(mise activate bash)"

Zsh

~/.zshrc

eval "$(mise activate zsh)"

Fish

~/.config/fish/config.fish

mise activate fish | source

PowerShell

$PROFILE

(&mise activate pwsh) | Out-String | Invoke-Expression

.bashrc, not .bash_profile

Put activation in the file that runs for interactive shells (.bashrc / .zshrc), not .bash_profile or .zshenv. Activation installs a prompt hook, and those non-interactive files run too early or in the wrong context. (For non-interactive environments — IDEs, CI, cron — you want shims instead. See below.)

Reload (exec $SHELL) and you’re live. The https://mise.run/bash (or /zsh, /fish) endpoint even appends the activation line for you during install.

The one concept: PATH activation vs shims

mise can expose your tools two different ways, and almost every “why isn’t my tool found?” question comes down to which one you’re using.

PATH activation hooks your shell prompt. Before each prompt — and on every cd — mise runs hook-env, which rewrites PATH (and [env] vars) to match the directory you’re standing in.

hook-env: PATH rewrite on cd / prompt (PATH-activation mode)

Rendering diagram…

Shims are static wrapper scripts in ~/.local/share/mise/shims. You put that one directory on PATH and forget it. Calling node runs the node shim, which asks mise (at exec time) which version this directory wants, then execs it. No prompt hook, no shell integration — which is exactly why they work where there is no shell.

eval "$(mise activate bash --shims)"   # or just add the shims dir to PATH
export PATH="$HOME/.local/share/mise/shims:$PATH"

	PATH activation	Shims
How	prompt hook rewrites PATH per directory	static wrapper scripts on PATH
Sets [env] vars	yes	no (env vars only via activation)
Needs an interactive shell	yes	no
Speed	fast; resolves once per prompt	tiny per-call exec overhead
New binary appears	picked up automatically	run mise reshim
Best for	your daily terminal	IDEs, CI, cron, Dockerfile, scripts

Use both — for different jobs

PATH activation in your terminal, shims everywhere a shell doesn’t run. They coexist happily. We lean on shims again for editors and CI.

A common gotcha: under PATH activation, which node reports the shim or installed path your shell sees. To find the real resolved binary, use mise’s own resolver:

mise which node     # → ~/.local/share/mise/installs/node/22.14.0/bin/node
mise where node     # → the install dir
mise reshim         # regenerate shims after a tool adds a new binary

Run a tool without activating: mise exec

Need a tool right now without touching config or your shell? mise exec (alias mise x) resolves, installs if missing, and runs — in a one-off subshell.

mise exec node@22 -- node --version    # ad-hoc, nothing written to config
mise x python@3.13 -- python script.py
mise x -- npm test                     # use the versions this dir already pins

This is the right tool inside scripts, cron, systemd units, and CI steps where you don’t want to depend on shell activation. (Pinning tools into a project with mise use is page 2.)

Where mise reads config

mise walks up from your current directory to the filesystem root, then layers in your user and system config. Nearer files win, merged key by key — so a project mise.toml overrides your global Node version without throwing away your global env.

Config resolution: walk up from cwd, merge (nearer overrides)

Rendering diagram…

Within a single directory, the precedence is (highest first):

Order	File	Commit it?
1	mise.local.toml	no — gitignore
2	mise.<env>.local.toml	no — gitignore
3	mise.toml	yes
4	mise.<env>.toml	yes
5	mise/config.toml, .mise/config.toml	yes
6	.mise.toml (legacy dotted form)	yes
—	then user ~/.config/mise/config.toml, then system /etc/mise/	—

Prefer the visible mise.toml

Use plain mise.toml (and mise.local.toml for your personal, untracked overrides). The dotted .mise.toml works but is legacy. Per-environment files like mise.production.toml and how they’re selected belong to Environments & Secrets.

There’s also .miserc.toml — a new-in-2026 early-init settings file read before the rest, for things like selecting the active environment.

.tool-versions vs mise.toml — pick mise.toml

mise still reads asdf’s .tool-versions (lowest precedence) for backwards compat:

.tool-versions

node 22.14.0
python 3.13.2

But it only carries tool versions — no [env], no [tasks], no [settings]. The equivalent mise.toml does all three, in one committed file:

mise.toml

[tools]
node = "22"          # fuzzy → latest 22.x
python = "3.13"

[env]
DATABASE_URL = "postgres://localhost/dev"

[tasks.test]
run = "npm test"

New projects: always mise.toml

Keep .tool-versions only while migrating off asdf. Going forward, mise.toml is the single file that pins your tools, env, and tasks — the foundation for the workflow you’ll design later.

---

You can now install mise, activate it (or drop in shims), run anything ad-hoc with mise exec, and you know exactly which config file wins. Next: actually pinning tools — versions, backends, and the lockfile — in Tools & Backends.