Must-Have Paper Plugins for a New Minecraft Server

A fresh Paper server trusts everyone the same way: every player can build anywhere, nothing gets logged, and there's no way to undo damage once it's done. The right handful of plugins is what lets a server survive its first griefer instead of getting torn up overnight. So before you open the doors, you want a small, deliberate set of plugins covering the jobs vanilla leaves wide open.

This is organized by job, not by brand. The category you need — something to manage permissions, something to log grief — is permanent, while the specific plugin filling that slot changes over the years as projects come and go. Pick one solid option per category, configure it properly, and you've got a foundation that holds up. The six jobs that matter on day one are permissions, anti-grief, anti-cheat, world management, performance, and voting. The only purchase anywhere in here is owning the base game so you can log in and test your own server.

Paper plugins are server-side .jar files. They go in your plugins/ folder, load on restart, and write their config the first time they run. Players don't install anything — they just connect. And a stable, well-moderated server is what keeps players around, which is what climbs the monthly vote board, so it's worth understanding how the rankings work before you build.

How to think about plugins on a new server

The install model is the same for everything below: drop the .jar in plugins/, restart the server, let the plugin generate its config, then edit that config. Once you've done it once you've done it for all of them.

The one rule that saves the most headaches is one plugin per category. Two anti-cheats, two permission managers, two block-loggers — running duplicates makes them fight each other, and you get behavior nobody can explain. Choose one per job and configure it well. Some plugins also depend on others being present (a permissions plugin, or a compatibility bridge so they can read group and economy data), so install the foundation pieces first and the rest will find what they expect.

Start minimal. A new server with five well-chosen plugins is healthier than one with fifty half-configured ones. Every plugin you add is a little more CPU, a little more memory, and one more thing that can break on the next Minecraft update — so keep them current and matched to the version you actually run. If you're not sure about update timing, do plugins break on Minecraft 26.2 covers when it's safe to move.

Permissions: deciding who can do what

Out of the box you've got two kinds of people: normal players and full operators. There's no middle. So if you want to give a helper the power to mute someone, you'd have to hand them everything, which is how new servers end up with five people who can ban each other.

A permissions plugin fixes that by letting you define ranks and groups, then grant or deny individual command and feature permissions per group. That's how you build a real staff hierarchy — helper, mod, admin — where each tier has exactly the powers it should and nothing more. It's the first thing you install, because almost every other plugin gates its commands behind permission nodes; without a permissions manager you can't cleanly hand out moderation tools or lock down the commands people abuse.

Before you open to the public, set up at least a default player group and one or two staff groups. Keep operator (op) status to yourself and run everyone else through permission nodes instead. LuckPerms is the standard here, and it's the one most other plugins assume you're using. Depending on what else you install, you may also need a small compatibility bridge so plugins can read your group and economy data.

Anti-grief: surviving the first griefer

Owners tend to lump two different jobs together under "anti-grief": cleaning up damage after it happens, and stopping it from happening at all. A healthy server usually wants both.

The cleanup side is block-logging and rollback. A logging plugin records every block placed and broken, every chest opened, every block set on fire — who did it and when. So when you find a griefed area, you look it up and roll it back in seconds instead of rebuilding by hand, and you can actually prove who was responsible. Without it, grief is permanent and anonymous. CoreProtect is the standard tool for this.

Prevention is the other half, and it comes in two pieces. A region plugin lets you lock down spawn, carve out staff-only zones, and set per-area flags like no build, no PvP, or no mob spawning — so your hub stays safe no matter who joins. WorldGuard is the usual pick there. On survival especially, you also want player-driven land claims: a claim plugin lets people protect their own builds by claiming the ground around them, which cuts down the "someone griefed my house" tickets and lets your moderation scale. GriefPrevention is the common choice. Run a logger plus a region plugin plus claims together on a survival server and you've covered the whole problem — the live survival rankings are a good look at what grief-resistant communities feel like once this is in place.

Core gameplay commands: the everyday utilities

Vanilla doesn't have homes, warps, /spawn, teleport requests, kits, or any chat formatting, and players on a public server expect all of it. A core-commands plugin fills that gap with /home and /sethome, /warp, /tpa teleport requests, /spawn, private messages, and chat and name formatting that reads from your permission groups.

That last part is why it pairs with permissions: most of these commands should be gated — number of homes per rank, who can use what — and that only works once a permissions plugin is in place. EssentialsX is the standard here, and it's modular, so you load the chat, spawn, and protect add-ons you want and leave the rest. Configure kits and perks around gameplay convenience and rank, things that make the server nicer to play. The plugin's job in this slot is player comfort.

Anti-cheat: keeping the playing field honest

Hacked clients — fly, speed, reach, killaura, X-ray — wreck PvP and quietly poison survival economies, and vanilla does almost nothing about them server-side. An anti-cheat watches player movement and combat at the packet level, flags or blocks the impossible stuff, and gives staff alerts and logs so you can actually catch and ban the cheater rather than guess.

Be careful which one you pick. The long-standing NoCheatPlus has stalled in development and current cheat clients walk right past it, so it's not a live option anymore even though you'll still see it recommended. The actively maintained, packet-level choices are the ones that track recent Minecraft versions — Grim is free and open-source, and Vulcan is another. Run exactly one of them. Two anti-cheats will double-flag the same actions and fight each other, which produces false bans and a flood of noise; this is the category where one-per-job matters most.

