Running a modded Minecraft server without the crashes

A vanilla server that falls over is almost always out of memory. A modpack that falls over could be out of memory, missing a dependency, running the wrong Java, holding a client-only mod it should never have seen, or two mods arguing over the same method. The fix is not more RAM. The fix is reading which of those five happened, and the server tells you in the first twenty lines of the log - if you know where to look and which loader you are on. This post covers installing a pack on a dedicated server, the Java version matrix that catches everybody, how to read a crash report backwards, and the handful of settings and mods that account for most of the rest.

Forge, NeoForge and Fabric, and which crashes belong to which#

Three loaders, one job: get code that is not Minecraft to run inside Minecraft. They fail differently enough that the loader is the first thing to establish.

• Forge is the oldest and still what most large 1.12 and 1.16 packs are built on. From 1.17 onwards the installer no longer produces a single runnable jar; it writes a libraries/ tree, a run.sh, a run.bat and a user_jvm_args.txt, and the start command is the script rather than java -jar.
• NeoForge is a fork of Forge that began at 1.20.1 and is where most new Forge-lineage packs live from 1.20.2 onwards. Same installer pattern, same file layout, different Maven coordinates. A mod for Forge 1.20.1 usually will not load on NeoForge 1.21 without a rebuild.
• Fabric is lighter, updates to new Minecraft versions within days rather than months, and expects almost every mod to depend on the separate Fabric API mod. Fabric's own failures are usually blunt and readable; Forge's are usually a stack trace.

The practical difference for a server operator is version cadence. Fabric packs follow the game closely, which means your server is rarely stuck on an old version but your mods update often. Forge and NeoForge packs lag, which means the pack is stable for months and then one update moves everything at once. Paper, Fabric or vanilla covers the choice itself; this post assumes you have already made it and something is on fire.

Getting the pack onto the server#

A modpack is not an install button. A server needs the pack's server files, which are not the same download as the client pack. Three routes, in order of how much work they are:

1. The pack publishes a server pack. Most large CurseForge packs do. It is a zip containing mods/, config/, sometimes kubejs/ or scripts/, and a start script. Upload it, unpack it in place, and set your start command to match what the script does.
2. The pack is a manifest only. A Modrinth .mrpack is a zip whose modrinth.index.json lists download URLs rather than the files themselves. Unpack it and resolve the list, either by hand or with one of the community tools that reads the index and builds a server folder.
3. You build the pack yourself. Install the loader, then add mods one at a time. Slower, but you end up knowing what every jar in the folder is for, which is worth a great deal the first time something breaks.

Installing the loader itself, on your own machine:

# Forge / NeoForge - writes run.sh, libraries/ and user_jvm_args.txt$ java -jar forge-1.20.1-47.3.0-installer.jar --installServer# Fabric - writes a launch jar and downloads the vanilla server jar$ java -jar fabric-installer-1.0.1.jar server -mcversion 1.21.1 -downloadMinecraft

After that the layout is the same on every loader: mods/ holds the jars, config/ holds their settings after the first start, logs/latest.log and logs/debug.log hold the evidence, and crash-reports/ holds the post-mortems.

On a panel-based host you upload all of that through the file manager or over SFTP - SFTP and the file manager has the connection details, and a pack of 200 mods is much faster dragged in as one archive and unpacked in place than as 200 separate uploads. Be honest with yourself about what the host does and does not do here: the Minecraft line on RE:NODE ships Paper with a matching Java, and a modpack is something you put on it yourself. There is no one-click modpack installer and no integration with any mod site; the files are yours to upload and the startup variables are yours to set.

Java version is not a detail#

Modpacks pin Java far more tightly than vanilla does, and the error when you get it wrong is unmistakable once you have seen it once:

java.lang.UnsupportedClassVersionError: com/example/Mod has been compiled by amore recent version of the Java Runtime (class file version 61.0), this versionof the Java Runtime only recognizes class file versions up to 52.0

Class file version 52 is Java 8, 61 is Java 17 and 65 is Java 21. That message means the pack wants newer Java than it is running on. The reverse - a 1.12 pack started on Java 17 - usually fails earlier and messier, with reflection errors about inaccessible internal packages rather than a clean version complaint.

