What PolyMC's fork policy, API key and debug builds mean for packagers

Why this MultiMC fork exists and whom it serves

PolyMC is a custom launcher for Minecraft whose stated job is to let one person hold several installations of the game at once, which the repository description repeats almost word for word. It descends from the MultiMC Launcher, and one line of its own README says plainly that this is a fork and is not endorsed by MultiMC. The positioning sentence right after that names predictability, long term stability and simplicity as the goals, and the project keeps a fork FAQ page of its own at polymc.org/wiki/overview/faq/ for the reasoning behind the split. No line of prose in the repository explains the fork, so that wiki page is the only place the motivation is recorded. The practical reading for a user is that this is a launcher run on its own terms, with its own issue tracker, its own Discord server and its own subreddit at `r/PolyMCLauncher`, and none of the support or account paths tied to MultiMC carry over.

Topic tags, not prose, define which loaders are in scope

The primary language is C++, and the topic tags attached to the repository read cpp, qt, qt6, fabricmc, forge, linux, minecraft, minecraft-launcher, modrinth, polymc and quiltmc. That list is the closest thing to a specification of what the launcher can load: three mod loader families plus the modrinth content source, sitting on a Qt6 desktop application. Quilt appearing next to Fabric tells you the launcher tracks two closely related loader families alongside Forge, a detail no line of prose in the repository mentions. How an instance is bound to a loader is nowhere described. There is no documented config key for loader selection, no menu path, no screenshot, and the README does not state which Minecraft versions or which Java versions an installation expects. C++ paired with Qt6 also tells you the binary is a compiled desktop program rather than a script, which matters for anyone planning to put it on a machine with no display.

The tree a self-host copies, from launcher/ to flake.nix

The top level carries two build systems at once. CMake is the first: CMakeLists.txt at the root, the buildconfig/ and cmake/ directories beside it, and a .gitmodules file recording that parts of the tree come from other repositories. Nix is the second, through default.nix, flake.nix and flake.lock, so a checkout can be evaluated without a hand-written configure step. The entries that matter for anyone building the source themselves, one per line exactly as the listing gives them:

launcher/
libraries/
buildconfig/
cmake/
program_info/
tests/
default.nix
flake.nix
flake.lock

The default branch is `develop`, so a clone of the default ref is a working branch rather than a frozen state, and a packager who tracks it inherits whatever the tip happens to contain that day. Contributor docs sit at the top level as `BUILD.md` and `CONTRIBUTING.md`, next to `COPYING.md`, while `.clang-format` and `.clangd` set out the formatter and language server configuration a patch should respect. The automation directories `.ci/` and `.github/` exist, but the entry names say nothing about what those workflows do.

First use means leaving the repository for four links

Installation here is four links and no commands. Downloads and instructions live at polymc.org/download/, build status is read from the GitHub Actions page, and anyone compiling from source is sent to the wiki:

polymc.org/download/
polymc.org/wiki/development/build-instructions/
polymc.org/wiki/overview/faq/
hosted.weblate.org/projects/polymc/polymc/

So a first run means fetching a build from the download page, unpacking or mounting the portable binary, and signing in to a Minecraft account, which works only while the key compiled into the binary is intact. The README documents no command line build sequence and no first-run wizard, so neither the install nor the account step can be traced inside the repository. Support comes in two forms, an issue on the tracker or the Discord server, and the project also points at `r/PolyMCLauncher` for issues and suggestions. Translations are handled on Weblate, with the translation effort itself hosted in a separate `PolyMC/Translations` repository.

Per-commit builds carry debug information, and the distro packages follow them

Development builds are produced per commit from the Actions workflow, and the README warns that they contain debug information, so their file sizes are relatively larger than the numbered builds. Portable builds exist as AppImage on Linux alongside Windows and macOS binaries. For Debian and Arch there are two community packages, both named `polymc-git`, and both are described as carrying the latest development versions:

aur.archlinux.org/packages/polymc-git/
mpr.makedeb.org/packages/polymc-git

Installing either one therefore hands a packager a per-commit binary with debug information inside it rather than the numbered 8.1 build, so anyone comparing disk footprint against a numbered build is comparing two different kinds of artifact. Flatpak users carry one extra step, since the project points them at the flathub-beta channel and names no other channel. Tagged builds 8.0 and 8.1 are dated 2026-10-01 and 2026-10-03, the 7.1 build is dated 2026-07-30, and the last push is dated 2026-10-04, so the tip of `develop` sits one day past the newest numbered build. No pinning path back to 8.1 is documented, which leaves distribution package maintainers tracking whatever commit the next push lands.

The shipped Microsoft API key decides whether a self-build can log in

Every fork carries some tax, and PolyMC names its own: the Microsoft API key embedded in CMakeLists.txt. The redistribution policy asks anyone who changes the code, rather than only repackaging a binary, to make clear that the fork is not PolyMC and is not endorsed by or affiliated with the project, and to change that key to their own value or set it to an empty string. An empty string still compiles, and the program still runs. What it removes is the ability to log into a Minecraft account, so a self-built launcher starts, manages installations and cannot sign in until someone supplies a key. Here is the contradiction worth naming plainly: those two requests are framed as a basic courtesy, yet the paragraph immediately after states that building the software without removing the provided key means accepting the Microsoft Identity Platform Terms of Use. Accepting a third party's terms is not a courtesy. Nothing in the repository explains how a packager obtains a key, and no environment variable or configuration file is offered as an alternative to editing CMakeLists.txt before the first compile.

The code and the icon carry separate reuse terms

PolyMC splits what may be reused from what may be rebranded: launcher code is under GPL-3.0-only, and the logo and related assets are under CC BY-SA 4.0. That split is the practical constraint for anyone redistributing, because a custom build can change the code while keeping the icon, and the icon carries its own terms independently of everything built around it. The policy itself is permissive about forks as long as the terms are followed, and it asks for disclosure plus an API key change and nothing else, so there is no approval process to negotiate with anybody. Both texts sit at the top level of the tree, next to `CONTRIBUTING.md`, so nothing has to be fetched from elsewhere before a redistribution. Rebuilding for a distributor is cheap too, because distribution metadata is not kept in this repository at all: it lives in the website repository under `src/download`, where a change arrives as a pull request or an issue.

No documented path for headless or scripted launching

The clearest wrong-tool case is any environment without a desktop. PolyMC is a C++ and Qt6 application whose supported artifacts are portable builds for Linux, Windows and macOS, two `polymc-git` packages, and a Flatpak channel, none of which is a server package. The README documents no command line interface, no headless mode and no unattended install, so a team scripting instance creation in CI has nothing to drive here, since the entire interaction model is a desktop window backed by a Discord for support. The build system is the only scripted surface the repository truly offers, through CMakeLists.txt, the `cmake/` directory and the Nix flake. Two gaps matter for anyone evaluating it further: no rollback to an earlier build is documented, and no supported range of Minecraft or Java versions is stated, so both answers have to come from the wiki rather than from the repository.

Editorial conclusion

PolyMC fits players who keep several Minecraft installations and want a Qt6 desktop launcher covering Fabric, Forge and Quilt without writing code. It is the wrong tool for a headless box or a scripted pipeline, because the repository documents no command line entry point and no rollback. Before running any binary, check that it came from polymc.org/download/ rather than a per-commit build carrying debug information, and before redistributing a self-built one, confirm the Microsoft API key in CMakeLists.txt was replaced or blanked.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. PolyMC/PolyMC on GitHub
3. Project website
4. README
5. Releases