PrismLauncher: strip the API keys out of CMakeLists.txt before you repackage

A MultiMC fork that asks you to state non-affiliation in public

The first fact about this project is its lineage. Prism Launcher is described as a custom launcher for Minecraft that lets you easily manage multiple installations of Minecraft at once, and it states plainly that it is a fork of the MultiMC Launcher and is not endorsed by it. That sentence is not decoration, because the project has a written policy for anyone who forks, redistributes or provides custom builds. The rule has a legal half and a courtesy half, and the distinction matters. The legal half is that you are free to fork, redistribute and provide custom builds as long as you follow the license terms, and the README calls that a legal responsibility. The courtesy half applies when you made code changes rather than just packaging a build: make it clear that your fork is not Prism Launcher and is not endorsed by or affiliated with the Prism Launcher project. The licensing split follows the same layering. All launcher code is GPL-3.0-only, while the logo and related assets sit under a separate licence, CC BY-SA 4.0. So a fork that keeps the launcher code must honour GPL-3.0, and a fork that keeps the branding inherits a share-alike obligation on those assets as well.

Downloads live on the project website, and build status lives in Actions

Nothing in the repository distributes binaries, and the installation section is three links rather than a set of commands. All downloads and instructions for Prism Launcher are on the project website, at the download page. The last build status is in the GitHub Actions tab, and the same tab carries pull request status, which is a way to see whether a proposed change is currently green. A third link points at a repology.org page listing packaged versions, which is where you find out whether your distribution already ships a build and which version it carries. This arrangement has a practical consequence for anyone automating installs: you cannot resolve a download URL from the repository the way you can with many projects, so a script has to consult the website or the Actions artifacts rather than a fixed path. For a Linux user the packaged route matters, because a distribution build removes the question of which runtime the launcher expects on the system. For everyone else, the site is the only sanctioned source of a stable release, and the last releases listed are 11.1.1 dated 2026-09-28 and 11.1.0 dated 2026-09-03.

Nightly builds ship debug symbols, and the warning is written in caps

There is a development build channel, and it opens with a warning that is unusually blunt: these builds are not intended for most users, there may be bugs and other instabilities, and you have been warned. Two sources feed it. GitHub Actions provides builds, and that includes builds from pull requests opened by contributors, which is worth noting because it means artifacts can originate from code that has not been reviewed or merged. The second source, nightly.link, always points only to the latest version of the develop branch, so the artifact you get is by definition the newest commit rather than a tagged state. The binaries carry debug information, so their file sizes are relatively larger, and prebuilt development builds are provided for Linux, Windows and macOS. On Linux there is an additional route, the project's own Flatpak nightly repository, and most software centers are able to install it by opening the flatpakref link directly. For a user this channel is fine for testing a change before it is released. For a deployment, it is the wrong input: an unstable artifact from an unmerged pull request is a supply chain decision, not a preference, and the size penalty makes it a poor fit for anything bandwidth constrained.

A repackaged build must blank the API keys or disable those features

This is the most concrete engineering instruction in the project and it is easy to miss. If you have made code changes rather than only repackaging, the policy asks you to go through CMakeLists.txt and change Prism Launcher's API keys to your own, or set them to empty strings to disable them. The consequence of blanking a key is described precisely: the program will still compile, but the functionality requiring that key will be disabled. So this is not a compile error you will notice, it is a build that looks fine and behaves differently, which is the harder class of mistake to catch in review. A second requirement applies even when you only package: if you are building for your distribution, set Launcher_BUILD_PLATFORM to a slug representing that distribution, with archlinux, fedora and nixpkgs given as examples. Why the keys matter is stated too. If you build without removing the provided API keys, you are accepting the Microsoft Identity Platform Terms of Use and the CurseForge 3rd Party API Terms and Conditions. If you do not agree with those terms, remove the associated keys by setting them to an empty string. The practical checklist for a packager is therefore short: change or clear the keys, set the platform slug, and be certain about which side of those two documents you are on.

CMake presets, vcpkg, nix and a Containerfile all live in one tree

The build configuration tells you what kind of C++ project this is, and the root is unusually well equipped. CMakeLists.txt is the entry point and CMakePresets.json sits beside it, so builds are described declaratively rather than as a list of flags people memorise. A buildconfig/ directory and a cmake/ directory hold the configuration pieces. Dependency management appears three separate ways: vcpkg.json and vcpkg-configuration.json for the C++ native approach, a full Nix layer with default.nix, flake.nix, flake.lock and shell.nix, and an .envrc file that suggests a direnv-based workflow on top of it. A Containerfile provides a reproducible container build. The code layout is conventional for a launcher: launcher/ for the application, libraries/ for bundled dependencies, program_info/ for platform metadata such as the icon names the README references, plus scripts/, tests/ and tools/. Quality tooling is checked in rather than assumed, with .clang-format, .clang-tidy and .editorconfig for style, .markdownlint.yaml and .markdownlintignore for documentation, CODE_OF_CONDUCT.md and CONTRIBUTING.md for process, and renovate.json for dependency update automation. The submodule list and a .git-blame-ignore-revs file round out a tree that is set up for a large group of contributors rather than a single author.

The default branch is develop, so your build can differ from the release

The default branch of this repository is develop, not main and not a release branch, and that single fact shapes how you should think about building from source. The development build channel is pointed at exactly that branch, with nightly.link always resolving to the latest version of develop, so the two are the same stream of commits. The consequence is that anything you compile yourself tracks unreleased work, while the 11.1.1 binary distributed on the website is a tagged, tested state. Recent history shows both moving: 11.1.0-pre1 on 2026-08-18, 11.1.0 on 2026-09-03, and 11.1.1 on 2026-09-28, with the last push dated 2026-11-01. That is a project shipping steady releases on top of an active development branch, not a stale fork. What it means for you is that a bug you hit while building from source may already be fixed in a release, or may only exist on develop, and telling those apart requires knowing which tree you built. If you are packaging for others, build from a tag rather than from the branch tip, and record which one. The repository also publishes its own build instructions off-repo, at the development section of the project wiki, rather than in the README, so the README is not the place to look for dependency details.

Weblate, three chat spaces and a sponsor list carry the project

The non-code infrastructure is spelled out in the README and it explains how a fork inherits or loses things. Translation is hosted on Weblate, and the guidance on translating is kept in a separate repository, PrismLauncher/Translations, which is where a fork that wants a different language base would start rather than editing strings in place. Support runs through a Discord server, a Matrix space and a subreddit, with GitHub issues as the place for bugs and feature suggestions, and the existence of the Matrix room is the detail worth noting for organizations that have moved away from Discord. Funding is handled through Open Collective backers, and the thank-you list names the infrastructure that keeps the pipeline running: JetBrains licenses for their products under their Open Source program, Weblate hosting the translation effort, Netlify providing web services under their Open Source program, and MacStadium supplying M1 Macs for development purposes. That list is effectively a dependency map for a fork. If you fork and change the code, you keep the licence obligation and lose the sponsor relationships, so the CI, the translation platform and the developer hardware become costs you either absorb or replace.

Editorial conclusion

Use Prism Launcher when you want several isolated Minecraft installations with per-instance settings rather than one global setup, and take the release build from the project website rather than a nightly. If you intend to package it for your own distribution, clear the API keys in CMakeLists.txt and set Launcher_BUILD_PLATFORM to your distribution slug, and read the Microsoft Identity Platform and CurseForge terms before you decide to keep them. If you cannot accept those terms, expect the features behind those keys to be disabled rather than merely unconfigured.

Frequently asked questions

Official sources

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