Whichever you choose, plan to tune it. Every anti-cheat needs its config dialed in to your tick rate and game modes to avoid false positives, so budget time before launch to get it right — especially on a PvP server, where a twitchy anti-cheat punishes your best players. The PvP rankings are where that tuning shows up most.

World management: keeping the map under control

An unbounded world keeps generating fresh terrain forever as players push outward. That bloats your disk and, worse, causes live-generation lag exactly when players are at the frontier exploring — the moment you'd least want a stutter.

A world border fixes the size problem. Set one per dimension (Overworld, Nether, End) and the map has a finite edge, which caps disk growth and gives the next step something to aim at. Paper has a built-in border, and plugins extend it. The next step is chunk pre-generation: a pregen tool walks the map out to the border and generates every chunk ahead of time, asynchronously, so the heavy work of building terrain is done before anyone reaches the edge. Chunky is the standard tool, and you run it during off-peak hours so it isn't competing with players for resources.

Multi-world is optional but common once you grow. A world-management plugin lets you run separate worlds with their own rules and gamemodes — a resource world you reset every so often, a creative plot world, a minigame lobby. A border plus pregeneration is one of the highest-impact things a new server can do for smoothness; how much RAM for a 20-player server goes deeper on pregen and view distances if you're sizing the box.

Performance: measuring before you optimize

You can't fix lag you can't see. Before you start pulling plugins or buying more RAM on a hunch, install a profiler. A tool like Spark measures TPS, CPU, and memory in real time and produces a shareable report that points at exactly which plugin, entity, or chunk is eating ticks — and it works across Paper, Spigot, Fabric, and Forge.

That beats guessing every time, because the laggiest thing on a server is usually one specific culprit: a runaway mob farm, a hopper cluster someone built, a single misbehaving plugin. A profiler names it in minutes instead of an afternoon of trial and error. Be wary of "lag-fixer" plugins that aggressively clear entities — they break farms and frustrate players, and they treat the symptom. Prefer Paper's own config tuning (view and simulation distance, entity limits) plus a profiler to find the real cause, and keep blanket clearlag tools as a last resort. Nobody notices good TPS; everybody notices a server that stutters, and stable TPS and uptime are a big part of what keeps a community coming back to vote.

Voting: connecting your server to the rankings

A new server is invisible until players find it, and on a vote-ranked list your monthly vote count decides your position — so you need to actually receive those votes. NuVotifier, the maintained successor to classic Votifier, is what does that. It opens a dedicated port and securely receives signed vote notifications from server lists, then fires an internal event. It runs on Paper going back many versions.

The catch is that NuVotifier receives and verifies the vote but never rewards anyone on its own. A separate vote-listener plugin has to act on that event to thank the player in-game, so install only NuVotifier and the votes arrive while nothing happens. On the network side, the Votifier port defaults to 8192 and is separate from your game port (Java 25565, Bedrock 19132); it has to be reachable from the internet, and the key or token mode on your server has to match what the listing expects. The full walkthrough — keys, ports, v1 versus v2, testing, and the "votes not received" troubleshooting — lives in how to set up NuVotifier for vote rewards, so treat this as the overview and go there for the steps.

A minimal starting stack

The launch checklist is one pick per category: a permissions manager, a block-logger paired with a region or claim plugin, a core-commands plugin, one modern anti-cheat, a world border plus a pregen tool, a profiler, and a voting plugin with a listener behind it.

Install in order. Foundation first — permissions and any compatibility bridge — because other plugins lean on it. Then anti-grief and commands, then anti-cheat and world tools, and voting last once the rest is settled. Resist the urge to bolt on dozens of feature plugins on day one. Get the foundation stable, open to a small group, run the profiler, and grow the plugin list deliberately as your community actually asks for things.

A server that's stable, fair, and grief-resistant retains players, and retention is what produces the votes that move you up. If you want a benchmark for what a healthy foundation looks like in the wild, the rankings and the survival category are the place to look. Pick by job, run one per category, configure before you launch — that's the whole foundation a new Paper server is built on.

FAQ

Do players need to install these plugins too?

No. Paper plugins are server-side only — they live in your server's plugins/ folder and run on the server. Players just connect with a normal Minecraft client and everything (permissions, protection, anti-cheat, vote rewards) happens on your end. The one purchase involved anywhere is owning the base game so you can log in and test your own server.

Spigot, Bukkit, Paper — will plugins built for one work on the others?

Mostly yes, in one direction. Paper is a fork of Spigot, which is a fork of Bukkit, so the plugin API is shared and the vast majority of Bukkit and Spigot plugins run on Paper unchanged. A handful are written specifically against Paper's extra API and won't load on plain Spigot or Bukkit. Because Paper adds performance improvements on top of that broad compatibility, it's the usual choice for a new server — and every category here has a well-maintained option that runs on it.

Which plugins should I hold off on at launch?

The feature stuff. Custom enchants, fancy cosmetics, mini-game frameworks, GUI shops, anything that adds a system players didn't ask for yet — those can all wait until you know what your community actually wants. The day-one list is the boring infrastructure that keeps the server safe and stable. As a rough sense of scale, most healthy small servers run somewhere around eight to fifteen plugins early on, almost all of them from the categories above, and grow the list slowly from there.

A plugin failed to load after I updated Minecraft. What now?

That's the usual outcome of updating too early: a plugin compiled for an older version can refuse to load until its author posts an update, and you'll see it flagged in the console on startup. Check that plugin's page for a build that matches your new version, and if there isn't one yet, roll back or wait. The real fix is to never update the live server first — test the version on a copy of your world, confirm every core plugin loads, and only then move the real one across.