Two rules that save whole evenings. First, match the pack's stated Java exactly rather than "something newer" - Forge 1.16.5 and older genuinely will not start on Java 17. Second, changing Java is a restart, not a reinstall, so it is the cheapest thing to rule out. On a panel the version is a startup variable; on your own box it is which java is on the path. JVM flags and Java versions has the flag sets that go with each.

Read the crash report, not the last line#

The last line of a crash is the symptom. The cause is above it, in the first frame of the stack that names something other than net.minecraft. Scroll up until you find a package that belongs to a mod; that mod is where to start. Older Forge reports print a Suspected Mods field and are often right about it. Modern Forge and NeoForge reports list every mod under -- System Details -- instead, and Fabric prints a Fabric Mods: block, so the stack trace is the only thing that narrows it down.

That last row is worth its own paragraph. Rendering mods - Sodium, Iris, OptiFine, Embeddium, Rubidium, Oculus, minimaps, shader loaders - have no server side at all, and a dedicated server that loads one dies reaching for a class that only exists in the client jar. When you copy a client pack's mods folder onto a server, that is the first thing to strip out.

The rough rule behind that diagram: if a pack crashes on first boot it is almost never memory, and if it crashes after an hour of play, it usually is. Startup failures are about which jars are in the folder. Runtime failures are about what the world is doing.

Memory: heap, metaspace and the kill with no stack trace#

Modded Minecraft has three distinct ways to run out, and only one of them produces the error people expect.

• Heap exhaustion gives you OutOfMemoryError: Java heap space, a stack trace and usually a crash report. This is the one where raising -Xmx helps, provided there is room under the container limit.
• Metaspace exhaustion is a modded speciality. Three hundred mods means tens of thousands of loaded classes, and metaspace lives outside the heap. A pack that "should fit in 6 GB" dies on a 6 GB plan with -Xmx6G because the heap was fine and the process still went over.
• The container stop produces nothing at all. The log ends mid-sentence, there is no exception and no crash report, because the process was killed from outside for exceeding its memory limit. On RE:NODE that is deliberate - at the limit the server is stopped and restarted clean rather than left to swap - but the diagnostic signature is the same everywhere: silence.

The fix for the second and third is the same and it is counter-intuitive: lower `-Xmx`. On a 10 GB plan running a 200-mod pack, -Xmx8G leaves 2 GB for metaspace, thread stacks, the JIT code cache and Netty's direct buffers, and the server stops dying. How much RAM a Minecraft server needs has the headroom table and the reasoning.

Client mods, server mods and the mismatch screen#

Mods are not plugins. A plugin runs only on the server and players join with an unmodified client. A mod that adds blocks, items, dimensions or recipes has to exist on both sides at the same version, because the client needs to know what it is drawing.

Forge and NeoForge enforce this at connection time and produce a screen headed Connection Closed - Mismatched Mod Channel List, listing the channels the server has that the client does not and vice versa. It is blunt but honest: the list on that screen is your diff. Fabric is looser - it only rejects a client outright when a mod registers a networking channel and the client lacks it - so a Fabric mismatch often shows up later as missing blocks, phantom items or a desynced inventory instead of a clean kick.

Three categories, and getting them straight prevents most of this:

• Server-only: performance mods, spawn control, block logging, backup mods, Discord bridges, permissions. Players install nothing.
• Client-only: rendering, shaders, minimaps, inventory tweaks, interface mods. These must never reach the server's mods folder.
• Both: anything that adds content or changes rules. Every player needs the same jar at the same version, which in practice means distributing the pack through a launcher rather than a chat message.

The four settings that cause most of the rest#

Once the pack boots and people can join, four things account for most of the lag and most of the "it was fine yesterday" reports.

view-distance=8simulation-distance=6max-tick-time=60000

1. View distance. It multiplies loaded chunks by players, and modded chunks are heavier than vanilla ones. A pack at view distance 12 with fifteen players is a different server from the same pack at 8. Start at 8, and on a big tech pack try 6.
2. Chunk generation during play. Generating new terrain on demand while people play is where most "random" spikes come from, and worldgen mods make it several times worse. Pregenerate the area you expect to be used with Chunky (/chunky radius 3000, /chunky start) before anyone logs in, and put a world border round it. World borders and pregeneration is the whole procedure.
3. Entity accumulation. Farms, mob spawners and dropped items from a chunk-eating quarry are the usual cause of a server that runs fine for a week and then does not. The vanilla maxEntityCramming gamerule (default 24) and randomTickSpeed (default 3) are the two levers every pack has; most packs also ship a spawn-control mod with better ones.
4. Chunk loaders. Tech packs let players keep chunks loaded permanently - quarries, contraptions, dimensional chunk loaders. Twenty of those and your server is simulating twenty extra areas with nobody in them. Find out which mod in your pack provides them and cap it before the first week is out.

