Guidefor server owners5 min read
Server-side-only mods: what they are and how they work
A mod that runs entirely on the server while every player connects with a plain vanilla client. The client-server split that makes it possible, and exactly what disqualifies a mod from it.
The client never learns the mod exists
A server-side-only mod runs entirely on the server. Every player connects with a plain, unmodified vanilla client, no prompt, no download link, no mismatched-mods error. This is not a workaround or a trick. It follows directly from how the vanilla protocol already splits the game.
A forum thread titled "Server-Side Horror" put it plainly, drawing over eight thousand views: players don't need to install anything, and you can put a mod like this on your server without the players even knowing it's there. NeoForge, the team behind the loader, ran an entire 2025 modjam built around the idea, Serverside Summer, with rules stating the mod should not be needed on clientside at all. This is a live, organised part of the modding community, not a rare curiosity.
Why the split exists at all
Minecraft's client and server have never done the same job. The server simulates the world: mob behaviour, physics, world generation, inventories, everything that decides what actually happens. The client does not simulate any of that. It renders what the server tells it and predicts a little to hide latency, but the authority is always the server.
That gap is why a server-side-only mod is possible. The client already expects to be told what mobs are doing, where blocks are, what an inventory contains, all through standard packets it knows how to read. A mod that only changes how the server computes those things, not what shape the packets take, changes nothing the client needs to understand.
What actually qualifies
The common thread across every example is this: the mod only touches logic that already lived entirely on the server, and sends the client nothing it wasn't already prepared to receive.
Custom mob AI and behaviour. A zombie that flanks instead of walking straight at you is computed server-side. The client still just sees a zombie moving, standard entity-position packets it already renders every tick.
World generation changes. The client receives ordinary chunk data. It has no concept of how that data was produced, so a different cave shape or a rebalanced ore distribution arrives looking exactly like vanilla terrain.
Gameplay, economy, and permission systems. Player balances, land claims, rank permissions, all of it is server-side bookkeeping. The client sees the results, an item appearing, a message in chat, through vanilla mechanisms.
Anti-cheat and moderation tooling. These watch server-side state and act on it, kicking, logging, flagging. Nothing about that requires the client to know the tool exists.
Rebalancing existing vanilla mechanics. A mod that changes how much damage an enemy deals, how fast hunger drains, or how far you fall before taking damage is editing numbers the server already controlled. No new block, item, or texture enters the picture.
What disqualifies a mod immediately
The rule is simple once you see it: anything new and client-visible needs a client install.
- A new block, item, or entity needs a texture, model, and sound the vanilla client does not already have. The server cannot hand a client an asset it was never built to load.
- New client-side UI or HUD elements, a mod adding a minimap overlay or a custom inventory screen needs code running on the client to draw it.
- New key bindings. The client has to register the binding to listen for it.
- New rendering effects, shaders, or particles the client has to compute needs client code to compute them. The server can trigger a vanilla particle effect; it cannot invent one.
If a mod adds any of these, players must install it, and the mod's own listing should say so. There is no partial version of this distinction: a single new item icon is enough to require the client.
Loader-specific is a separate question
Server-side-only and loader-specific describe two different boundaries, and mixing them up causes confusion.
Client-side vs. server-side is about which machine needs the mod at all. A server-side-only mod needs no client installation whatsoever.
Loader-specific is about which loader's machinery the mod was built against, covered in why mods are loader specific. A Fabric mod is compiled against Fabric's API and will not load on NeoForge, full stop, regardless of which side it runs on.
These two axes are independent. A server-side-only mod still has to be built for the loader your server runs, Forge, NeoForge, or Fabric, and that loader still has to be installed on the server. What server-side-only removes is the client's obligation, not the server's. Your server needs the loader and the mod. Your players need nothing.
Why this matters for running a server
The biggest source of failed modded servers is not the mods, it is getting players to install them correctly. Every extra step, choosing a loader, matching a version, finding the right build, is a place someone gives up or gets it wrong, and support threads on this site's own forum research show that friction constantly.
Server-side-only mods sidestep it entirely for a real category of gameplay depth: smarter mobs, a working economy, real moderation tools, better-generated terrain. None of it asks a single player to touch their launcher. You get to make the server meaningfully different without asking anyone to opt in.
Checking before you install
Before adding a mod to your server on the assumption players won't need it, verify the claim rather than trust the mod's name:
- Check the environment tags. Modrinth marks each mod's sidebar with Client, Server, or Client and server. CurseForge lists the same information as environment metadata. This is the fastest, most reliable signal.
- Read the mod's own description. Authors building for this purpose, like Serverside Summer entrants, usually say so directly, often in the first line.
- Test with a genuinely vanilla client before telling players nothing is required. A mod that is supposed to be server-only but was tagged wrong will either fail silently or produce a mismatched-mods disconnect, and you want to find that before your players do.
- Recheck on updates. An author can add a client-visible feature in a later version without renaming the mod. What was server-side-only at 1.2 is not guaranteed to still be at 2.0.
Checking mod compatibility covers the same loader-and-version checks for mods you do expect players to install.
