packwiz.infra.link

packwiz modpacks are installed by pointing a launcher at a pack.toml file served over HTTP, usually through the Java-based packwiz-installer for MultiMC or ATLauncher, which keeps the instance updated automatically. The same pack can also be exported as a CurseForge or Modrinth modpack if you want to publish through those platforms instead. This guide covers the distribution options and the steps for each.

What packwiz actually distributes

packwiz is a command line tool for creating Minecraft modpacks. Rather than managing JAR files directly, it stores mod information as TOML metadata files (pack.toml, index.toml, and per-mod mod.pw.toml files) that are easy to version-control and share with Git. The actual mod JARs are referenced by URL and downloaded by the client at install time.

That design is what makes automatic updating possible: the client reads the metadata, compares it against what it already has, and fetches only what changed.

Option 1: packwiz-installer (auto-updating instances)

This is the recommended path for servers and for anyone who wants players to stay in sync without manual re-downloads.

Prerequisites

• A launcher that supports pre-launch commands: MultiMC or ATLauncher.
• The pack metadata reachable over HTTP (a web host, or a local packwiz serve instance for testing).
• Java available to the launcher, since packwiz-installer is Java-based.

Steps

1. Host the pack so pack.toml is available at a URL.
2. In MultiMC or ATLauncher, open the instance's settings and add a pre-launch command that runs packwiz-installer against that URL.
3. Launch the instance. The installer reads the metadata, downloads the listed mods, and places them in the instance.
4. On later launches, the same command runs again and applies only the changes, so updates are fast.

What you get

• Optional mods are supported, so players can opt in or out of specific files.
• Fast automatic updates, which is the main reason this setup suits servers.
• Server-only and client-only mod handling, so each side gets the correct set.

Common snags

• If the metadata URL is wrong or unreachable, the installer has nothing to read — verify the URL in a browser first.
• Because the installer is Java-based, a missing or mismatched Java runtime in the launcher will stop it before any mods download.

Option 2: HTTP distribution with a local test server

You can distribute the pack from any HTTP server. For testing before you publish, packwiz includes a built-in local server via packwiz serve, which lets you confirm the installer works against your own machine before pointing players at a public URL.

A practical order of operations:

1. Build the pack and confirm the metadata is correct.
2. Run packwiz serve locally and test the installer against the local URL.
3. Once it works, upload the same files to your real HTTP host and update the URL in the launcher command.

Option 3: Export to CurseForge or Modrinth

If your goal is public distribution rather than a private server pack, packwiz can export the pack to a CurseForge or Modrinth modpack. Those exports are then published through the respective platform's normal process.

Choose this when:

• You want the pack discoverable on CurseForge or Modrinth.
• Your players prefer installing through those platforms rather than a launcher pre-launch command.

Choose packwiz-installer instead when:

• The pack is private, for example for a server community.
• You need automatic updates and optional mods.

Which distribution method fits

What packwiz is not for

Two limits are worth knowing before you commit:

• Managing downloaded mod files. packwiz tracks metadata, not a local JAR library; use CurseForge, GDLauncher, or another CLI for that.
• GUI users. packwiz is a command line tool. Third-party GUI efforts exist but are not part of the core tool.

If either of those is a hard requirement, a different modpack workflow will serve you better.

The packwiz documentation site (packwiz.infra.link) organizes its reference material into three main sections: Commands, Reference, and Pack format. If you need to look up a specific subcommand, understand configuration options, or learn how the TOML metadata files are structured, those are the sections to visit. The site also includes a Tutorials section for step-by-step guides covering modpack creation, mod management, Git usage, installation/distribution, and publishing.

Commands

The Commands section lists every packwiz subcommand with its own page. Based on the site's table of contents, the documented commands are:

Each command has a dedicated page in the documentation, so you can look up the exact syntax and available flags for the one you need.

Reference

The Reference section covers Additional options — configuration settings that apply across packwiz usage. This is where you'd look for behavior that isn't tied to a single subcommand.

Pack format

The Pack format section explains the three TOML metadata files that packwiz uses instead of managing JAR files directly:

• pack.toml — the top-level pack definition
• index.toml — the index of files in the pack
• mod.pw.toml — per-mod metadata

These files are designed to be version-controlled and shared with Git, which is the core of packwiz's approach.

