How to Install Minecraft Mods and Modpacks on Your Server

Before you start

Three things save an enormous amount of pain if you handle them first.

Back up your world. Adding, removing or updating mods can corrupt a save irreversibly. Download the world folder before you touch anything — this takes thirty seconds and has rescued countless servers.

Check your RAM. Modpacks are hungry. Under 80 mods needs about 4 GB, 150 or more needs 8 GB. Installing a heavy pack on 2 GB won't crash immediately — it'll start, run badly, and then die during world generation, which is a much more confusing failure. Our guide to Minecraft server RAM requirements has the full breakdown.

Decide before you build. Switching loaders on an existing world — Forge to Fabric, say — will generally break it. Choose your pack while the world is still empty.

Forge, Fabric, NeoForge or Quilt?

A mod loader is the layer that lets mods hook into Minecraft. Mods are built for one specific loader and won't work on another.

If you're installing a published modpack you don't choose — the pack dictates the loader. This matters when you're assembling your own set of mods.

Installing with the modpack installer

This is the route to use whenever possible. The FlameHost control panel installs packs from CurseForge, Modrinth, FTB and Technic directly.

1. Stop your server. Installing over a running server produces corrupt files.
2. Open the modpack installer in the control panel.
3. Search for your pack by name — All the Mods, Better MC, Create: Astral, whatever you're after.
4. Pick the exact version. Note it down. You need this identical version on your client, and "latest" is not a version number.
5. Install. The loader, Minecraft version and every mod are fetched automatically. Big packs take a few minutes.
6. Start the server and watch the console. First boot is slow — it's generating configs for every mod. Wait for the "Done" line before trying to connect.

If the console stops moving for several minutes on first boot, that's usually normal for a large pack. If it stops and then prints an exception, jump to troubleshooting.

Installing a pack manually

Sometimes you need this — a pack not in the installer, a custom pack, or a specific build.

1. Download the server pack, not the client pack. Most CurseForge packs publish a separate server files download. Using the client pack is the most common mistake here and produces immediate crashes.
2. Stop the server and clear the old files. Delete the previous mods folder, loader jars and config folder. Keep your world folder.
3. Upload the pack via the file manager, or use SFTP for anything large.
4. Unzip it in place so the folder structure sits at the server root — mods, config and the loader files should be top level, not nested inside another folder.
5. Set the startup jar to the loader jar the pack shipped with.
6. Accept the EULA if prompted, then start.

If some packs ship a start.sh or run.bat, don't run those directly on managed hosting — read them to find the jar name and point your panel's startup command at it instead.

Adding individual mods

Building your own set rather than using a published pack:

1. Install the loader first through the panel — Forge, NeoForge or Fabric with your chosen Minecraft version.
2. Check every mod matches both that loader and that Minecraft version. A Fabric 1.20.1 mod will not load on Forge 1.20.1, and a 1.20.1 mod won't load on 1.21.
3. Add required dependencies. Many mods need a library mod — Fabric API, Architectury, Cloth Config. Missing dependencies are the top cause of first-boot crashes.
4. Drop the jars into mods via the file manager.
5. Skip client-only mods. Shaders, minimaps, and most visual mods will crash a server. If a mod's page says client-side only, it does not go on the server.
6. Add a few at a time and restart between batches. Adding forty mods at once means a crash tells you nothing about which one caused it.

Setting up your client to match

A modded server needs the same mods on the player's machine. Everyone connecting needs the identical pack.

• Use the same launcher as the pack's source — CurseForge app for CurseForge packs, Modrinth App or Prism for Modrinth.
• Install the exact same pack version as the server. Version 1.14 and 1.15 of the same pack will refuse to connect.
• Allocate client RAM too. Heavy packs need 6-8 GB on the client, set in your launcher's Java settings.
• Update everyone together. When you update the server pack, every player must update before they can rejoin.

Version mismatch is the number one reason people can't connect to a modded server they just set up. If you get kicked immediately with a mod-related message, compare version numbers first.

Troubleshooting crashes

Modded servers crash. Reading the log is the whole skill — the answer is nearly always written there in plain English, a few lines above where you stopped reading.

Server won't start at all

• "Missing or unsupported mandatory dependencies" — a required library mod is absent. The log names it; install it.
• "Incompatible mod set" / wrong Minecraft version — a mod built for a different version. The log names the file.
• Out of memory / exit code 137 — the pack needs more RAM than your plan has.
• "You need to agree to the EULA" — set eula=true in eula.txt.

Starts, then crashes during world generation

Almost always memory, or a worldgen mod conflict. Check RAM first — this is the classic symptom of a pack that's slightly too big for its plan.

Players can't connect

• Client pack version doesn't match the server's.
• A client-only mod was installed server-side, or vice versa.
• The server is still generating chunks on first boot. Give it time.

Reading a crash log properly

Open the crash-reports folder, take the newest file, and look for the "Caused by" line — that's the actual error, not the stack trace above it. Mod file names in that line point at the culprit. Pasting the log into a search engine, or into our Discord, usually resolves it quickly.

Keeping a modded server fast

Modded servers are far heavier than vanilla. What helps most:

• Lower simulation distance to 4-6. Modded worlds simulate much more per chunk, so this matters more here than on vanilla.
• Add server-side performance mods. On Fabric, Lithium and Starlight are close to free performance. Forge and NeoForge have equivalents.
• Pre-generate the world with Chunky. Modded worldgen is expensive; doing it once up front removes most exploration lag.
• Watch chunk loaders. Tech mods let players keep chunks loaded permanently. A handful of quarries can consume an entire server.
• Strip what you don't play. Big packs ship mods nobody in your group will touch. Each one costs memory and startup time.
• Restart nightly. Modded servers accumulate memory pressure faster than vanilla.

Ready to build a modded world? Claim up to 8 GB with invites, or read our crossplay setup guide to bring Bedrock players into your world too.