Minecraft plugins worth installing, and the ones that cost you

Every plugin is code running inside your server's single main thread, and a tick is 50 milliseconds long. A plugin that costs 5 ms per tick has taken a tenth of the budget before the game has moved a mob. That is the frame to keep in your head: the list is not free, a short list chosen deliberately outperforms a long one collected over two years, and the cost shows up as tick rate rather than as memory. This post is the short list - four plugins almost every server needs, six more that earn their place once you have players, the categories that quietly ruin a server, and how to install, update and remove any of them without breaking things.

What a plugin actually costs you#

Plugins are cheap in memory and expensive in time. A typical jar is a few megabytes of classes plus whatever it caches; twenty of them will not move your memory graph. What they compete for is the tick.

The server does everything in order, on one thread: entity movement, redstone, block updates, then every plugin's scheduled tasks and every event handler that fired. If the total exceeds 50 ms, the tick overruns and TPS falls. On Paper, /mspt shows you the current cost directly, and it is a much earlier warning than TPS - a server sitting at 45 ms still reads 20.0 TPS and is one mob farm away from visible lag.

Three specific behaviours are what make a plugin expensive:

• Repeating tasks on the main thread. A plugin that scans every loaded chunk once a second is doing work proportional to your player count and view distance, every second, forever.
• Synchronous database queries. A lookup on the main thread blocks the whole server until it returns. If the query takes 200 ms, the server lost four ticks. Login handlers are the classic offender.
• Event handlers on hot events. BlockPhysicsEvent, EntityMoveEvent and chunk-load events fire enormously often. A handler that does anything non-trivial on one of them is a tax on everything.

None of this means avoid plugins. It means know what each one is for and be willing to remove one.

The four that almost every server needs#

A permissions plugin comes first, because everything else has no way to ask who somebody is. LuckPerms is the default answer and has been for years: groups with inheritance, per-world and per-server contexts, tracks for promotion, a web editor, and - the feature that actually saves you - /lp verbose on, which prints every permission check as it happens so you can see exactly which node a plugin is asking for instead of guessing.

$ lp creategroup moderator$ lp group moderator parent add default$ lp group moderator permission set coreprotect.inspect true$ lp user Steve parent add moderator$ lp editor

It stores to an H2 file by default, so nothing else is required to start, and it runs on Paper, Velocity, Fabric and Forge, which matters if you ever grow into a proxy network. The LuckPerms guide covers contexts and inheritance properly, and whitelists and permissions covers the layer above it.

Land protection prevents the single most common reason a community collapses. Two shapes of it, and most servers want both:

• Claim-based - GriefPrevention is the standard. Players claim with a golden shovel, earn claim blocks over time, and manage access with /trust, /containertrust and /accesstrust. No admin work per claim, which is the point.
• Region-based - WorldGuard, which needs WorldEdit alongside it. An admin selects an area and sets flags: /rg define spawn, then /rg flag spawn pvp deny. This is how you protect spawn, shops and event arenas.

Block logging with rollback turns "somebody burned down the town" from a disaster into a command. CoreProtect is the one: /co inspect toggles a mode where clicking a block prints its history, /co lookup u:Steve t:3d r:10 searches, and /co rollback u:Steve t:2h r:20 undoes it. It logs to a SQLite file by default. Grief protection and anti-cheat goes into the rest of that toolkit.

A profiler so that when the server slows down you can answer why instead of guessing. spark is the one, it is free, and it runs on Paper, Fabric, Forge and Velocity alike.

/spark profiler start... play for five minutes .../spark profiler stop/spark health/spark heapsummary

profiler stop prints a link to a flame graph that names the plugin, mod or system eating the tick. health prints TPS, MSPT and memory together. heapsummary tells you which classes are holding the heap, which is how you catch a plugin cache that has been growing since March. Reading a spark report explains what you are looking at.

A profiler turns an argument about which plugin is slow into a screenshot.

