How to Add Mods to a Minecraft Server

Mods divide into server-side, client-side, and both. Knowing which you are holding determines where it goes.

Client-side mods run entirely on a player's machine and the server never knows they exist. Shaders, minimaps, performance mods and interface tweaks are all in this group, and players can run different ones freely.

Server-side mods run only on the server. Performance mods with server builds, permissions systems and world-management tools live here, and clients need nothing.

Mods that add content — blocks, items, mobs, recipes, dimensions — must be on both, at identical versions. This third category is where every mismatch problem comes from.

Stop the server first. Adding files while it is running produces inconsistent results and can corrupt configs written on shutdown.

Open the server's own directory — the folder containing server.jar and server.properties. Inside it is a mods folder, created by the loader on first run. This is a different folder from your client's, and confusing the two is a common mistake.

Drop the .jar files in, including any dependencies such as Fabric API, which the server needs just as the client does.

Start the server and watch the console. It lists loaded mods during startup, and anything that failed reports the reason there rather than in a crash report.

Hosts provide a file manager in the control panel, and most also expose SFTP for bulk transfers.

For a handful of files the web file manager is fine — navigate to the mods folder and upload. For a whole modpack, SFTP is considerably faster and less likely to time out.

Many hosts also offer one-click modpack installation, which handles the loader, every mod and the configs in one operation. If you are running a published pack, use that rather than uploading files by hand.

Stop the server before uploading and start it afterwards. Some panels do this automatically; most do not.

This is the actual work, and getting it wrong produces an immediate connection rejection naming the mod that differs.

Identical means the same mods at the same versions. A client running version 1.2.0 of a mod and a server running 1.2.1 will often refuse the connection, and the error message is usually explicit about which mod is at fault.

The reliable approach is a modpack. Publish yours, or export it from Prism or the Modrinth app, and have everyone including the server use the same export. The lists match by construction rather than by everyone being careful.

The manual approach — zipping the mods folder and sending it round — works for a small group and degrades quickly as the group grows or the list changes.

Not every mod can go on a server, and installing one that cannot usually produces a startup crash rather than a polite refusal.

Client-only mods frequently reference rendering code that does not exist in a server environment. Sodium and Iris are the obvious examples — putting either on a server will crash it on startup with an error about missing classes.

Most mod pages state which side they belong on, and Modrinth shows this explicitly as client and server support fields. Check before uploading rather than after.

If a server crashes immediately after you added mods, a client-only mod is the first thing to suspect.

A dependency needed by a content mod is needed everywhere that mod runs, which means the server as well.

Fabric API is the usual one, and forgetting it server-side produces a startup failure naming every mod that wanted it — an alarming wall of text with one simple cause.

Match dependency versions to the Minecraft version exactly as you do on the client. A Fabric API built for a different version will be ignored and the mods will report it missing.

After the first run with a new mod, the server generates config files in its own config folder. These are separate from your client's and can legitimately differ.

Some settings only make sense on one side — rendering options on the client, world-generation settings on the server. Others should match, particularly anything affecting recipes or progression, or players will see different behaviour from what the server enforces.

When a pack ships configs, use the pack's server configs on the server rather than copying your client ones across. Pack authors usually differentiate them deliberately.

Coordinate it. An uncoordinated update is the most common way a working modded server stops working.

Announce the update, take a backup, stop the server, replace the files, start it, then have everyone update their clients. Server first is deliberate — a client ahead of the server is rejected just as firmly as one behind.

Turn off automatic pack updates in everyone's launcher. Left on, one person's launcher will update at an inconvenient moment and they will be unable to join with no obvious explanation.

Keep a note of which version the group is on so anyone returning after a break knows what to install.

If the server matters, keep a second copy for testing. Most hosts let you run a second instance cheaply, and self-hosting a test server costs nothing but a folder.

Copy the world, apply the mod change, and start it. Ten minutes of checking catches most problems before they reach players.

This matters most for updates that remove mods, since the damage there is to the world rather than to the startup, and it may not appear until someone walks into an affected area.

Stop the server. Confirm each mod belongs server-side. Add mods and dependencies to the server's own mods folder. Start it and read the console for load failures. Update every client to the identical list. Have one person test the connection before announcing it.

Following that order turns most modded server maintenance into a routine ten-minute job rather than an evening of confusion.

The server console during startup is the most useful diagnostic tool available, and most people close the window without looking at it.

It prints each mod as it loads, along with its version. Counting those lines against what you uploaded confirms immediately whether everything was picked up.

Failures appear here rather than in a crash report, often with a plain-English explanation — a missing dependency, an incompatible version, a mod that cannot run server-side. These messages are usually clearer than anything in a stack trace.

On a rented server the console is in the control panel and scrolls quickly, so read it during startup or download the log afterwards.

Once the server is right, the remaining work is getting everyone's client to match, and how you do it determines how much support you end up providing.

The cleanest route is a published modpack that includes exactly the mods the server runs. Everyone installs it from the same launcher and matches automatically, and updates are a single coordinated action rather than a negotiation.

If your list is custom, export it as a pack from Prism Launcher or the Modrinth app. Both produce a file others import in one step, which is nearly as good and keeps you in control of the contents.

Whatever you choose, publish the exact version alongside it. 'We are on version 1.4.2' resolves most joining problems before anyone has to ask.