Top 10 Features in Mise You're Not Using

1. Task `sources` and `outputs` #

Any task can declare input/output globs. If all outputs are newer than all sources, the task is skipped entirely:

[tasks.build]
run = "cargo build"
sources = ["Cargo.toml", "src/**/*.rs"]
outputs = ["target/debug/myapp"]

Don’t want to enumerate outputs? Set outputs = { auto = true } (which is actually the default when sources is defined) — mise tracks a hash internally and skips the task if sources haven’t changed.

2. The `github`, `http`, and `s3` backends #

The github backend installs tools directly from GitHub releases. It infers the right asset for your platform automatically — just point it at a repo and it usually works:

[tools]
"github:BurntSushi/ripgrep" = "latest"

For more complex setups (non-standard naming, multiple binaries, etc.), the aqua registry is a better choice for open-source tools — it has hand-written manifests for hundreds of tools with full platform mapping. The github backend is best for quick one-offs and private/internal tools.

The http backend goes further — install any binary from any URL with templated platform variables:

[tools."http:my-internal-tool"]
version = "2.1.0"
url = 'https://artifacts.internal.co/tool-v{{version}}-{{os(macos="darwin")}}-{{arch(x64="amd64")}}.tar.gz'

The s3 backend [experimental] does the same for S3 or S3-compatible storage (MinIO, etc.):

[tools."s3:my-tool"]
version = "1.0.0"
url = "s3://my-bucket/tools/my-tool-v{{ version }}.tar.gz"
endpoint = "http://minio.internal:9000"

Great for internal artifact servers, private buckets, or anything with a download link.

3. Tool stubs #

Inspired by Meta’s dotslash, tool stubs are self-contained scripts that auto-download and execute tools on first run. Check them into your repo and anyone can run them — they just need mise:

#!/usr/bin/env -S mise tool-stub
version = "20.0.0"
tool = "node"
bin = "node"

Generate them with mise generate tool-stub. Add --lock to embed platform-specific URLs and checksums for fully reproducible installs. Add --bootstrap to create a wrapper that installs mise itself if missing. You can also use the http backend style for custom binaries — no registry entry needed.

4. Typed task arguments with `usage` #

Tasks can have real CLI arguments with validation, choices, defaults, and auto-generated help:

[tasks.deploy]
usage = '''
arg "<environment>" help="Target env" { choices "dev" "staging" "prod" }
flag "-v --verbose" help="Verbose output"
flag "--region <region>" default="us-east-1"
'''
run = 'deploy.sh ${usage_environment} --region ${usage_region}'

mise run deploy --help prints a proper help page. Tab completion works out of the box — including completing argument values from choices or dynamic complete handlers. Adding autocompletion for custom values is as simple as:

complete "environment" run="mise plugins ls"

5. Lockfiles — avoid `GITHUB_TOKEN` issues with `mise lock` #

Pin exact versions, checksums, and download URLs for every tool:

mise lock

That’s it. Run it and it generates mise.lock with checksums and URLs for all common platforms. This is a big deal for teams — without a lockfile, every mise install hits the GitHub API to resolve versions and download URLs. GitHub’s API rate limits are aggressive for unauthenticated requests, and getting every developer on a team to configure a GITHUB_TOKEN is an unnecessary hassle. With a lockfile, installs are fully offline-capable: no API calls, no rate limits, no tokens needed.

Use --locked in CI to fail if the lockfile is missing or outdated.

6. Supply chain security #

Most tools in the mise registry now install through the aqua backend, which natively verifies integrity — no external tools required:

Checksums (SHA256, SHA512, Blake3) — always on
Cosign signature verification
SLSA provenance verification
GitHub Attestations — workflow-level verification
Minisign — public key signatures

Only 39 out of 919 tools in the registry default to a plugin-based backend (23 asdf, 16 vfox) — around 4%. The rest install through aqua, github, or other backends with built-in verification. Those remaining plugin-backed tools have all been forked to the mise-plugins org under mise maintainer control. When you run mise use ripgrep, you’re getting a verified binary from the vendor’s GitHub release — not running arbitrary bash from a third-party plugin.

7. Environment profiles with `MISE_ENV` #

Set MISE_ENV=staging and mise layers mise.staging.toml on top of mise.toml:

