Purpur vs Paper: Should You Switch Server Software?

Purpur is a Paper fork, so switching to it doesn't make your server faster. It inherits every Paper optimization and 100% of Paper's plugin compatibility, then adds hundreds of extra gameplay and config toggles on top. That's the whole pitch: configurability, not performance. Here's the honest rule to keep in your head before you download anything: if you never open purpur.yml, running Purpur is functionally identical to running Paper. So switch only if you actually want some of the mechanic toggles it exposes. If you don't, stay on Paper and keep the bigger support community.

What Purpur actually is (a Paper fork, not a rival)

The server software family runs in a straight line: CraftBukkit came first, then Spigot forked it, then Paper forked Spigot, and Purpur forks Paper. Each step down that chain keeps what came before and adds to it. So Purpur is not competing with Paper the way Paper competes with Fabric — it is Paper, plus a config file.

That makes it a drop-in replacement in the literal sense. Any plugin that runs on Bukkit, Spigot, or Paper runs on Purpur unchanged, and it still reads all the same config files you already know: bukkit.yml, spigot.yml, and Paper's paper-global.yml and paper-world-defaults.yml. Your plugins still live in the plugins/ folder. The only genuinely new thing Purpur brings is one extra file, purpur.yml, sitting alongside Paper's config. Everything Purpur does that Paper doesn't happens in that file.

What Purpur adds on top of Paper

purpur.yml is a long menu of gameplay and mechanic switches — hundreds of them — that Paper simply doesn't offer. A couple of concrete, commonly-cited ones give you the flavor:

• Rideable mobs: let players hop on and steer mobs that are normally passengers-only in vanilla.
• Single-player sleep: one person in bed skips the night for the whole server, instead of needing the vanilla percentage of players asleep.

Beyond those two, it's a big pile of smaller knobs — mob behavior tweaks, drop and spawn adjustments, and other quality-of-life toggles — that let you bend individual mechanics without writing a plugin or a datapack for each one.

The important part, and the thing people miss: every one of these is off by default. A fresh Purpur server behaves exactly like vanilla-plus-Paper until you go into purpur.yml and flip something. Purpur doesn't change how your server plays out of the box. It just hands you the switches. If the mechanics you want to change happen to be in that file, great — you've saved yourself a plugin. If they aren't, the file does nothing for you.

What Purpur does not add: performance

Purpur is not "faster Paper," and this is the misconception worth clearing up. It runs the same engine Paper does, so it inherits Paper's TPS and gives you nothing extra out of the box. If your server is lagging on Paper, it will lag the same on Purpur, because the tick loop is the same code.

If you want actual performance gains, they come from the usual places — tuning your view distance and simulation distance, sorting out your JVM flags, and cutting entity load — not from the jar you're running. Purpur can't out-optimize the project it's forked from. Anyone telling you to switch to Purpur "for more TPS" has it wrong; the real advantage is configurability.

The cost: smaller community and tracking Paper's updates

Purpur is a smaller project than Paper, and that shows up in two ways.

First, it lags Paper's release schedule a little. Every time Paper ships a new build, Purpur has to re-fork and re-apply its changes on top before it can release a matching build. That's usually quick, but it means Purpur can trail Paper by a bit right after a big Minecraft version bump. If you insist on being on the newest build the day it drops, Paper gets you there first.

Second, the support base is thinner. When you hit a weird problem on Paper, half the internet has already hit it and written the answer down. On Purpur you're drawing from a smaller pool of people and docs. It's a good project with real documentation, but it's not the default everyone else is running, so troubleshooting help is scarcer.

Neither of these is a dealbreaker. They're just the trade you make for the extra config file.

Who should switch, and who should stay on Paper

Switch to Purpur if you look through what purpur.yml controls and see a mechanic you actually want to change — single-player sleep on a small survival server, rideable mobs for a goofy event night, whatever fits your world. If the toggle you want is in that file, Purpur is the cleanest way to get it, and you lose nothing by using it since it's still Paper underneath.

Stay on Paper if you read that same file and nothing jumps out, or if you'd rather sit on the largest support community and the fastest update track. New owners in particular should probably start on Paper: it's the baseline everything is written against, and you can always move to Purpur later in about five minutes if a reason comes up. Don't switch just because Purpur exists or because a video called it "better." Switch because there's a specific switch you want to flip.

How to switch (it's a jar swap)

Moving from Paper to Purpur is a jar swap, nothing more. Your world and configs carry over untouched, and it's fully reversible.

1. Back up your world folder first. Copy the whole level-name directory somewhere safe. This should be routine anyway — here's how to back up a server if you don't have a habit yet.
2. Stop the server cleanly with the stop command in the console, so everything saves. Don't just kill the process.
3. Drop the Purpur jar into the same folder and delete or set aside the old Paper jar. Grab the build from Purpur's download page rather than trusting a memorized version number — Purpur tracks Paper's Java requirement, so newer drops want Java 25 and older ones want Java 21, and the download page tells you which.
4. Relaunch with the same command, just pointed at the new jar: java -Xms4G -Xmx4G -jar purpur.jar --nogui. Keep it in the same folder pointed at the same level-name so it loads your existing world and configs.

Once it's up, run /version (alias /ver) in-game or the console. You'll see something like This server is running Purpur version <build> (MC: <version>), which confirms the swap took. If you set up your Paper server from the standard install steps, nothing else about your setup changes. To go back to Paper, stop the server and swap the jar the other direction. The purpur.yml file just sits there ignored once Paper's running again.

FAQ

Do my players need to install or change anything?

No. Purpur is a server-side change only. Players connect with the same vanilla client, on the same 25565 port, exactly as before. They can't even tell you switched unless you turn on a toggle that visibly changes gameplay.

How do I confirm my plugins loaded after the swap?

Run /plugins (alias /pl) right after you relaunch. Because Purpur keeps Paper's full plugin API, you should see the exact same list you had before, all enabled. If one shows red, it failed to load for its own reasons — not because of Purpur — so check its console line the same way you would on Paper.

Is there any downside to just running Purpur "in case"?

Yes, a small one: running with an untouched purpur.yml gets you the costs of the switch — slightly slower updates, thinner community support — and none of the benefit, since you're not using a single toggle. It won't hurt your server, but there's no reason to take on the trade until you have a specific mechanic you want to change.