Leaves is a Paper fork whose goal is to put vanilla behaviour back

The pitch is a fork that undoes Paper's patches

Leaves describes itself in one line as a fork of Paper aimed at repairing broken vanilla properties. That is a precise positioning, because Paper is itself a fork of Spigot, which is a fork of CraftBukkit, and each generation has changed vanilla behaviour in the name of consistency or performance. Leaves takes the opposite direction on that axis. Instead of continuing to layer on modifications, it works to restore the behaviour the original game had, and the README points to a configuration reference at docs.leavesmc.org where you can see what the project modifies and fixes. That reference is the interesting part of the design, because it implies the changes are exposed as configuration rather than baked into the server binary. The audience is Minecraft server operators who have to choose between upstream Paper and something that behaves closer to the vanilla client, and plugin developers who need to know whether the APIs they rely on still work in a fork that changes server side behaviour.

The paperclip jar system carries over unchanged

Operationally, Leaves does not ask administrators to learn a new deployment model. The README states that Leaves uses the same leavesclip, a paperclip fork, jar system that Paper uses. In practice that means the distribution model people already know applies: you grab the latest 1.21.x build from the releases page, run it, and the server bootstraps the rest of the pieces it needs. The repository layout matches that model, with leaves-server/ holding the server implementation and leaves-api/ holding the API module, plus build.gradle.kts, settings.gradle.kts and gradle.properties at the root for the multi module Gradle build. There is also a build-data/ directory, a scripts/ directory and a docs/ directory, and the documentation reference for the configuration lives under docs/CONTRIBUTING.md for contributions while the user facing configuration reference is published on the documentation site. The whole tree is a Java project built with Gradle wrappers, gradlew and gradlew.bat, which is the standard shape for this family of server forks.

Building from source with two Gradle tasks

Building is two commands, and the prerequisites are stated plainly: you need JDK 21 and good Internet conditions. The Internet requirement is not incidental, because the build applies patches against upstream sources rather than compiling a self contained tree. The README instructs you to clone the repo, run ./gradlew applyAllPatches, and then run ./gradlew createMojmapLeavesclipJar, and the resulting jars appear in the leaves-server/build/libs directory:

./gradlew applyAllPatches
./gradlew createMojmapLeavesclipJar

The task name is worth reading carefully. createMojmapLeavesclipJar tells you two things: the output is a Mojmap named paperclip style jar, and the jar follows the leavesclip convention. The Mojang mapping name is a deliberate choice in this ecosystem, since it keeps the jar compatible with the mapping most plugin and server tooling expects. For an administrator this section only matters if you intend to modify the server, but for anyone who wants to understand what a fork actually changes, building it is how you get the source in a state where the patches are applied and visible.

Plugin developers have to build the API themselves

This is the part of the README that will stop a plugin developer in their tracks, and it is stated without softening. You can use Leaves as a dependency only if you build it yourself, and each time you want to update that dependency you must re-build Leaves. The dependency coordinates are published for both modules, and the API artifact comes from the project's own snapshot repository:

maven {
    name = "leavesmc-repo"
    url = "https://repo.leavesmc.org/snapshots/"
}

dependencies {
    compileOnly("org.leavesmc.leaves:leaves-api:1.21.10-R0.1-SNAPSHOT")
}

The server artifact is referenced the same way under the leaves coordinate:

dependencies {
    compileOnly("org.leavesmc.leaves:leaves:1.21.10-R0.1-SNAPSHOT")
}

So a repository entry and a snapshot repository are both needed, but the snapshot dependency alone does not remove the build requirement, because the snapshot repository does not necessarily hold a build matching your local tree and the README asks you to rebuild on each update. The practical workflow for a plugin author is therefore to build Leaves locally, point the dependency at your build, and repeat that whenever you bump the server version. Note also that the example coordinates are for a 1.21.10 snapshot while the published server builds are listed as 1.21.11, which is a reminder to check the version you are actually consuming.

Where Leaves differs from running Paper directly

The comparison to make is not abstract. Both servers run the same plugin ecosystem, both use a paperclip style launcher, and both are Java projects built on the CraftBukkit and Spigot lineage, so the day to day administration of plugins, worlds and permissions is comparable. The difference is what the fork does to the game itself and how it exposes that. Leaves aims at repairing broken vanilla properties and publishes a reference of what it modifies and fixes, which is documentation a server owner can consult before changing a setting. Paper, by contrast, is the base that Leaves diverges from, and its own configuration governs the behaviour Paper introduced. So the choice is not between a better and a worse server, it is between a fork that continues to change vanilla behaviour and one whose stated goal is to put it back, with the operational risk that a fork which changes server side mechanics can behave differently from the vanilla game your players know.

Version numbering, release cadence and the licence question

The releases tell you how this project tracks Minecraft. The tagged builds are named for the Minecraft version plus a build counter and a short commit hash, for example Leaves-1.21.11-157-a8bb272 dated 2026-08-13, preceded by 1.21.11-156-d3ab8e2 on 2026-07-20 and 1.21.11-155-8278a37 on the same day. That naming scheme means the Minecraft version is the first thing to read, and the build number tells you how many builds have been made for that Minecraft release. The last push to the repository was on 2026-08-13 and the repository is not archived. The licensing is where an adopter needs to slow down. The licence is a custom one that GitHub cannot classify, with LICENSE.md at the root and a licenses/ directory in the tree, which in a fork that vendors upstream code is a sign that the licensing terms of Paper, Spigot, CraftBukkit and Minecraft itself all matter. Read LICENSE.md and the licenses/ directory rather than assuming an open source grant, and treat that as a question for your own counsel rather than something this article can settle.

Editorial conclusion

Leaves suits a server administrator who wants Paper's plugin ecosystem with vanilla game behaviour restored, and who can accept building the plugin API from source. It is a poor fit for a plugin author who wants a published dependency, because the README states that using Leaves as a dependency requires building it yourself and re-building on every update. Verify first which Leaves build matches your Minecraft version on the releases page, check the configuration reference at docs.leavesmc.org to see which behaviour a given setting changes, and read LICENSE.md, since the licence is a custom one that GitHub cannot classify and the repository also carries a licenses/ directory.

Frequently asked questions

Official sources

1. Issues
2. LeavesMC/Leaves on GitHub
3. Project website
4. README
5. Releases