mise.toml              # shared defaults
mise.dev.toml          # dev overrides
mise.staging.toml      # staging overrides
mise.local.toml        # personal overrides, never committed

The catch: MISE_ENV determines which config files get loaded, so it can’t be set inside mise.toml itself. That’s what .miserc.toml is for — a lightweight config loaded before everything else:

# .miserc.toml
env = ["development"]

This way your project defaults to the development profile without requiring every developer to set an environment variable.

8. Shell aliases #

Project-scoped aliases that activate/deactivate as you cd:

[shell_alias]
ll = "ls -la"
dev = "npm run dev"
dc = "docker compose -f docker-compose.dev.yml"
src = "cd {{config_root}}/src"

Works in bash, zsh, and fish. Leave the directory and they’re gone.

9. `mise prepare` [experimental] #

Detects lockfiles and installs project dependencies only when they’re stale. If the content of package-lock.json has changed since the last run, it triggers npm install. Built-in providers for npm, yarn, pnpm, bun, go, pip, poetry, uv, bundler, and composer. Custom providers for anything else:

[prepare.codegen]
sources = ["schema/*.graphql"]
outputs = ["src/generated/"]
run = "npm run codegen"
depends = ["npm"]

Set auto = true and it runs automatically before mise run and mise exec. Pass --dry-run to see why each provider is stale (e.g., “package.json changed”, “outputs missing”).

Watch this space — this is an area I plan to improve further to give users a cargo/uv-like experience across all languages.

10. Monorepo tasks [experimental] #

Run tasks across packages with wildcard patterns:

mise //services/api:build          # specific package
mise //...:test                    # all packages
mise '//services/...:build'        # all under services/

Configuration inherits from parent directories — define node = "20" and common env vars in the root mise.toml, and every package gets them automatically. Individual packages can override just what they need (e.g., a legacy app pinning node = "14") while inheriting everything else. Enable with experimental_monorepo_root = true in your root mise.toml.

Bonus: The mise ecosystem #

fnox #

Secret management for development and production. Encrypt secrets in git with age or cloud KMS, or fetch them from AWS Secrets Manager, 1Password, Vault, and more. Shell integration auto-loads secrets on cd:

# fnox.toml
[providers]
age = { type = "age", recipients = ["age1ql3z..."] }

[secrets]
DATABASE_URL = { provider = "age", value = "YWdlLWVuY3..." }  # encrypted, safe to commit
API_KEY = { default = "dev-key-12345" }                         # plain default for local dev

[profiles.production.providers]
aws = { type = "aws-sm", region = "us-east-1", prefix = "myapp/" }

hk #

A git hook manager built for speed. The key innovation is read/write file locking: check commands (e.g., eslint, prettier --check) take read locks and run fully in parallel, while fix commands (e.g., prettier --write) take write locks to prevent race conditions. It runs checks first by default, only falling back to fixes when needed. No other git hook manager does this — tools like husky, lefthook, and pre-commit either run steps serially or do naive parallelism that can corrupt files when multiple fixers touch the same file:

amends "package://github.com/jdx/hk/releases/download/v1.36.0/hk@1.36.0#/Config.pkl"
import "package://github.com/jdx/hk/releases/download/v1.36.0/hk@1.36.0#/Builtins.pkl"

hooks {
    ["fix"] {
        fix = true
        steps {
            ["prettier"] = (Builtins.prettier) {}
            ["eslint"] = (Builtins.eslint) {}
            ["tsc"] { check = "tsc --noEmit" }
        }
    }
    ["check"] {
        steps {
            ["prettier"] = (Builtins.prettier) {}
            ["eslint"] = (Builtins.eslint) {}
            ["tsc"] { check = "tsc --noEmit" }
        }
    }
}

pitchfork #

Daemon manager for dev services. Auto-starts processes when you cd into a project, auto-stops when you leave. Ready checks, restart on failure, dependency ordering, and cron jobs:

# pitchfork.toml
[daemons.postgres]
run = "docker run --rm -p 5432:5432 -e POSTGRES_PASSWORD=dev postgres:16"
auto = ["start", "stop"]
ready_delay = 5

[daemons.api]
run = "npm run dev:api"
auto = ["start", "stop"]
ready_output = "listening on"
depends = ["postgres"]

1. Task sources and outputs #

2. The github, http, and s3 backends #