renovate/lib/modules/manager/mise

Renovate can update mise configuration files.

Supported configuration files

Renovate supports all standard mise configuration file patterns:

• mise.toml, .mise.toml
• mise/config.toml, .mise/config.toml
• .config/mise.toml, .config/mise/config.toml, .config/mise/mise.toml
• .rtx.toml (legacy)
• Environment-specific variants (e.g., mise.production.toml, .mise.dev.toml)
• Local variants (e.g., mise.local.toml, .mise.local.toml)

Supported tool locations

Renovate supports top level tools and tasks.*.tools keys.

Remote task files

Renovate supports remote git task files in tasks.<name>.file, using the same git:: forms as for remote include entries. The path may point to any file, not only to TOML files. ref handling, datasources and comment hints work like for remote include entries, and the dependencies have the depType task-<name>-file. Local paths and plain http(s):// URLs without the git:: prefix have no version and are ignored.

[tasks.build]
file = "git::https://github.com/org/tasks.git//scripts/build.sh?ref=v1.0.0"

[tasks.lint]
file = "git::ssh://git@gitlab.com/org/tasks.git//lint.sh?ref=0123456789abcdef0123456789abcdef01234567" # v1.0.0

Remote include support

Renovate supports the remote forms of the top level include key:

• git::<https|http|ssh>://<host>/<repo>.git//<path>?ref=<ref> or git::git@ssh.dev.azure.com:v3/<org>/<project>/<repo>//<path>?ref=<ref>: the ref is looked up as a Git tag. GitHub, GitLab and Bitbucket Cloud repositories use the github-tags, gitlab-tags and bitbucket-tags datasources, other hosts use git-tags. Entries without a ref are skipped, as mise then uses the default branch.
• oci::<registry>/<repo>[:tag][@sha256:<digest>]: handled like a Docker image, using the docker datasource.

A tag ref is updated to the newest tag:

include = [
  "git::https://github.com/org/cfg.git//mise.toml?ref=v0.5.0",
  "oci::ghcr.io/org/base:1.0",
]

Pinning to a commit sha

Optionally, a ref can be a full or short commit sha, if it has a trailing # <version> or # <branch> comment. Renovate updates the sha and the comment:

include = [
  # tracks tags: the sha and the comment are bumped to the new tag
  "git::https://github.com/org/cfg.git//mise.toml?ref=0123456789abcdef0123456789abcdef01234567", # v0.5.0
  # tracks a branch: the sha is bumped to the head of the branch
  "git::https://gitlab.com/org/cfg.git//mise.toml?ref=0123456789abcdef0123456789abcdef01234567", # main
]

