Fabric server performance mods: Lithium, C2ME

A Fabric server can run noticeably cheaper than vanilla with a short list of server-side mods, and players need nothing installed to join it. The core set is Lithium for game logic, FerriteCore for memory, Krypton for networking and ModernFix for startup and general fixes - all four aim to change nothing a player can see. C2ME parallelises chunk generation and is the most powerful and the least conservative. Add spark to measure, Chunky to pre-generate, and stop there until the profiler tells you otherwise. What these mods do not do is change vanilla rules the way Paper does, which is exactly why technical players choose this route.

Why Fabric for performance at all#

Paper is the usual answer to "my server is slow", and for a plugin server it is the right one. But Paper gets part of its speed by changing behaviour: it fixes dupes, alters entity activation, changes how some redstone and hopper edge cases resolve, and offers settings that deliberately trade accuracy for tick time. For a community server that is a good deal. For a technical survival server whose players build tick-perfect farms from videos made in vanilla, it is a steady trickle of "this works in single-player but not here".

The Fabric route keeps the vanilla server and replaces its slow parts underneath. The guiding rule of the main performance mods is that the game must behave identically; they rewrite how something is computed, not what the result is. The trade-off is that you lose the plugin ecosystem - Fabric does not load Bukkit plugins - and you gain a server that matches single-player behaviour while running far cheaper than vanilla. Paper, Fabric or vanilla covers that choice in general; this post is about doing the Fabric side well.

One more advantage: none of the mods below need to be on the client. A Fabric server with only server-side mods accepts unmodified vanilla clients, so your players keep using whatever launcher they already have.

Setting up the Fabric server#

Fabric publishes a single executable launcher jar for servers on its website. You choose the Minecraft version, the loader version and the installer version, and download one file. On first start it fetches the vanilla server jar and the libraries it needs, then starts.

$ java -Xms4G -Xmx4G -jar fabric-server-mc.1.21.1-loader.0.16.5-launcher.1.0.1.jar nogui

The version numbers in that file name are only an example - take the current ones from the Fabric site for your Minecraft version. The first boot writes eula.txt; set eula=true and start again. After that you have the usual vanilla layout - one world folder with the Nether and the End inside it, server.properties, logs/ - plus a mods/ folder and a config/ folder that fills as mods create their settings.

Two rules for the mods/ folder:

• Match the Minecraft version exactly. A mod built for 1.21.1 will not necessarily load on 1.21.4. Mod pages list a file per version; take the one that matches.
• Check dependencies. Most Fabric mods depend on Fabric API, which is a separate mod you also put in mods/. A few performance mods, Lithium among them, deliberately do not. Each mod's page lists what it needs, and Fabric's error message on a missing dependency is clear about which one.

On a panel host you upload the launcher jar and the mods through the file manager or SFTP and set the jar name on the startup settings. On RE:NODE the Minecraft line ships Paper, so a Fabric server is your own install: upload the launcher, point the Startup tab at it, and the panel runs it like any other jar. There is no whitelist of allowed mods, and equally no one-click Fabric switch.

The core four#

These are the mods that almost every performance-minded Fabric server runs, and they are designed to coexist.

Lithium is the big one. It rewrites hot paths throughout the server - mob pathfinding, entity collision checks, hopper and block entity ticking, chunk and block access, the random tick, explosion calculations - with the explicit goal of producing identical results. It is configured with config/lithium.properties, which starts empty. Every optimisation is a mixin you can disable individually if you ever find a behaviour difference:

# Disable one optimisation group if you suspect itmixin.ai.pathing=false

You should rarely need that file. Its existence is mostly useful for bisecting: if a contraption behaves differently than in single-player, turning off groups one at a time tells you whether Lithium is involved, and the project wants to hear about it if so.

FerriteCore reduces the memory Minecraft uses to represent block states and related data by deduplicating structures the game creates many copies of. On a vanilla server the saving is modest; on a modded server with thousands of blocks and block states it can be large. It has its own mixin configuration file in config/ with the same opt-out pattern.

Krypton replaces parts of the networking stack with faster implementations, including the native compression and encryption code from the Velocity proxy project. The gain grows with player count: at five players you will not see it, at fifty you might. It changes nothing about game behaviour.

ModernFix started as a collection of fixes for slow modpack startup and grew into a general-purpose mod that cuts memory use and load times on Fabric and NeoForge. On a lightly modded server it mostly shortens the boot. Its options are in config/modernfix-mixins.properties, and the defaults are sensible.

C2ME and chunk work#

Chunk generation is the most expensive thing a Minecraft server does, and vanilla does much of it with limited parallelism. C2ME (Concurrent Chunk Management Engine) parallelises chunk generation, loading and saving across cores. On a server where players explore new terrain, or during a pre-generation run, it can make a large difference.

It is also the mod on this list most likely to cause trouble:

• It changes threading inside world generation, which is code that mods and datapacks assume runs a certain way. Worldgen mods and complex worldgen datapacks are the usual conflicts.
• Its benefit scales with cores. On an allocation of one or two vCPUs there is little to parallelise across, and C2ME can compete with the main thread for the same small share.
• Its configuration, in config/c2me.toml, has options for thread counts and for individual features. The defaults try to be safe; changing them is for after you have measured.

The test for C2ME is straightforward: take a copy of the world, pre-generate a fixed area with and without it, compare the time and the MSPT during the run, and walk the boundaries of the generated area looking for anything odd. If you pre-generate the whole world once and then keep a border, C2ME's ongoing value drops sharply, and many servers use it only during the pre-generation phase. World borders and pre-generation has the Chunky commands, which work the same on Fabric.

