SKCraft Launcher turns a modpack folder into a branded installer

The list of what it is and is not for

The README opens by asking a question and then answering it twice, once for who should use it and once for who should not, and the second list is the more useful one for an evaluation. It may not be for you if you made a cool modpack and just want it out there, if you do not have a website or a place for people to download files from, or if you do not want anything to do with distributing the launcher. That is a much narrower product than a generic modpack hosting site. The positive list names the cases the platform was built for: you want your own logo and branding on the launcher with your own news feed, you want to be able to update the modpack whenever you want, you do not want to depend on anyone else, there are several modpacks you want to provide as a set, and you want to provide hidden modpacks that are only accessible by a secret code. The last two are the ones that separate this from simply uploading a zip to CurseForge, because both need the author to stay involved after publication.

Drag and drop is the whole authoring story

Creating modpacks with this launcher is described as easy in three steps: only drag and drop of configs and mods into a folder, no scary XML or JSON files to edit, and a nice interface for creating modpacks, with a command line also available. The folder structure is small enough to hold in your head, with the config, mods and resource packs directories living under src/ and the mod loaders in a separate loaders folder:

* src/**config**/
* src/**mods**/
* src/**resourcepacks**/
* loaders/

LiteLoader and Forge installers, or the Fabric Loader, go into the loaders folder. Alongside the src/ tree the launcher supports LiteLoader, Forge, Fabric and custom jar mods, and the README notes you can put resource packs in, or really even random mod files that do not go in the configs or mods folder. That last allowance matters for the creator-tools workflow, because it means the pack definition is a folder of files rather than a manifest with a schema, so a mod author who hands you a loose jar can be included without a repackaging step. The trade-off is that nothing validates the arrangement for you, so a mistyped loader or a mismatched version is discovered by the player rather than by the creator.

Downloads that resume, updates that are incremental

The launcher has the features you would expect from a distribution platform, and the README names three of them specifically. Resume of incomplete downloads means a player who loses connection mid-download does not start over, which matters because modpacks are often hundreds of megabytes and the players who install them are the least technical audience you will ever have. Incremental updates means shipping a new version of the pack transfers only what changed, rather than the whole pack again. File deduplication saves disk space when you have files duplicated between updates or modpacks, and since the launcher supports several modpacks as a set, the same library appearing in three packs is stored once. That third feature is the one that becomes more valuable the more packs you publish, and it is the reason the storage model is worth understanding if you are planning a catalogue rather than a single release. The README also notes that the launcher can update itself, that there is a portable mode, and that there is a dark version of the launcher alongside the light theme.

Optional features let players assemble their own variant

Users can select optional mods and features, and the README has a screenshot of that screen, which tells you the model is a base pack plus a set of choices rather than one fixed artifact. For a modpack author this is the difference between a single experience and a family of them, and it changes how you think about the content you ship. If the optional pieces are genuinely optional, you can add a heavier mod to one variant without making it a requirement for everyone, and the player decides. The same mechanism is what makes a secret code for hidden packs a reasonable feature rather than an odd one, since a hidden pack is a different set of choices for the same underlying content. The launcher carries its own configuration screens for options and a console view for logs, and the pack manager and modpack creator tools are separate graphical utilities from the launcher itself, which is why the repository has a creator-tools/ directory alongside launcher/.

Generating packs from version control

For the technically inclined, the README describes a path that removes the manual step entirely. You can generate modpacks from Git, or any VCS, using your favourite continuous integration server, and then dynamically create modpacks even down to one per branch or tag. The mechanism follows from how the format works. Because a pack is a folder of files rather than a compiled artifact, a continuous integration job can assemble it from a repository at any commit and publish the result, and the launcher can point at whatever is current. One pack per branch or per tag is a natural extension of that, and it is the feature that turns the launcher from a one-off installer into something you can run continuously. The prerequisite is the one the README states plainly: you do need some sort of website, but it does not need anything complicated like PHP. That is a real constraint on the audience, since people who cannot run a web server are the people who most want a simple way to share a modpack.

Java conventions, dual licensing and the build

The contributing section is brief and has two conditions. Pull requests can be submitted on GitHub, but they will be accepted at the discretion of the maintainers, and the code must follow Oracle's Java Code Conventions. The second condition is the licensing one, and it applies specifically to third party contributions: those must be dual licensed under the two licenses described in LICENSE.txt, the GNU Lesser General Public License version 3 and the 3-clause BSD license. The launcher itself is licensed under the LGPL version 3, which is the weak copyleft choice, so a launcher distributed as a binary to players does not oblige them to open source anything, while modifications to the launcher itself stay open. The repository layout shows how the project is put together, with launcher/ for the application itself, launcher-bootstrap/ and launcher-builder/ as separate modules, launcher-fancy/ for the styled interface, creator-tools/ for the creator utilities, sample-files/ with files you can upload to your own site to test the flow, readme/ holding the images, and build.sh, build.bat, build.gradle, settings.gradle and the gradlew wrapper scripts for building. It is also described as Minecraft's oldest surviving modpack launcher platform, which is worth knowing because it means the format predates the current mod loaders and has been carried forward rather than reinvented.

Editorial conclusion

Adopt SKCraft Launcher when you publish several modpacks as a set, want your own branding and news feed, need update control, or want packs gated behind a secret code, and you can host files and accept running the distribution yourself. Do not adopt it to publish one modpack, because the README lists that case as one it may not be for, along with having no download site or not wanting to distribute a launcher. Verify first that you can host files and serve them over the web, that the launchers and mod versions your pack needs are supported, and that you read the dual licensing terms in LICENSE.txt before you contribute code.

Frequently asked questions

Official sources

1. Issues
2. README
3. SKCraft/Launcher on GitHub