To see which of the four you have, profile rather than guess. spark runs on Fabric, Forge and NeoForge as well as Paper: /spark profiler start, play for a few minutes, /spark profiler stop, read the link. On 1.20.3 and later vanilla also has /tick query, which gives you tick time without installing anything. Reading a spark report explains what the flame graph is telling you.

Performance mods that are safe to add#

A small set of mods reliably makes a modded server faster without changing behaviour. None of them are a substitute for the four settings above, but they are close to free.

Add them one at a time, restart, and watch the log. C2ME in particular changes how worldgen runs and should be tested on a copy of the world before it goes near the real one. And do not add a client-side "optimisation" mod to a server because the name sounds right - Sodium and its forks are renderers, and there is nothing on a server to render.

Updating a pack without losing the world#

Every game patch and every pack update breaks something until authors catch up, so a modded server should never auto-update on the day of a release. The procedure that works:

1. Back up the world, `mods/` and `config/` together. They are one unit; a world restored next to the wrong mod versions is not a restore. Backup slots come with every plan here, backups are stored off the machine they protect, and you can lock one so rotation cannot delete it - do that before an update.
2. Write down the versions you are on. Loader version, Minecraft version, pack version, Java version. This is the state you are rolling back to.
3. Update with nobody online, start the server, and read logs/latest.log from the top rather than watching the tail. The interesting lines are in the first thirty seconds.
4. Expect the registry prompt when you remove a mod. Forge notices that the world references blocks and items that no longer exist and refuses to load rather than deleting them silently. You can accept the loss deliberately by adding -Dfml.queryResult=confirm to the JVM arguments - and it is a loss, so back up first.
5. Log in and walk round the areas people built in before you announce it is back. Missing blocks show up immediately and are much easier to discuss before thirty people have seen them.

What to do when a mod update breaks covers the rollback in detail, backups that actually restore covers why the untested backup is not one, and keeping a modded server clean covers the security side of running other people's code.

FAQ#

How much RAM does a modded Minecraft server need?

Size for the pack, not the player count: the mods, registries and worldgen are paid whether one person is online or eight. A 30 to 80 mod Fabric pack runs in 6 GB, a 150-plus-mod Forge or NeoForge pack wants 8 to 10 GB, and old 1.12 kitchen-sink packs want 10 GB and Java 8. Then leave 20 to 25% of the container below your -Xmx for metaspace.

Why does my modpack crash immediately but vanilla runs fine?

Because startup failures are about the jars in the folder, not the memory limit. In order of likelihood: wrong Java version, a client-only mod on the server, a missing dependency, a mixin conflict. All four are named in the first thirty seconds of logs/latest.log.

Do players need to install the same mods as the server?

For anything that adds content or changes rules, yes, at the same version. Performance, logging, permission and backup mods are server-side only and players install nothing. Rendering and interface mods are client-side only and must be kept off the server.

Can I run plugins on a Forge or Fabric server?

Not directly - plugins target the Bukkit and Paper API, which neither loader provides. Hybrid servers such as Mohist and Arclight bolt the two together and are noticeably less stable than either half; if you need plugins, run Paper and accept that you cannot add new blocks. Fabric does have server-side ports of some familiar tools, including a permissions implementation.

What does "Mixin apply failed" mean?

A mod tried to patch a method that was not shaped the way it expected - usually because another mod patched it first, or because the mod was built for a different Minecraft version. The log names the mixin and the target class; the mod that owns that mixin is the one to update or remove.

Is it safe to change the pack's config files?

Yes, and often necessary on a server - packs are tuned for single player. Change one file at a time, keep the original, and remember that some mods only read their config at startup. Configs in config/ are regenerated if deleted, which is a useful way to reset one you have broken.