Tutorials

If you're looking for task-oriented guidance rather than reference material, the Tutorials section covers:

• Creating a modpack — getting started, adding mods, using packwiz with Git
• Installing/distributing a modpack — installing with packwiz-installer, publishing to CurseForge, publishing to Modrinth

Quick orientation

• Looking up a command's syntax or flags → Commands section
• Understanding configuration behavior → Reference section
• Understanding the TOML file structure → Pack format section
• Learning how to do a specific task end-to-end → Tutorials section

The full documentation is available at packwiz.infra.link, with each section accessible from the site's table of contents.

packwiz is a command-line tool for creating Minecraft modpacks. Rather than managing JAR files directly, it stores modpack information as TOML metadata files that can be version-controlled and shared with Git. You can export the result to a CurseForge or Modrinth modpack, or use packwiz-installer to keep a MultiMC instance automatically updated.

It fits you if you want a Git-friendly, text-based way to build and distribute modpacks, especially for private server packs or for publishing to CurseForge and Modrinth. It does not fit you if you want a GUI, or if your main goal is managing mod JAR files you have already downloaded.

How packwiz works

The core idea is separating metadata from binaries. Instead of committing mod JARs to a repository, packwiz writes TOML files describing which mods belong in the pack and where they come from. Those small text files are what you track and share.

The pack format uses three kinds of TOML files:

Because the metadata is plain text, changes show up cleanly in diffs, and collaborators can review mod additions or removals the same way they review code.

What you can do with it

• Distribute private modpacks for servers — a common use case, since the pack definition can live in a repo while the installer pulls the actual files.
• Create modpacks for CurseForge and Modrinth — export directly to either platform's pack format.
• Import from CurseForge packs — bring an existing CurseForge pack into the packwiz workflow.
• Install and update many mods at once from CurseForge and Modrinth.
• Handle server-only and client-only mods so each side gets the right set.
• Generate remote file metadata from JAR files for CurseForge mods.

Features worth knowing

• Git-friendly TOML-based metadata format.
• A Java-based pack installer/updater that works with MultiMC and ATLauncher, with support for optional mods and fast automatic updates — useful for servers.
• Pack distribution over HTTP servers, including a built-in local server for testing.
• Easy installation and updating of multiple mods at once from CurseForge and Modrinth.
• Exporting to and importing from CurseForge and Modrinth packs.
• Server-only and client-only mod handling.

When packwiz is not the right tool

packwiz is not designed for managing downloaded mod files — for that, use CurseForge, GDLauncher, or another CLI. It is also not aimed at people who want a GUI, though some third-party efforts exist. If your workflow depends on a graphical interface or on organizing JARs you already have, packwiz will add friction rather than remove it.

Getting started

The documentation is organized into a few paths:

• Installation — set up the tool itself.
• Tutorials — creating a modpack, getting started, adding mods, using packwiz with Git, installing/distributing a modpack, installing with packwiz-installer, and publishing to CurseForge or Modrinth.
• Reference — additional options and the full command list, including packwiz init, packwiz add (via curseforge and modrinth subcommands), packwiz refresh, packwiz update, packwiz serve, packwiz pin/unpin, packwiz remove, packwiz migrate, and packwiz settings.

If you need help, the project points to its Discord server.

packwiz is a command-line tool for creating Minecraft modpacks that stores your pack as TOML metadata files instead of managing JAR files directly. To create a modpack, you run packwiz init to generate the metadata, add mods with packwiz curseforge add or packwiz modrinth add, and keep the index current with packwiz refresh. This workflow suits pack authors who want version-controllable packs, private server packs, or packs published to CurseForge and Modrinth. It is not intended for managing already-downloaded mod files or for users who want a graphical interface.

Prerequisites

• packwiz installed and available on your command line (see the Installation section of the packwiz documentation).
• A pack directory you can run commands in — packwiz writes its metadata files there.
• For mods pulled from CurseForge or Modrinth, you need the relevant mod identifiers (slugs or project IDs) that those platforms use.

Initialize the pack

Run packwiz init inside your pack folder. This creates the pack metadata, including pack.toml, which describes the pack itself. From this point the pack is defined by TOML files rather than by a folder of JARs, which is what makes it easy to version-control and share with git.

Add mods

Add mods from either platform:

