Deployment Rules

Fine-tune how mods are deployed with a rule engine that can skip, redirect, or rename files conditionally.

Last updated on

What Are Deployment Rules?

Deployment rules let you control how individual mods (or groups of mods) are handled during deploy. Instead of a one-size-fits-all approach, you can write rules like:

"Skip this mod on Fabric instances"
"Redirect this datapack to the Paxi folder"
"Rename this mod's file to a stable name"

Rules live in profile.json under setup.rules, and can also be edited from the instance's Setup page.

Rule Anatomy

A rule has two parts:

Selector — which packages does this rule apply to?
Actions — what should happen to matching packages?

Selectors

Selectors are boolean expressions that match packages by their properties. A selector is a JSON object with a type:

`type`	Matches by	Field
`pref`	Package reference (exact or partial)	`pref`
`repository`	Source repository	`repository`
`tag`	Tag name	`tag`
`kind`	Resource type	`kind`

kind values are mod, resourcePack, shaderPack, dataPack and world.

Selectors combine through boolean operators, which take their operands in a children array:

and — all sub-selectors must match
or — any sub-selector must match
not — inverts a selector

For example, all CurseForge data packs:

{
  "type": "and",
  "children": [
    { "type": "repository", "repository": "curseforge" },
    { "type": "kind", "kind": "dataPack" }
  ]
}

Actions

A rule applies any combination of three actions:

Field	What it does
`"skipping": true`	Don't deploy this package at all
`"destination": "<folder>"`	Deploy into this folder instead of the default one
`"normalizing": true`	Rename the file to the package's project name plus its original extension

destination is relative to the Run Directory (build/). skipping and normalizing default to false when omitted, and a rule itself can be turned off with "enabled": false.

Common Use Cases

Skip Server-Side Mods

If you have server-side mods that shouldn't be in a client instance:

{
  "selector": { "type": "tag", "tag": "server-only" },
  "skipping": true
}

Redirect Datapacks for Paxi

Different loaders use different datapack paths. If you use Paxi:

{
  "selector": { "type": "kind", "kind": "dataPack" },
  "destination": "datapacks/"
}

Normalize Filenames for Resource Packs

Resource pack files often include version numbers in their filenames — Sapphire-v2.1.zip, for example. When the pack updates to Sapphire-v2.2.zip, the filename changes, and Minecraft forgets your resource pack selection. You have to re-enable it every time.

normalizing renames the deployed file to the package's project name plus its original extension, so the name stays stable across updates:

{
  "selector": { "type": "pref", "pref": "pref://modrinth/sapphire" },
  "normalizing": true
}

The project name comes from the repository the package was installed from, so the file stays Sapphire.zip regardless of what version number the author used. Your resource pack won't be deselected every time it updates.

Adding Rules

Open your instance and go to the Setup tab.
Open the Rules editor for the instance.
Add a new rule: define the selector and its actions.
Save. Rules take effect on the next deploy.

Rules and Tags

Tags and rules work together. The typical workflow:

Tag your mods with meaningful labels (see Tags).
Write rules that target those tags.

This gives you a maintainable system — change a mod's tags instead of editing individual rules.

On this page