LE

Leaf

Performance-focused Paper fork for Minecraft servers

Game Servers ★ 1.1k stars Medium setup GPL-3.0

Leaf is a performance-oriented fork of the Paper Minecraft server software, applying additional optimizations and patches. It is a drop-in replacement aimed at large self-hosted Minecraft servers.

Key features

  • Optimized Paper fork
  • Drop-in replacement
  • Extra performance patches
  • Plugin compatibility

Pros & cons

Strengths

  • Good performance gains
  • Easy migration

Trade-offs

  • Newer project
  • Same Java requirements

Leaf replaces

Last reviewed Sep 13, 2026 · 829 words

Leaf earns its place in one situation: you already run Paper, the server dips below 20 TPS with your player count, and you have exhausted the cheap fixes. Then swapping the jar for Leaf can buy back a meaningful chunk of that headroom through patches Paper will not merge because they change vanilla behaviour in small ways. For everyone else, Paper remains the safe pick, and I would not start a new server on a 2023-vintage fork with 1,077 stars when the parent has a decade of stability and every plugin tested against it.

What Leaf changes relative to Paper

Leaf carries its own patch set on top of Paper's, drawing on the same lineage as Gale and Pufferfish, the earlier performance forks. The headline items are asynchronous mob spawning and pathfinding (entity AI decisions move off the main thread), a multithreaded entity tracker so a crowded spawn area costs less per tick, and options to trim redundant work in chunk ticking and redstone. Each of these is individually small; together on a server with 60 players and a few hundred mobs per player they add up.

The trade is that some of this is not strictly vanilla. Mobs may path a fraction of a tick later, entity activation ranges are tuned, and a few of the optional toggles change mechanics that technical players notice. A survival server for friends will never see it. A redstone-heavy technical server might, and those admins tend to stay on Paper or even vanilla.

The swap is genuinely drop-in

Migration is the reason to try it rather than fear it. Stop the server, back up the directory, replace paper.jar with the Leaf jar for the same Minecraft version, and start. Worlds, bukkit.yml, spigot.yml, Paper's config folder and the plugins folder all carry over unchanged, because Leaf is Paper underneath. It adds its own config file alongside Paper's for the extra toggles, with defaults chosen to be safe. Plugin compatibility is the same as Paper's in practice; the rare exceptions are plugins that reach into internals the async patches touch, and those break loudly at startup rather than subtly.

Going back is the same operation in reverse, which makes it a cheap experiment. Do it on a copy of the world first if the server has an audience.

Where the gains come from, and where they do not

Before switching, measure. Run Paper's built-in /spark profiler or /timings for an hour of peak play and look at what is eating the tick. If it is entity work (mob AI, tracking, collisions), Leaf's patches target exactly that and the improvement can be substantial. If it is a plugin doing synchronous database calls, a world with 40,000 hoppers, or a 2 GB heap for 50 players, Leaf will not save you, and fixing the actual cause will. Same Java requirements as Paper, meaning Java 21 for current versions and the memory the catalogue lists as a floor rather than a target.

Purpur is the other fork people weigh, and it is a different animal: it stacks gameplay features and configurability on Paper rather than performance patches, and it is the older and larger project. If you want both, Leaf is often run as the base with Purpur-style features left out.

Risks of a younger fork

Three honest ones. Leaf tracks Minecraft releases quickly but not instantly, so on update day you may wait for the fork while Paper is already out. The project is small, and a performance fork that stops updating leaves you migrating back to Paper, which is easy but still a chore. And the patches are the kind that occasionally introduce edge-case bugs (a mob that stops moving, a farm that behaves differently) that the wider Paper user base would have caught sooner. Read the release notes, keep the previous jar, and update a day or two after release rather than the hour of.

None of this is a mark against the project; it is the cost of being at the front of the optimisation curve. The panels most people use, PufferPanel and its bigger siblings, treat it as just another jar, so operationally it costs nothing extra.

What I'd do

New server or under 30 players: run Paper and stop reading. Existing Paper server that is entity-bound at peak, confirmed with a profiler: back up, swap in the Leaf jar for your version, leave every toggle at default for a week, and compare the same profiler numbers. Keep it if the TPS graph is visibly better and nothing broke. Two forks I would not bother with are anything unmaintained and anything that claims to double your player count; Leaf does not claim that, which is part of why I trust it as the vanilla server replacement for busy servers.

Compare Leaf

2 head-to-head comparisons.

Similar game servers apps