Folia vs Leaf: Choose by Workload and Plugin Compatibility
Last reviewed August 29, 2026. Folia and Leaf are both downstream of the Paper ecosystem, but they solve different problems. Folia splits loaded worlds into independently ticking regions. Leaf is a performance-oriented Paper fork that aims to retain Paper plugin compatibility. Neither is automatically faster for every server.
Short answer
- Choose Paper or a Paper-compatible fork such as Leaf when normal Paper plugin compatibility is the first requirement.
- Evaluate Folia when a sizeable player population is naturally spread across independent areas and every critical plugin explicitly supports Folia.
- Stay on the current software when you have no measured bottleneck. Changing forks adds migration and compatibility risk.
What Folia changes
PaperMC's Folia architecture overview explains that loaded chunks are grouped into regions that tick independently and in parallel. Nearby activity can merge into one region, while separated areas can tick on different region threads. This can help a large SMP or island-style server where players are dispersed; it does not make a single crowded spawn or one overloaded redstone area parallel.
Folia changes thread ownership and scheduling. A plugin cannot safely assume there is one global main thread. PaperMC's plugin support guide requires an explicit folia-supported: true marker and warns that adding the marker alone does not make a plugin safe. Developers must use Folia's region, entity, async, and global schedulers correctly.
What Leaf changes
Leaf describes itself as a high-performance Paper fork and states in its official FAQ that it has Paper-equivalent plugin compatibility and includes Purpur patches. Its optimizations and configuration can change between releases, so use its current documentation rather than copying old flags or invented benchmark claims.
Paper compatibility is not a guarantee that every plugin and fork combination is bug-free. If a plugin fails on Leaf, reproduce the issue on current Paper or Purpur before blaming the plugin or the fork. Keep a rollback copy of the world and configuration when moving between implementations.
Side-by-side
| Question | Folia | Leaf |
|---|---|---|
| Tick model | Independent regions can tick in parallel. | Paper-style server model with additional performance patches. |
| Best candidate workload | Many players spread across distant regions or islands. | Typical Paper/Purpur communities seeking Paper-compatible tuning. |
| Plugin requirement | Every critical plugin must explicitly support Folia and its schedulers. | Targets normal Paper plugin compatibility; test exact versions. |
| Hardware | Benefits from many real cores; PaperMC's FAQ recommends at least 16 cores for suitable large workloads. | Still benefits strongly from fast per-core performance, with enough memory and storage for the workload. |
| Crowded single location | Limited parallel benefit when nearby activity belongs to one region. | Conventional choice; profile the hot region and plugins. |
| Migration risk | High when plugins are not Folia-aware. | Lower for Paper stacks, but fork-specific settings still need testing. |
When Folia is a reasonable test
PaperMC's Folia FAQ names spread-out skyblock and SMP workloads with a sizeable player count as candidates. It also recommends pre-generating the world and treats thread-allocation examples as rough starting points that must be tuned from observed utilization. There is no honest universal “players per core” promise.
Do not choose Folia because a host advertises a very high maximum player count. Build a plugin inventory first. Permissions, protection, economy, maps, NPCs, world editing, minigames, and custom plugins all need explicit support. One unsupported critical plugin can eliminate the operational benefit.
Safe migration test
- Download the world, configuration, and plugin data. Keep the original server untouched.
- List every plugin and confirm Folia support in the plugin's own current documentation. A third-party compatibility list is only a discovery aid.
- Start a clone with the target server build and required Java runtime.
- Test login, permissions, claims, teleports, portals, scheduled tasks, economy transactions, maps, world edits, shutdown, and restart.
- Spread test players across separate regions and profile actual tick-thread utilization. Also test the busiest shared location.
- Run at least one backup and restore on the clone.
- Schedule the production migration with a rollback window; keep the source files until the new instance has completed clean saves under real load.
Do not paste mystery JVM flags
Flags copied from an unrelated Java or Minecraft version can waste memory or prevent startup. Match the runtime to the server jar—Minecraft Java 26.1 requires Java 25—and begin with the server project's documented defaults. Change one measurable variable at a time. Use a profiler such as spark to identify plugins, entities, chunk generation, or regions that actually consume tick time.
Related guides
- Minecraft server software: vanilla, Paper, Fabric, and Forge
- Choose server plugins and verify compatibility
- Pre-generate worlds with Chunky
- Profile server lag with spark
- Choose Java 21 or Java 25 for the server jar
Compare Supercraft Minecraft Java plans if you want managed file access, backups, and supported server-software choices. Confirm the current panel options and plugin compatibility before selecting Folia or any Paper fork.