packwiz keeps a Minecraft modpack in git as TOML, not as a folder of jars

The pack is metadata, and the jars are somebody else's problem

packwiz is a command line tool for creating Minecraft modpacks, and the way it works is that instead of managing JAR files directly, it creates TOML metadata files which can be easily version controlled and shared with git. There is an example pack in the repository for exactly that purpose.

The reason this matters is that a modpack is a list, and a list is what a version control system is good at. A jar is a binary blob that changes when it is rebuilt, that cannot be reviewed in a diff, and that bloats a repository. The TOML file changes only when the pack changes, so a version bump of one mod is a one line change, and a pull request that swaps three mods is readable.

The tool then exports the pack in the formats the platforms expect. You can export it to a CurseForge or Modrinth modpack, or use packwiz-installer for an auto updating MultiMC instance. The README names the two use cases it is good for, distributing private modpacks for servers, and creating modpacks for CurseForge and Modrinth.

The second is worth pausing on. Distributing a private pack for a server is a different problem from publishing a public pack, because a server team usually wants to change the mod list over time without asking every player to reinstall anything, and that is what the installer and the update mechanism are for.

The features are a list of distribution problems solved

The feature list in the README reads like a set of answers to specific distribution problems.

Easy installation and updating of multiple mods at once from CurseForge and Modrinth is the core one, and the packwiz-installer is the mechanism: a MultiMC pack installer and updater, with support for optional mods and fast automatic updates, which the README describes as perfect for servers.

Exporting to CurseForge and Modrinth packs, and importing from CurseForge packs, covers the round trip between the local format and the platform formats, so a pack that started as a set of TOML files can be published without retyping the mod list, and a pack downloaded from CurseForge can be brought into the tool and then maintained in git.

Server-only and client-only mod handling is the feature that most obviously comes from real use. A server pack and a client pack are not the same list, and a mod that must be present on the server but not on the player is a distinction that a flat list of jar files cannot express, and that a naive modpack format gets wrong.

Pack distribution with HTTP servers, with a built in local server for testing, is the fourth piece. A pack that lives in git still has to reach the machines that install it, and a built in server means you can test the exact distribution path locally before pointing it at a real host.

What packwiz deliberately does not do

The README has a section headed packwiz is not so great for, and it is more useful than the feature list.

The first entry is managing downloaded mod files, and the advice is to use Curse or GDLauncher or another CLI for that. The division is clean: packwiz owns the list, the launcher owns the files. A tool that tried to do both would end up with the binary management problem that the TOML format exists to avoid, and the launcher that already solves it solves it well.

The second entry is people who want a GUI, and the README notes that although there are some third-party efforts, the project itself is a command line tool. There is a link to one of those efforts in the repository, and that is the honest shape of the answer: the GUI is somebody else's project, and packwiz does not try to be one.

There is a third, quieter limitation. The CurseForge side needs a file to point at, and the feature list includes the creation of remote file metadata from JAR files for CurseForge mods, which is the step that turns a local jar into something a remote instance can fetch. That step is a conversion, and it is a place where a pack that was fine locally can stop being fine once it is distributed, because the remote file has to exist and be reachable at the moment the instance updates.

The tool is also explicit about the audience it does not serve. It is a pack authoring and distribution tool, not a launcher, and the value of the whole design depends on that line being respected.

Installing it: a build artifact, nightly.link, or go install

There are three ways to get the binary, and the README is refreshingly honest about the rough edges of the first one.

Prebuilt binaries are available from GitHub Actions, and the README says the UI is a bit terrible, but essentially you select the top build and then download the artifact ZIP for your system at the bottom of the page.

The second option is nightly.link, and the instruction is to go to the page and download the artifact for your system.

To run the executable you first extract it, then add the folder where you extracted it to your PATH environment variable, with a tutorial link for Windows, or move it to where you want to use it.

The third option is compiling from source, and the requirements are Go 1.24 or newer from golang.org/dl, and then a single command, with the README warning to be patient because it has to download and compile the dependencies as well.

go install github.com/packwiz/packwiz@latest

That route is the most reproducible of the three, and it is the one a server operator is likely to pick, because the version ends up in the same place as the rest of the tooling on the machine and updating it is a matter of running the same command again.

The documentation is published at packwiz.infra.link, with the pages for hosting on CurseForge and for installing with packwiz-installer being the two a first time user will want, and there is a Discord server for help.

The Go code shows how the project is put together

The dependency list is a reasonable map of the project, and the module layout in the repository is the other half of the picture.

The module is github.com/packwiz/packwiz, and the direct dependencies split into groups. The format and the platform integrations are BurntSushi/toml for the TOML itself, Masterminds/semver for version comparison, and codeberg.org/theepicblock/go-modrinth for Modrinth. The command line is cobra for the command structure and viper for configuration, with pflag and mousetrap behind it, and there is a progress bar library, vbauerster/mpb, which is what you would expect in a tool that downloads many files at once. There is also a terminal menu library, wmenu, and fuzzy matching, which is how a mod is picked out of a long list.

The repository layout maps onto those responsibilities. There are directories for core, for curseforge, for modrinth, for github, for settings, for url handling, for utils, a cmdshared directory for code shared between commands, a cmd/ directory for the command definitions, and a migrate/ directory. There is also a nix/ directory with flake.nix and flake.lock, so the tool can be run from Nix, and a .goreleaser.yml for the release builds that GitHub Actions produces.

Two dependencies are worth a second look. The Murmur hash library is what makes a jar's identity stable across the CurseForge ecosystem, and the FlexVer library is a Minecraft specific version comparison scheme, which is not the same thing as semver and is why both are present. A tool that has to compare a file against a catalogue of published files and decide whether the file matches what the catalogue says needs exactly those two pieces.

Editorial conclusion

packwiz fits a server operator or a pack author who wants a modpack under version control, with the mod list reviewable in a pull request and the instance updated automatically when the list changes. It is the wrong tool if you want a launcher that downloads and organises mod files for you, because the README says that job belongs to Curse, GDLauncher or another CLI. Verify first that your launcher can use the exported pack format, and check the server only and client only mod handling, since that is where a hand written pack usually goes wrong.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. packwiz/packwiz on GitHub
4. Project website
5. README