FoliaToGo: Getting Fresh Folia Builds Every Single Night

You've probably heard Folia is the future of Minecraft servers - parallel-processed chunks, better multi-core support, genuine performance improvements. Problem is, Paper won't release automated builds until Folia's "officially ready." FoliaToGo cuts through that wait by giving you freshly compiled Folia jars every midnight UTC, no strings attached.

What This Project Does

FoliaToGo automates what would otherwise be a manual, time-consuming process. The project runs a GitHub Actions workflow every night at midnight UTC that compiles the latest Folia source code and deposits the resulting.jar file where you can grab it. No compilation step on your end. No waiting for official releases. Just download and run.

With 104 stars on GitHub and written primarily in Shell script, it's a straightforward solution to a specific problem. The whole setup is elegantly simple because it just needs to do one thing well: automate the build and make it accessible.

Why Server Admins Want This

Folia's threading model is genuinely different from Paper. Instead of one thread handling all chunk updates, Folia distributes them across multiple CPU cores. On properly specced hardware, this shows up as real performance gains - especially at peak hours when TPS usually tanks.

But Folia's still experimental. Here's the thing, it gets updates constantly. Security patches, bug fixes, performance tweaks that could matter for your server.

You could wait six months for an official release. Or you could grab last night's build and get those improvements immediately. For public servers, that's the actual appeal - you're not sacrificing stability, you're just avoiding the wait.

Getting Started - The Easy Way

Easiest approach: download straight from GitHub. Head to the FoliaToGo Actions tab (there's a direct link in the README) and grab the latest successful build. It's just a.jar file - drop it in your server directory alongside Paper like you normally would.

java -Xmx30G -Xms30G -XX:+UseG1GC -XX:+ParallelRefProcEnabled \
 -XX:MaxGCPauseMillis=200 -XX:+UnlockExperimentalVMOptions \
 -XX:G1NewCollectionPercentage=30 -XX:G1MaxNewCollectionPercentage=40 \
 -XX:G1HeapRegionSize=8M -XX:G1HeapWastePercent=5 \
 -XX:G1MixedGCCountTarget=4 -XX:InitiatingHeapOccupancyPercent=15 \
 -XX:G1MixedGCLiveThresholdPercent=90 -XX:G1ReferenceProcessingThreads=4 \
 -XX:G1ReservePercent=10 -jar server.jar nogui

That's a solid JVM configuration for Folia. Adjust the Xmx and Xms values based on your available RAM - those 30G values are just an example.

If you want to build locally instead, clone the repository and run the build script:

git clone https://github.com/Slackadays/FoliaToGo
cd FoliaToGo
sh build.sh

One caveat: this doesn't work in Windows Command Prompt or PowerShell. You need bash - WSL2 on Windows, or a proper Unix environment. The build also takes time, depending on your hardware. You're compiling an entire server from source, not just downloading a pre-made jar.

Real Scenarios Where This Helps

You're running a survival server. 50 players, peak hours every night. Before Folia, you'd squeeze every optimization you could - plugin tweaks, code review, maybe hardware upgrades. With Folia, you're testing nightly builds in a staging environment and rolling a fresh compilation to production when you find improvements. You get performance gains that wouldn't be possible otherwise.

Or you're a plugin developer testing against the absolute latest Folia code. Official releases could be weeks away. FoliaToGo means you test against last night's build and catch API changes immediately.

If you're working with custom chat messages or commands, the Minecraft Text Generator can help format those properly. Similarly, if you're building terrain-heavy servers or creating custom terrain generation plugins, the Minecraft Block Search tool is handy for cross-referencing block properties while you're developing.

The Gotchas That'll Catch You

Folia isn't a drop-in Paper replacement. Some plugins won't work. Anything assuming single-threaded behavior will break. You can't just swap the jar and expect everything to work.

The builds run on schedule. If there's a critical security fix pushed to Folia at 3 AM UTC, your next automated build arrives 21 hours later at midnight UTC. For production servers, that gap might matter.

Here's something I learned the hard way: Folia moves fast. A build from three weeks ago might be incompatible with current code. You can't sit on an old build indefinitely. Updates matter, and skipping builds could leave you behind.

Also check plugin support explicitly. Some frameworks handle Folia gracefully. Others don't. Know before you deploy.

Should You Use This

Running a small vanilla server for friends? Probably not worth the complexity.

Running anything that needs to squeeze performance out of every available CPU cycle? Worth investigating seriously. The threading model is genuinely different, and on the right hardware, it shows.

Plugin-heavy server? Test extensively first. Your mileage will vary dramatically depending on which plugins you run.

The project itself is rock solid - it's automated builds of stable upstream code. That risk is Folia itself, which is experimental by design. That's actually a feature. You get bleeding-edge improvements faster than waiting for official "ready" status.