Backups are the fifth thing most lists include, and they are the one case where the plugin is usually the wrong tool. A backup plugin writes an archive to the same disk as the world it is protecting, which covers a corrupted chunk and nothing else. A panel-level backup is stored off the machine, can be locked so rotation cannot delete it, and restores with a button. Use that instead, and see below for how to make it consistent.

Installing, updating and removing plugins#

The mechanics are simple and the mistakes are consistent.

1. Download from the plugin's own page. Hangar, SpigotMC, Modrinth or the project's GitHub releases. A plugin is arbitrary code with full access to your server, its files and its database credentials. A reupload on an aggregator site is not worth the risk - keeping a modded server clean is the longer version of this argument.
2. Check the version it targets. A plugin built for 1.20 may not load on 1.21. The download page states the supported range; believe it rather than hoping.
3. Put the jar in `plugins/` and restart. On a panel that is the file manager or SFTP, then the Restart button.
4. Do not use `/reload`. It leaves half-unloaded classes referencing objects that no longer exist, and produces bugs that look like anything except what they are. Plugin managers that claim to hot-swap jars have the same problem behind a nicer interface. Restart the server.
5. Read the generated config. First start creates plugins/<Name>/config.yml. Most plugins ship defaults tuned for a large public server, and most of you are not running one.
6. To remove one, stop the server, delete the jar, and decide about the data folder. Leaving plugins/<Name>/ behind costs nothing and means you can change your mind. Deleting it is permanent, and for something like CoreProtect it is your entire history.

/plugins lists what is loaded; anything printed in red failed to enable, and the reason is in the console from startup. Reading the console covers what else is worth noticing there.

The next six, once you have players#

Notes worth having before you install any of them.

EssentialsX is the maintained fork; the original Essentials has been abandoned for years and guides that link to it are old. Install the core plus only the modules you want - EssentialsXChat and EssentialsXSpawn are the common pair. Its protection modules overlap with WorldGuard and GriefPrevention, and running two protection systems produces arguments neither of them wins. EssentialsX, Vault and economies covers the money side, and if you plan to sell anything, read monetising within the rules before you set a price.

Chunky is the highest-value plugin on the list per minute of setup, because unpregenerated terrain is the largest single cause of "random" lag spikes on a survival server. Set a border, pregenerate inside it, and the spikes stop:

/chunky world world/chunky center 0 0/chunky radius 5000/chunky quiet 30/chunky start

Pair it with the vanilla world border so players cannot walk out of the pregenerated area. World borders and pregeneration is the full procedure, including the Nether, which people forget.

Web maps are the plugin category that most often surprises people with a bill in disk and I/O. Dynmap renders tile images and serves them on port 8123 by default; BlueMap builds a 3D model, serves on 8100, and is expensive during the initial render and cheap afterwards; squaremap is the lightweight 2D option. All of them need a second port allocation, which on this panel is a couple of clicks on the Network tab because the Minecraft plans ship with one. Dynmap, BlueMap and squaremap compared is the detail.

Anti-cheat deserves a warning rather than a recommendation. Packet-based anti-cheat is genuinely CPU-hungry, and CPU on a game plan is a hard share rather than a burst. It also produces false positives on high-latency players and on Bedrock players arriving through Geyser, because their movement rules are not the same. If you run one, run it in logging mode first and read what it would have done for a week before you let it kick anybody.

A backup that is actually consistent#

Minecraft holds the world in memory and writes it out periodically, so an archive taken mid-write can contain a torn region file. The fix is to flush first, and the Schedules tab is built for exactly this because tasks run in order with delays between them.

Set the schedule for an hour nobody plays, put save-all flush as the first task, a short delay as the second and the backup as the third. Before a version upgrade or a big plugin change, take one by hand and lock it so rotation cannot remove it. And restore one occasionally to prove it works, because a backup nobody has restored is a hypothesis - backups that actually restore is about the second half of that sentence, and scheduled tasks worth having covers the rest of what belongs on a timer.

