Renovate

import Tabs from '@theme/Tabs'; import TabItem from '@theme/TabItem';

Renovate automates dependency updates by opening pull requests when new versions are released. Because moon builds on proto for toolchain management, and proto is supported by Renovate out of the box, most moon repositories work with Renovate with little to no configuration. This guide covers that native support, and how to extend it to versions pinned in moon's own configuration files.

Pin versions in .prototools (recommended)

The cleanest setup requires no Renovate configuration and no annotations at all. Renovate ships a built-in proto manager that updates tool versions declared in .prototools files automatically.

node = "22.18.0"
yarn = "4.16.0"
rust = "1.85.0"
moon = "2.4.2"

Because moon toolchains inherit their version from .prototools by default (via versionFromPrototools), you can leave the version out of .moon/toolchains.yml entirely and let proto be the single source of truth:

# No version here — inherited from .prototools
node: {}
rust: {}

With this approach, Renovate keeps .prototools current, moon resolves toolchains from it, and derived fields (like package.json's packageManager) stay in sync — no # renovate: comments required.

:::tip

If you can, prefer this over hard-coding a version in .moon/toolchains.yml. It's the least configuration, and nothing drifts out of sync.

:::

Versions in moon configuration

If you'd rather pin versions in moon's config files — or you have versions that don't live in .prototools at all (the moon versionConstraint, a CI input, a WASM plugin) — moon publishes a shared Renovate config preset to cover them.

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": ["config:recommended", "github>moonrepo/moon//ecosystem/renovate"]
}

If you'd rather not depend on the preset, copy its custom managers directly into your configuration — see the source at ecosystem/renovate.json.

Toolchain versions (no annotations)

The preset includes JSONata managers that read your toolchains config by structure, so a version pinned for a built-in toolchain is updated automatically — no comments needed. This works for the yml, yaml, json, and toml formats (in .moon/ or .config/moon/):

node:
  version: '22.18.0'
rust:
  version: '1.85.0'

Other versions

For anything the structural managers don't cover, the preset also includes a regex manager that reads a trailing # renovate: (or // renovate:) comment. Add it to the end of the line containing the version, and point it at a datasource and package. It applies to .moon/ (and .config/moon/) configs, moon.* project files, and .github/workflows/*.yml, in any comment-supporting format (yml, yaml, toml, jsonc, pkl, hcl — strict json has no comments):

# Pin the version of moon itself
versionConstraint: '>=2.4.2' # renovate: datasource=github-releases depName=moonrepo/moon extractVersion=^v(?<version>.*)$

- uses: 'moonrepo/setup-toolchain@v0'
  with:
    proto-version: '0.58.2' # renovate: datasource=github-releases depName=moonrepo/proto extractVersion=^v(?<version>.*)$

In formats that use // for comments (JSONC, Pkl, HCL), the // renovate: form works the same way:

{
  "versionConstraint": ">=2.4.2" // renovate: datasource=github-releases depName=moonrepo/moon extractVersion=^v(?<version>.*)$
}

To annotate versions in other files — such as WASM plugin versions in .prototools — append their paths to managerFilePatterns in your own customManagers entry.

Datasource reference

Useful when annotating a version, or adding a toolchain the structural manager doesn't cover. These mirror the datasources Renovate's native proto manager uses.

Tips and limitations

• Config format coverage. Comment-free structural updates work for the yml, yaml, json, and toml formats; jsonc, pkl, and hcl are updated through # or // annotations. Strict json can't hold comments, so pin those toolchains structurally or in .prototools.
• Aliases are skipped. Values like latest, stable, canary, or nightly can't be resolved to a concrete version, and are ignored.
• Pin each toolchain in one place. Don't set the same version in both .prototools and .moon/toolchains.yml (or add an annotation on top of a structurally-managed version) — you'll get duplicate pull requests.
• Propagate changes on self-hosted Renovate. You can run moon sync (or any command) after an update via postUpgradeTasks to keep generated files in sync.
  to batch toolchain bumps into a single pull request.