Lighting is the other chunk-heavy job. The Starlight mod used to be the standard fix, then Mojang rewrote the vanilla light engine and Starlight stopped being needed for new versions. ScalableLux continues the idea on recent Fabric versions. Treat it like C2ME: useful during heavy generation, and something to test rather than assume.

Mods that change behaviour, and when they are worth it#

The core four keep vanilla behaviour. The next group deliberately does not, and each is worth it only when you know which problem it solves.

ServerCore brings Paper-style controls to Fabric: entity activation ranges, a dynamic view and simulation distance that drops when MSPT climbs, adjustable mob caps and chunk-ticking limits. It is the closest thing to Paper's configuration on Fabric, and it changes vanilla behaviour in the same ways Paper does. Use it if you want vanilla-compatible mods but Paper-like protection against overload.

VMP (Very Many Players) targets servers with high player counts: entity tracking, chunk sending and related work that scales per player. It matters at dozens of players, not at five.

Alternate Current replaces the vanilla redstone dust update algorithm with a much cheaper one. Redstone dust in vanilla fires an enormous number of redundant block updates; Alternate Current produces the same powered states with far fewer. The update order differs, which can affect a contraption that depended on vanilla's update order. Most builds work; some tick-precise ones do not.

Clumps merges experience orbs into larger orbs, which stops boss and mob farms from filling an area with thousands of orb entities. The total experience is the same.

Carpet is not a performance mod as such, but technical servers run it for its profiling and control commands and its long list of optional rules. Every rule is off until you set it, so installing Carpet changes nothing by itself.

What does not belong on a server#

The most common Fabric performance mistake is installing client mods on the server because their names sound like performance.

• Sodium, Iris, ImmediatelyFast, Entity Culling and similar mods optimise rendering. A server renders nothing. At best they do nothing; at worst the server crashes on start with Cannot load class ... in environment type SERVER, which is Fabric telling you a client class was touched on a dedicated server.
• Shader and resource mods are the same category.
• "FPS boost" packs are client bundles. Read the list, take nothing.

The safe rule: if the mod page describes frames per second, it is a client mod. If it describes ticks, memory, chunks or network, it might be a server mod, and the page will say whether it is required on the client too. For the general split between server-only, client-only and both, see running a modded server without the crashes.

Measuring before and after#

A performance mod you cannot measure is a superstition. Install spark (it has a Fabric build) before anything else on this list, and take a baseline:

/spark tps/spark health/spark profiler start... play normally for five to ten minutes .../spark profiler stop

/spark tps shows TPS and MSPT over several windows; MSPT (milliseconds per tick) is the number that matters, because TPS sits at 20 right up until MSPT crosses 50. /spark health shows memory and CPU. The profiler produces a link to a flame graph showing where tick time went. On 1.20.3 and later, vanilla's /tick query gives you tick timing without any mod at all.

Compare like with like: same player count, same activity, same time of day. Then add one mod, restart, and profile again. Reading a spark report explains how to read the flame graph and where each category of lag shows up.

A few vanilla settings belong in the same pass, because they often matter more than any mod:

view-distance=8simulation-distance=6sync-chunk-writes=truenetwork-compression-threshold=256

view-distance and simulation-distance are the biggest levers on any server. sync-chunk-writes=false reduces stalls during saves at the cost of a slightly higher risk of chunk damage if the process is killed mid-write; leave it true unless the profiler shows saving is the problem. The heap and garbage collection settings are covered in JVM flags and Java versions, and they apply unchanged to Fabric.

On RE:NODE the console shows memory, CPU and disk graphs against your plan's actual limits, which is the other half of measurement: if the CPU graph is pinned at your share while MSPT is high, the tick is CPU-bound and the mods above are the right tools. If memory is near the limit instead, FerriteCore and a smaller view distance help, and remember that reaching the memory limit stops the container and restarts it clean rather than swapping.

A sensible starting list#

For a vanilla-feeling survival server on Fabric:

1. Fabric API (most other mods need it)
2. Lithium
3. FerriteCore
4. Krypton
5. ModernFix
6. spark
7. Chunky, for pre-generation, removed or idle once the world is generated
8. C2ME only if exploration or pre-generation is your measured bottleneck

That list keeps vanilla behaviour, needs nothing on the client, and leaves the server easy to update: when a new Minecraft version comes out, the core performance mods are usually among the first to update. Keep a copy of the working mods/ folder before every update, and do not update on release day. What to do when a mod update breaks is the plan for when one of them lags behind.

FAQ#

Do players need to install Lithium or the other mods?

No. Lithium, FerriteCore, Krypton, ModernFix, C2ME, spark and Chunky are server-side, and a Fabric server running only server-side mods accepts vanilla clients. Players may install Sodium or other client mods for their own frame rate, but the server does not care.

Is Fabric with Lithium faster than Paper?

It depends on what is slow, and they are not doing the same job. Paper changes behaviour and offers aggressive settings; Lithium keeps behaviour identical. A tuned Paper server can usually handle more load, while Fabric with Lithium is the choice when exact vanilla mechanics matter more than the last few milliseconds.

Can I use C2ME with Lithium?

Yes, they are commonly run together. Conflicts with C2ME usually come from worldgen mods and datapacks rather than from the other performance mods. Test on a copy of the world, especially before a pre-generation run.

Why does my Fabric server crash with "environment type SERVER"?

A client-only mod is in the server's mods/ folder and tried to load a class that exists only in the game client. Remove rendering, shader, HUD and interface mods from the server. The crash log names the mod that triggered it.

Do these mods work on Forge or NeoForge?

Some do. FerriteCore and ModernFix publish builds for both loaders. Lithium is Fabric-first, and the Forge lineage has ports of the same work under other names. Check each mod page for the loader and Minecraft version you run.