The categories that cost you#

Some of these are individually defensible. All of them are common, and all of them are worth being suspicious of.

• Anything that scans on a timer. Entity counters, chunk sweepers, "lag reducers". They do work proportional to your world every few seconds whether or not anything has changed.
• Entity clearers. The ClearLag pattern - delete all dropped items every five minutes - hides the problem and deletes players' possessions. The actual fix is finding the farm or the quarry that is producing them. Paper can already merge items and limit spawns in spigot.yml and config/paper-world-defaults.yml without a plugin.
• Block loggers left on defaults. CoreProtect is worth having, but logging every container and item transaction on a busy server is a large write volume. Turn off the categories you will never look up, and run /co purge t:30d on a schedule.
• All-in-one plugins. A jar that bundles forty features so you can use three is thirty-seven features' worth of event handlers you did not ask for.
• Abandoned plugins. The most dangerous category, because they usually work until they do not. A plugin that has not been updated for your version may load, appear fine, and then break on a specific event or silently corrupt data. Check the last release date before you install, and check your whole list before a version upgrade.
• Multiple plugins doing one job. Two protection plugins, two chat formatters, two economies behind Vault. Whichever loads second usually wins, inconsistently.
• Extra loaded worlds. Multiverse is fine, but each loaded world keeps its own spawn chunks resident whether or not anybody is in it.

Proving which plugin is slow#

When TPS drops, resist the urge to remove things at random. The order that works:

1. `/mspt` first. If it is comfortably under 50, your problem is not sustained load - it is a periodic spike, and step 3 will find it.
2. `/spark profiler start`, play through the bad behaviour, `/spark profiler stop`. Read the flame graph from the widest bar down. Plugin names appear as their own package, so the culprit is usually obvious within thirty seconds.
3. `/spark profiler start --timeout 60` if the problem happens on a timer and you need a sample that stops and uploads itself.
4. `/spark heapsummary` if memory is the symptom. A plugin holding hundreds of megabytes of cached objects shows up here and nowhere else.
5. Only then start removing things, one at a time, with a restart between each. Removing five at once tells you nothing.

Remember that not every slowdown is a plugin. View distance, unpregenerated terrain, an entity farm and a CPU share that is simply too small all look like lag. Why TPS drops and what to do works through the non-plugin causes, and a server pinned at its CPU limit is slow rather than broken.

FAQ#

How many plugins is too many?

There is no number. Thirty light plugins can cost less than three heavy ones. The measurement that matters is MSPT: if it is under about 35 with your usual player count online, you have room. If it is near 50, you have none, regardless of how many jars are in the folder.

Do plugins use a lot of RAM?

Rarely. Most cost a few megabytes of classes plus their caches. The exceptions are web maps, block loggers with large in-memory queues, and anything that caches region or chunk data. What plugins really consume is main-thread time.

Can I install plugins without restarting?

You can, and you should not. /reload and hot-swap plugin managers leave stale classes behind and cause bugs that are extremely hard to diagnose. Upload the jar, then restart. It takes fifteen seconds and saves an evening.

Will plugins work on a Fabric or Forge server?

No. Plugins target the Bukkit and Paper API, which the mod loaders do not implement. A few familiar tools have separate mod versions - LuckPerms and spark among them - but the ecosystem does not transfer. Paper, Fabric or vanilla covers that decision.

Which plugin should I install first?

LuckPerms, before anything else. Almost every other plugin's configuration assumes a permissions system exists, and retrofitting one after you have handed out operator to five people is more work than doing it on day one.

Do I need a backup plugin?

Not if your host does backups off the machine. A plugin writing archives to the same disk protects against a corrupted world file and nothing else - not a deleted server, not a bad restore, not a mistake with the file manager. Use panel backups and schedule a save-all flush before them.