Folia: How Regionalized Multithreading Transforms Your Server

If you're running a large Minecraft server and watching your TPS crater whenever someone explores new chunks or you hit peak player count, Folia might be the answer you've been looking for. And this Paper-based fork completely reimagines how Minecraft servers handle computation by splitting the world into independent regions, each running on its own thread. Instead of one main thread struggling to keep up with everything at once, Folia lets your CPU cores actually do parallel work.

What Folia Actually Is

Folia isn't a mod. It's not a plugin. It's a from-the-ground-up rewrite of the Paper server that removes the concept of a main thread entirely. Instead, nearby chunks get grouped into "regions," and each region runs its own tick loop on the thread pool. Think of it as giving different parts of your world their own independent processor rather than forcing one thread to micromanage everything.

The architecture matters because it changes how your server scales.

Paper handles millions of players' servers well within its single-threaded design, but once you get to that next tier of scale - hundreds of players spread across a huge world - bottlenecks emerge. Folia doesn't try to squeeze more out of a single thread. Instead, it fundamentally changes the problem.

Why You'd Actually Want This

Large spread-out servers benefit most. Skyblock networks where players have floating islands scattered across dimensions, massive survival worlds, custom RPG servers with distributed dungeons - these are where Folia shines. If your players cluster in one spawn area, you won't see the same performance gains. But for a 200+ player SMP where people are exploring in different quadrants, the difference is substantial.

I should mention upfront: this isn't a drop-in replacement.

Your plugins need to be rewritten for Folia's multithreaded environment. That's the real cost. But if you're at the scale where you're considering it, your plugin ecosystem is probably custom anyway. Standard Paper plugins that don't assume a main thread will break immediately under Folia.

The payoff is genuine though. With proper configuration, you're looking at actual performance improvements that scale with your CPU core count. That's not achievable on standard Paper.

Installation and Basic Setup

First, grab the latest build from the PaperMC downloads page. As of 2026, Folia supports modern Minecraft versions (1.20.4 and later). Download the jar file to your server directory:

wget https://api.papermc.io/v2/projects/folia/versions/latest/builds/latest/downloads/folia-latest.jar
mv folia-latest.jar folia.jar

Next, you'll need to accept the EULA in your eula.txt file. Boot the server once to generate your config files:

java -Xmx30G -Xms30G -jar folia.jar nogui

Stop it (it'll create the folia.yml config), then you enter the actual work: thread configuration. This isn't just "set more threads and go." The PaperMC documentation recommends pre-generating your world before moving to production, which reduces chunk loading overhead significantly.

Thread Configuration: The Real Challenge

This is where most people get confused. Your folia.yml has a `threaded-regions.threads` setting. Don't just max it out. The guideline from the project itself: allocate threads for netty IO (about 4 per 200-300 players), chunk system IO threads (about 3 per 200-300 players), chunk system workers if pre-generated (about 2 per 200-300 players), and then use the remaining cores up to 80% total allocation for tick threads.

On a machine with 32 cores serving 500 players, you'd roughly allocate:

• Netty IO: 8 threads
• Chunk system IO: 6 threads
• Chunk system workers: 4 threads
• Tick threads: remaining cores up to 80% (about 10 threads)

You don't leave 100% allocation because plugins and unexpected background tasks will spawn their own threads and crash the server. The 80% ceiling is a safety boundary that actually matters.

Even then, this is a starting point. Monitor your actual thread usage under load and adjust. The folia.yml file has detailed comments for every option.

Key Features That Actually Work

Region isolation. Each region ticks independently at 20 TPS. A lag spike in one region doesn't cascade to others. If your dungeon system is poorly optimized, it won't tank your spawn area's performance.

Proper thread scaling. Unlike Paper's plugin-threadpool approach (which still bottlenecks on tick-critical operations), Folia's regions run tick logic in parallel. More cores actually translates to more tick processing. The scaling isn't linear, but it's real.

Async chunk loading. Chunk I/O happens off the region threads. You won't get the random freezes that single-threaded servers experience when storage reads spike.

There's also native support for server-side chunk optimization, pre-generated chunk caching, and configurable memory limits per region. Honestly, the feature depth is impressive if you're willing to dig into the documentation.

What Will Break and How to Handle It

Most plugins assume they're on a main thread and that they can read/write world state safely without synchronization. They're wrong on Folia. If a plugin does something like "check if block X is stone, then set it to air," that race condition might happen across threads in a way it never would on Paper. Expect plugin failures.

Some specifics:

• Teleportation between regions involves additional complexity and can cause deadlocks if plugins aren't careful
• World border checks are region-aware and might behave differently than you expect
• Timers and scheduled tasks need to be region-safe to avoid corruption
• Entity tracking across region boundaries requires plugin updates

The Folia docs list incompatible patterns explicitly. If you're evaluating plugins for compatibility, check whether they directly manipulate tick logic or assume single-threaded access to chunk data.

When Folia Makes Sense

You've got a 16+ core machine. Your server's going to hit 200+ concurrent players regularly. Your players are geographically spread out (not all at spawn). You either have custom plugin infrastructure or you're willing to port existing plugins.

Those four conditions? You're a candidate.

You're running 50 players on a VPS with 8 cores? Stick with Paper. The gains won't justify the compatibility headache. You're running a 100-player SMP where everyone hangs at spawn? Folia helps, but not as dramatically as it would on a sprawled server.

But if you're building the next generation of serious multiplayer Minecraft communities, Folia is where the performance ceiling is actually higher. The players at skins like adderall_abuser's, ironmouse's, and other active community members on massive servers are already exploring this space. Check out streaming communities and large survival projects on Modrinth - you'll see Folia appearing more often.

Alternatives Worth Considering

Paper. Still the gold standard for most servers. Stable, well-understood, enormous plugin ecosystem. If Folia feels like overkill, Paper's optimization features (async chunk loading, reduced entity AI ticks, etc.) might be enough.

Purpur. A Paper fork with additional per-player optimizations. Better for servers where player experience varies wildly (some AFK, some actively exploring). Less architecture change than Folia, more targeted performance gains.

Fabric Server. If you need mod support (not plugins), the Fabric ecosystem is actually pretty solid for servers now. Not multithreaded in the same way, but lightweight and fast.

The honest truth: Folia is specialized. It's for a specific problem at a specific scale. For everyone else, Paper with thoughtful configuration is still the right choice.