The Case Against Running Every Popular Plugin
Why a long plugin list costs a Minecraft server memory, startup time, upgrade work and debugging hours, what a deliberate plugin list looks like, and how to prune one that has already grown too long.
ChunkPod Team · · 8 min read
The Case Against Running Every Popular Plugin
Look at any small SMP's plugin folder that has been running for a year and you'll usually find between thirty and forty jars. Each one made sense the day it went in. Someone asked for grave protection after dying in lava, so GraveStones landed. A griefer trashed spawn, so CoreProtect got added. Someone wanted afk detection, land claims, custom join messages, a shop, a chat filter, a nicer tab list, and on it went. None of those choices were wrong at the time. Together, they add up to a server that starts slow, eats memory, and hurts every time Minecraft ships a new version.
This is a case for keeping the list short on purpose.
How plugin lists get bloated
Plugins are cheap to install. Drop a jar in the folder, restart, done. That low cost is the problem: the friction to add is tiny, and the friction to remove is high, because someone somewhere is probably still using the feature. A plugin that got added for one player's request in month two is still running in month fourteen, even though that player left months ago.
There's also the "someone recommended it on Reddit" pipeline. A big thread on must-have plugins for a survival server lists twenty. A YouTube guide says every Paper server needs another six. If you add plugins without asking whether you actually needed the feature yesterday, the list grows without a plan.
The result is a folder full of jars whose real job is not to serve players today, but to preserve a decision you made months ago and never revisited.
The memory cost is real but boring
Every plugin loads classes into the JVM, holds its own config in memory, and usually keeps caches, listeners and scheduled tasks alive for the whole run. One plugin isn't much. Thirty is a different story. On a small server with 4 to 6 GB of heap, plugin overhead can quietly take a large slice before a single player logs in.
The trouble is not the raw megabytes. It's what they push out. When heap gets tight, the garbage collector runs more often, pauses get longer, and TPS drops in ways that don't show up as an obvious spike in any one plugin's timings. You end up profiling for hours looking for the villain, and there isn't one. The villain is the crowd.
Plugins that hold entity data, region data or per-player history are the biggest offenders. Anti-cheat, land claim, logging and economy plugins tend to keep more state per player than a chat cosmetic does, but even small utility plugins add up when you have thirty of them.
Startup time and reload pain
Startup is the honest audit. A Paper server with no plugins starts in a handful of seconds. Every plugin adds file reads, config parsing and often a network call to check for updates or to phone home to some author's stats endpoint. It's not unusual for a 30-plugin server to take a minute or more from java -jar to "Done" in the log.
That matters more than it looks. A slow startup means:
- Every crash costs the community more downtime.
- You'll avoid restarts even when they'd help, because the pause is annoying.
- Config changes are painful, so you'll patch things live with
/reloadand pretend it's fine. It isn't./reloadis one of the most reliable ways to leave a server in a weird half-broken state, and the more plugins you have, the more likely something breaks.
The plugin list is the biggest thing you can shorten if you want fast, clean restarts.
Version upgrades turn into a scavenger hunt
Minecraft's major versions bring API changes. Paper, Spigot, Fabric and Forge all follow, but plugin authors don't move in lockstep. The day a new version drops, some plugins update within hours, some take weeks, and some are abandoned and never come back.
With five well-chosen plugins, updating is a coffee's worth of work. With thirty-five, at least one is going to be:
- Not updated yet, with no ETA.
- Updated, but with breaking config changes buried in the changelog.
- Silently broken on the new version, with issues that show up hours after restart.
- Replaced by a fork under a new name, and you have to decide which fork to trust.
Every plugin you keep is a small, recurring tax on every future update. The more you keep, the more the tax adds up. Some servers stay on old Minecraft versions for a year past release, not because the admin doesn't want to move, but because two plugins in the pile don't have working versions and nobody has volunteered to replace them.
Conflicts nobody warned you about
Two plugins written by different people, each doing something reasonable, can interact in ways neither author expected. A land claim plugin and an anti-cheat both hook into player movement, and their check order can decide whether legitimate movement gets flagged. A chat plugin and a Discord bridge each rewrite messages, and either one going first produces different results. A world manager and a spawn plugin can fight over which one owns the respawn location.
You don't discover these on day one. They come out during odd events: a lag spike during a boss fight, one player who can't log in, a message that shows up twice for some people. The debugging cost is not proportional to the number of plugins. It scales with the number of pairs, which grows much faster.
Fewer plugins means fewer pairs, which means fewer of these little mysteries.
What a deliberate list looks like
Long-running SMPs that keep their setup clean tend to converge on a similar shape:
- One backup plugin, or none if the host handles it. Backups are critical, so pick one, configure it once, and forget it.
- One protection plugin. Either grief rollback (like CoreProtect) or region protection (like WorldGuard), not both stacked on top of each other unless you truly need both.
- One permissions plugin. LuckPerms is the usual answer. Don't stack a second one on top for "extra features".
- One chat plugin at most. Vanilla chat is fine for a small SMP. If you need a Discord bridge, that's one more.
- One or two quality-of-life plugins for whatever your community actually asks for. Homes and warps, or a market, but not both plus a teleport plugin plus a party plugin.
Everything else is worth a hard question: what breaks if this isn't installed? If the answer is "nothing anyone would notice this week", it's a candidate for removal.
Optimisation and lag-fix plugins deserve their own note. Adding three of them at once because a Reddit thread said to is how you end up with a server that runs worse and where you can't tell which plugin's aggressive entity culling is the reason mobs vanish before players reach them. Most of what those plugins do can be set in spigot.yml, bukkit.yml and Paper's world config directly, and you keep control over what changed.
Pruning a server that's already bloated
If your list is already long, the way out isn't dramatic. Delete nothing on a Friday night. Instead:
- List every plugin and write, in one sentence, what it does for players today. If you can't write the sentence, that plugin is the first to go.
- Look at commands. If nobody has used a plugin's commands in the last month, that's a signal.
- Check timings or spark on a normal evening and note the top consumers. Some are unavoidable (protection, anti-cheat), some aren't (a fancy tab list).
- For every candidate, announce a removal date and a reason. Give players a week. Some will speak up about a feature you didn't know was in use, and you keep those. The rest go, and almost nobody notices.
Do this once a quarter and the list stays short on its own.
The point isn't minimalism for its own sake
A server with three plugins isn't better than a server with ten if the ten are all pulling their weight. The goal is that every plugin you run is one you'd add again today, not one you inherited from a decision made a year ago that nobody remembers making. Every jar in the folder is a small ongoing commitment: memory, startup time, upgrade work, and a share of the debugging bill. Ask whether you'd sign up for that commitment today. If not, drop it.
If you're sanity-checking how much memory your plugin list will actually need on a new server, the RAM Calculator at chunkpod.com/tools/ram-calculator gives a rough estimate from player count, software and plugin count. And when you sit down to trim spigot.yml, bukkit.yml and Paper's config so you can remove a "lag fix" plugin, the config generators at chunkpod.com/tools cover those files with the settings explained.
ChunkPod is a Minecraft server host in early access. If you want a simpler place to run your next server, join the waitlist at chunkpod.com.