Modpack server from CurseForge or Modrinth

To run a modpack as a server, start from the pack's server pack if it has one - most large CurseForge packs publish one as an extra download - and upload it with the matching loader and Java version. If there is no server pack, you build the server folder from the pack's manifest: CurseForge exports list mods by project and file ID in manifest.json, and Modrinth's .mrpack lists download URLs in modrinth.index.json, each marking which side a mod belongs on. Either way, the work that remains is the same: install the right loader, remove client-only mods, copy the pack's config overrides, give it enough memory, and make sure players have exactly the same pack version. This post walks through both formats and every place the process fails.

What a modpack actually is#

A modpack is three things bundled together: a loader at a specific version (Forge, NeoForge, Fabric or Quilt), a list of mods at specific versions, and a set of overrides - configs, scripts, default settings, sometimes resource packs - that turn a pile of mods into a designed experience.

The client pack you install in a launcher includes all three, plus everything a player sees: shaders, minimaps, menus, sounds. A server needs the loader, the mods that run game logic, and the overrides that affect the server. It must not have the client-only parts, and it must have the exact same versions of everything else.

That gives three routes to a server, in order of effort:

1. Download the server pack the author made. Fastest and most reliable, because the author has already removed the client-only mods.
2. Build one from the pack file - a CurseForge export or a Modrinth .mrpack - with a tool or by hand.
3. Assemble your own pack from individual mods. Covered in running a modded server without the crashes; this post is about published packs.

Before anything else, find three facts on the pack's page and write them down: the Minecraft version, the loader and its exact version, and the pack version. Every step below depends on them.

CurseForge: server packs and manifest.json#

On CurseForge, a pack's Files tab lists each release. Large packs usually attach a server pack to each release as an additional file. It is a zip, separate from the client download, and typically contains:

• mods/ with client-only mods already removed
• config/, and often defaultconfigs/, kubejs/ or scripts/
• A start script, and sometimes a README with the recommended memory and Java version

Server packs differ in one important way: some include the loader already installed, with libraries/ and run scripts in place; others include a script that runs the loader installer on the first start, downloading files from the internet. Open the start script before you run it so you know which kind you have. NeoForge server setup explains the run scripts and user_jvm_args.txt that Forge-lineage packs use.

If a release has no server pack, you have the client export. Its key file is manifest.json:

{  "minecraft": {    "version": "1.20.1",    "modLoaders": [{ "id": "forge-47.3.0", "primary": true }]  },  "manifestType": "minecraftModpack",  "manifestVersion": 1,  "name": "Example Pack",  "version": "2.4.1",  "files": [    { "projectID": 123456, "fileID": 4567890, "required": true }  ],  "overrides": "overrides"}

The manifest does not contain mods. It contains CurseForge project and file IDs, and the overrides folder beside it holds the configs and scripts to copy over the top. Turning IDs into jars means asking CurseForge's API for each file, which is what the CurseForge app does when you install the pack.

There is a catch specific to CurseForge: mod authors can opt out of third-party distribution. Tools that build server folders through the API cannot download those mods automatically and will list them for you to fetch by hand from each mod's page. Expect a few on any large pack.

Modrinth: the .mrpack format#

A Modrinth pack is a .mrpack file, which is a zip with a different extension. Inside are modrinth.index.json and up to three override folders.

{  "formatVersion": 1,  "game": "minecraft",  "versionId": "2.4.1",  "name": "Example Pack",  "files": [    {      "path": "mods/example-mod-1.3.0.jar",      "hashes": { "sha1": "...", "sha512": "..." },      "env": { "client": "required", "server": "unsupported" },      "downloads": ["https://cdn.modrinth.com/data/..."],      "fileSize": 215040    }  ],  "dependencies": { "minecraft": "1.21.1", "fabric-loader": "0.16.5" }}

Three parts of this file matter for a server:

• `dependencies` names the Minecraft version and the loader: fabric-loader, quilt-loader, forge or neoforge, each with its version. Install exactly that.
• `env` says whether each file is required, optional or unsupported on the client and on the server. A file with "server": "unsupported" is client-only and does not belong on the server. This is the pack author's declaration, so it is only as accurate as they made it, but it is far better than guessing.
• `downloads` are direct URLs, and hashes let you verify the result.

The override folders are applied after the files are downloaded: overrides/ for both sides, server-overrides/ for the server only, and client-overrides/ for the client only. Copy overrides/ and then server-overrides/ into your server folder, in that order, and ignore client-overrides/.

Tools that build the server folder#

You can resolve a manifest by hand - open each URL, download each jar - and for a twenty-mod pack that is fine. For two hundred mods, use a tool that reads the index and builds the folder:

• ServerPackCreator builds a server pack from a CurseForge or Modrinth pack, including removing a list of known client-only mods. It has a GUI and a command-line mode.
• mrpack-install reads a .mrpack, downloads the server-side files and installs the loader. It is a single binary designed for exactly this job.
• packwiz is a pack format of its own, used by some authors; its bootstrap installer can update a server from a published pack on every start: java -jar packwiz-installer-bootstrap.jar -g -s server https://example.com/pack.toml.
• Prism Launcher imports both CurseForge and Modrinth packs on a desktop, which is a convenient way to get every jar onto your own machine before you sort them.

Run these on your own computer, check the output, and upload the result. A tool that silently skipped a mod it could not download, or kept one it should have removed, is easier to spot locally than in a server log.