• The comment must only contain the version (# v0.5.0) or the branch name (# main).
• Branches use the github-digest datasource for GitHub and git-refs for other hosts.
• Sha refs without a usable comment are skipped (unversioned-reference).
• Comments of non-sha refs are ignored.
• Only comments of entries in multi-line arrays are read, as the comment of a single-line array can not be assigned to one entry.
• oci:: entries with a digest but no tag do not support comment hints.

Renovate does not fetch the included files, so the tools they define are not updated. include entries are not locked by mise.lock.

Lock file support

Renovate supports mise lock files (mise.lock). When a lock file is present:

• Dependencies will have their lockedVersion extracted from the lock file

• Renovate can update lock files when dependencies change

• Fuzzy selectors such as latest, lts, 25, 25.1, and temurin-25 are resolved against their locked version and updated in mise.lock only

• latest remains unbounded; partial selectors remain restricted to their major/minor range; lts is supported for the core Node.js and Java tools

• Concrete versions such as 25.0.3 retain Renovate's normal source-file update behavior

• To keep concrete versions pinned, set updatePinnedDependencies to false in the mise manager configuration

  {
    "mise": {
      "updatePinnedDependencies": false
    }
  }
  

• Lock file maintenance is supported via the lockFileMaintenance option. When the mise version Renovate runs supports it (see safe mode for how the version is detected), maintenance runs mise lock --bump, which advances fuzzy selectors (e.g. node = "22") to the latest matching version rather than only refreshing existing locked versions.

When mise lock pins a tool's dependencies in a native dependency sidecar (for example .mise/locks/npm-prettier/3.3.3/aube-lock.yaml), Renovate commits the sidecar changes together with the lock file, including new sidecar directories and the removal of ones that mise lock deleted.

Renovate recognizes environment-specific lock files:

• mise.lock - default lock file
• mise.local.lock - local configuration lock file, typically ignored alongside mise.local.toml
• mise.{env}.lock - environment-specific lock files (e.g., mise.production.lock)
• mise.{env}.local.lock - environment-specific local lock files, typically ignored alongside mise.{env}.local.toml

For more information about mise lock files, see the mise lock file documentation.

Trust model for lock file updates

Running mise lock can execute repository-defined behavior, so Renovate treats mise lockfile refreshes as an unsafe execution.

Self-hosted administrators must explicitly allow this path by including mise in the global allowedUnsafeExecutions setting.

Because mise lock can execute repository-defined scripts, Renovate treats lockfile refreshes as an unsafe execution and attempts to run mise in safe mode.

If mise does not support safe mode or version detection fails, Renovate blocks all mise operations.

Allowing Unsafe Executions

Self-hosted administrators can permit these operations by adding "mise" to the global allowedUnsafeExecutions configuration.

Once allowed, Renovate runs mise trust before mise lock when a mise.lock file is present. This exposes the trust step in execution logs and defers trust rules to mise.

In particular:

• an existing mise.lock is required
• self-hosted administrators decide whether this unsafe execution is acceptable for their environment

Renovate only updates primary versions

Renovate's mise manager is designed to automatically update the first (primary) version listed for each tool in the mise.toml file.

Secondary or fallback versions require manual updates.

Example

Given a mise.toml entry like:

[tools]
erlang = ["23.3", "22.0"]

Renovate will update "23.3" (the primary version) but will not touch "22.0" (the fallback version).

The same applies when the array items are inline tables:

[tools]
rust = [
  { version = "1.98.1", components = "clippy,rustfmt" },
  { version = "nightly-2026-07-12", profile = "minimal" },
]

Renovate will update "1.98.1" and read backend options such as version_prefix or tag_regex from that first item only.

Why can Renovate only update primary versions?

To maintain consistency and reliability, Renovate opts to only manage the first listed version.

• Fallback versions can often be older versions of a tool that are known to work and are there as a backup.

This follows the same workflow that Renovate's asdf manager uses.

Short names support

Renovate uses the mise registry to resolve tool short names to their appropriate datasource.

Where possible, Renovate will automagically support tools from the mise registry (via mise registry --json).

This means that any tool in the mise registry that has a supported backend (e.g. aqua, github, cargo) should be automatically supported by Renovate.

Adding new tool support

If a tool you need is not yet in the mise registry, add it upstream to mise. Once Renovate syncs its registry data, the tool will be supported automatically, as long as it is in a backend that Renovate supports.

For tools that need a custom datasource mapping (e.g. core tools like node, python), you can create a PR to extend Renovate's mise manager directly.

If you want to add support for other tools' short names to mise, you can create a PR to extend Renovate's asdf manager, which indirectly helps Renovate's mise manager as well. Even if the tool does not use the asdf backend in the registry, the short names added to the asdf manager will still be used in the mise manager.

This may no longer be necessary now we automagically add support via the tools that the mise registry advertises.

Backends support

Renovate's mise manager supports the following backends:

• core
• asdf
• aqua
• cargo
• conda
• gem
• github
• gitlab
• go
• npm
• pipx
• pypi
• spm
• ubi
• vfox

Limitations

Renovate's mise manager does not support the following tool syntax:

• asdf and vfox plugins e.g. asdf:mise-plugins/asdf-yarn or vfox:version-fox/vfox-elixir Short names with backends like asdf:yarn or vfox:elixir are supported if the short names (yarn, elixir) are supported.

• aqua packages with http package type. However if the short name using aqua backend is supported by Renovate, it will be updated. e.g. aqua:helm/helm is not supported, but helm or aqua:helm is supported.

• aqua packages with version_filter. We don't read the aqua registry itself, so we can't support this feature. If some packages using version_filter like aqua:biomejs/biome are not updated or updated incorrectly, set extractVersion in the Renovate config manually like below.

  {
    "packageRules": [
      {
        "matchDepNames": ["aqua:biomejs/biome"],
        "extractVersion": "cli/(?<version>.+)"
      }
    ]
  }
  

• Some of ubi backend tools with tag_regex option. The tag_regex option is used as extractVersion, but the regex engines are not the same between mise and Renovate. If the version is not updated or updated incorrectly, override extractVersion manually in the Renovate config.

• Some of github backend tools with version_prefix option. The version_prefix option is converted to extractVersion by escaping special regex characters. If the version is not updated or updated incorrectly, override extractVersion manually in the Renovate config.

• Renovate will prefer the github: backend over other backends, if using the tool definition from the mise registry

Supported default registry tool short names