• packwiz curseforge add — add a mod from CurseForge.
• packwiz modrinth add — add a mod from Modrinth.

Each added mod gets its own metadata file (the pack format documents mod.pw.toml for individual mods), so additions and removals show up cleanly in version control.

Refresh the index and check your work

After adding or changing mods, run packwiz refresh. This updates the index (index.toml) so it reflects the current set of mod metadata files. Use packwiz list to see what has been added to the pack.

Version-control with Git

Because packwiz stores metadata as TOML, you can commit pack.toml, index.toml, and the per-mod .pw.toml files to git and share the pack that way. The packwiz documentation explicitly frames the tool as git-friendly and points to an example pack for reference.

Distributing the pack

Once the pack is built, you have two main distribution paths:

packwiz also supports distributing packs over HTTP servers, with a built-in local server (packwiz serve) for testing, and it can export remote file metadata from JAR files for CurseForge mods.

Common sticking points

• Forgetting to refresh. Adding mods without running packwiz refresh leaves the index out of date.
• Expecting JAR management. packwiz is not designed for managing downloaded mod files — use CurseForge, GDLauncher, or another CLI for that.
• Wanting a GUI. packwiz is command-line first; the documentation notes some third-party GUI efforts exist but does not present them as the primary path.

For command-by-command details, the packwiz Commands reference covers init, curseforge, modrinth, refresh, list, serve, and the rest of the available subcommands.

packwiz is a command line tool for creating Minecraft modpacks that stores pack contents as TOML metadata files instead of managing JAR files directly. That design makes it strong for version control, server distribution, and publishing, but it also defines clear limits: it is not built for managing downloaded mod files, and it has no official GUI. If your workflow depends on either of those, another tool will likely fit better.

Where packwiz fits and where it does not

The project's own documentation draws the line directly.

packwiz is great for:

• Distributing private modpacks for servers
• Creating modpacks for CurseForge and Modrinth

packwiz is not so great for:

• Managing downloaded mod files (the docs suggest using Curse/GDLauncher or another CLI)
• People who want a GUI (though there are some third-party efforts)

So the comparison is less about packwiz being "worse" and more about which job you are actually doing.

Limitation 1: It does not manage downloaded mod files

This is the biggest practical difference from launcher-centric tools.

packwiz works on metadata, not on a folder of JARs you curate by hand. Its job is to describe a pack so it can be version-controlled, shared, exported, or installed elsewhere. If your main need is to browse, download, and organize mod files locally, the documentation points you to Curse/GDLauncher or another CLI instead.

Choose packwiz when the metadata is the artifact you care about. Choose a launcher-style tool when the downloaded files themselves are what you want to manage.

Limitation 2: No official GUI

packwiz is a command line tool. The documentation notes that it is not great for people who want a GUI, while acknowledging that some third-party efforts exist.

If a graphical interface is a hard requirement, treat packwiz as a poor fit unless you are willing to rely on unofficial tooling. If you are comfortable in a terminal, this limitation mostly disappears.

What you gain in exchange

The limitations come bundled with capabilities that launcher-style tools do not offer in the same way:

• Git-friendly TOML-based metadata format — pack contents are text files that version-control and share cleanly, with an example pack linked in the docs.
• Java-based pack installer/updater — works with MultiMC and ATLauncher, supports optional mods and fast automatic updates, which the docs call out as perfect for servers.
• Pack distribution with HTTP servers, including a built-in local server for testing.
• Easy installation and updating of multiple mods at once from CurseForge and Modrinth.
• Exporting to CurseForge and Modrinth packs, plus importing from CurseForge packs.
• Server-only and client-only mod handling.
• Creation of remote file metadata from JAR files for CurseForge mods.

How to decide

A reasonable rule: if your pack's value lives in its metadata and distribution, packwiz is a strong choice. If your pack's value lives in a locally managed set of JAR files or in a graphical workflow, look elsewhere first.

Getting started if packwiz still fits

The documentation is organized around a few entry points:

• Installation
• Tutorials — Creating a modpack (getting started, adding mods, using packwiz with Git) and Installing/distributing a modpack (installing with packwiz-installer, publishing to CurseForge, publishing to Modrinth)
• Reference — additional options, commands, and pack format details

If you need help, the project points to its Discord server.