On RE:NODE there is no modpack installer and no integration with any mod site - the Minecraft line runs Paper with the matching Java version, and a modpack is something you put on it yourself. Zip the finished server folder, upload it through the file manager and unpack it in place, or copy it over SFTP. SFTP and the file manager has the connection details. There is no whitelist of allowed mods, so nothing in the pack is blocked.

Removing client-only mods#

This is the step that produces most first-boot crashes. Client-only mods fall into recognisable groups:

Loaders handle them differently. Fabric reads each mod's declared environment and quietly skips mods marked client-only on a dedicated server, so a well-made client mod does no harm. Crashes on Fabric come from mods that declare themselves for both sides but are not, and the error reads Cannot load class ... in environment type SERVER. Forge and NeoForge are less forgiving: a client-only mod often crashes the start with Attempted to load class net/minecraft/client/... for invalid dist DEDICATED_SERVER.

In both cases the stack trace names the mod. Remove it from the server's mods/ folder, start again, and repeat until the server reaches Done. Keep a list of what you removed; you will need it again on the next pack update.

Loader, Java and the start command#

With the mods sorted, the server needs the right loader and the right Java:

• The loader version from the pack, exactly. Not the latest. A pack built on NeoForge 21.1.77 was tested on that build; a newer one is usually fine and occasionally is not.
• Java to match Minecraft. 1.20.4 and earlier need Java 17 (1.16.5 and earlier need Java 8), 1.20.5 and later need Java 21. JVM flags and Java versions has the table.
• One place for memory. Server packs ship start scripts that set memory; panels often set it too. Use one. If both pass -Xmx, the last one on the command line wins.

On a panel, check what the start command runs. Fabric packs start from a single launcher jar. Forge and NeoForge packs from 1.17 onwards start from argument files rather than one jar, and the pack's own script is the reference for what the command needs to be.

Memory, first boot and pre-generation#

Modpacks vary enormously, so take the pack author's recommendation as the starting point and these as a sanity check:

Leave space between the heap and the plan's memory limit for metaspace and native memory; modded servers load a very large number of classes. On RE:NODE, Minecraft plans run from 2 to 14 GB, and a container that reaches its limit is stopped and restarted clean rather than swapping - the log simply stops, with no crash report. If that happens during play, the heap is too close to the limit or the plan is too small. How much RAM a Minecraft server needs goes into the sizing.

The first boot of a large pack can take several minutes while every mod initialises and the world generates. Watch for Done in the console rather than for the panel to call the server online. Then pre-generate before people arrive: worldgen mods make chunk generation far more expensive, and exploring players are where modded lag usually comes from. Chunky works on every loader, and world borders and pre-generation has the procedure.

Keeping players and the server in step#

A modded server only works if every player has the same pack version as the server. The practical arrangements:

• Publish the exact pack and version in your Discord or on your website: "Example Pack 2.4.1 on CurseForge" or the Modrinth version link.
• Do not add mods the pack does not have, unless they are server-only (performance, backups, permissions, chat bridges). Anything that adds content forces every player to install it by hand, and someone always gets it wrong.
• If you must customise, publish your own fork of the pack so players install one thing. Modrinth and CurseForge both let you upload a pack; packwiz is designed for exactly this.

When the pack updates:

1. Read the changelog for removed mods. Removing a content mod deletes its blocks and items from the world.
2. Back up the world, mods/, config/ and defaultconfigs/ together. Restoring a world next to the wrong mods is not a restore. On RE:NODE you can lock that backup so rotation does not remove it while you test.
3. Replace mods/ completely rather than merging, so old versions do not linger beside new ones.
4. Apply the new overrides, but keep your own changes - diff config/ rather than overwriting it blindly.
5. Start with nobody online, read the log from the top, and tell players to update before they connect.

What to do when a mod update breaks is the plan for when step 5 goes wrong.

Troubleshooting the usual failures#

"Mismatched mod channel list" or "missing mods" on connect. The client and server packs differ. The screen lists which mods are on one side and not the other. Usually the player is on an older pack version, or you stripped a mod that was not client-only.

The server starts but the world has no pack features. The overrides were not copied, or were copied to the wrong place. Check that config/, defaultconfigs/ and any kubejs/ folder sit next to mods/, not inside another folder.

Changed configs have no effect. The setting is a per-world server config and you edited the template in defaultconfigs/. The live copy is in world/serverconfig/.

A mod is missing after building from a manifest. On CurseForge, the author opted out of third-party distribution. Download it manually from its page, matching the file ID in manifest.json.

The server stops with no error. Memory. Lower the heap so it leaves room under the limit, or move up a plan.

FAQ#

Can I just upload the client modpack to the server?

You can, and on Fabric it will often start because Fabric skips mods marked client-only. On Forge and NeoForge it usually crashes on a renderer or shader mod. Either way, a server folder built from the pack's server pack or its manifest is cleaner and uses less memory.

Where do I find a CurseForge server pack?

On the pack's Files tab, open the release you want and look under its additional files for a server pack. Not every pack provides one, and the server pack's version must match the client version players install.

What do I do with a .mrpack file?

Rename it to .zip to look inside, or use a tool such as mrpack-install that reads modrinth.index.json, downloads the server-side files, installs the loader and applies overrides/ and server-overrides/.

Can players join with a different version of the pack?

Usually not. Any difference in content mods causes a kick or desync. Small patch releases sometimes only change configs and still connect, but the safe rule is that the server and every player run the same pack version.

Do I need a database for a modpack server?

Not for the pack itself; mods store their data in the world folder. A few server-side mods for permissions, logging or web maps can use an external database, and Minecraft plans on RE:NODE include one database slot if you want to use it.