Paper vs Spigot: Which Should You Run?

They are the same server with different amounts of optimisation

Paper took Spigot's code base and added performance work across the tick loop: entity ticking, chunk loading, redstone scheduling, packet handling and the many small paths where vanilla does more work than it needs to. Those changes are invisible to players. They show up as a server that holds 20 ticks per second on hardware Spigot cannot.

Paper also continues to release builds for new Minecraft versions. It is the fork with the active upstream work, not the smaller of two maintained projects.

The worlds and plugins are identical, so switching is a restart

Both projects use the vanilla world format and the Bukkit plugin API. A Paper server can run a Spigot-built plugin, and a Paper world can be opened by Spigot, because nothing about the data changed.

That makes the decision almost free to reverse: change the software in your panel, restart, and your players join with no download. Installing Paper walks through it, and take a backup first so any surprise is one click away from undone.

Where the difference actually shows up

In every case where the server is the bottleneck rather than the player's machine: a busy mob farm, a large explored world, a plugin doing heavy work, many chunks loading at once. Paper holds its tick rate where Spigot drops below it, which is the entire argument for it.

On a small server with two players and a small world, you may not notice a difference at all. That is a fair reason to not think about it, and not a reason to prefer Spigot.

What a player notices, or does not

Nothing. Paper makes no gameplay change: redstone, mechanics, world generation, commands and the vanilla client all behave identically, which is why the switch does not require anyone to install anything. The difference is only in how much of each second the server can give you.

The other thing Paper adds over Spigot is its own configuration layer: two files of documented, per-world overridable settings that let you cap entity spawning, trim loading and limit work. Spigot offers fewer of those controls, because the performance work that makes them useful is the work Paper added.

The one real migration cost

A few plugins call APIs that Paper has deprecated, and those log warnings or fail to load on Paper. The list is short and shrinking, but it is the thing that makes a migration fail, so check it before you start: read the startup log on Paper and see what complains.

Configuration also moves in one direction only in appearance: Paper inherits spigot.yml and server.properties, so your old settings still apply, and Paper adds files rather than replacing them. There is nothing to port and nothing to re-enter.

/version

The reasons to still run Spigot

There are two honest ones. First, a plugin you depend on calls APIs Paper has removed and has no Paper build. Check the plugin's page and issue tracker first, because the answer is often a newer version rather than a different server software. Second, an organisation that requires unmodified upstream code for licensing, audit or support reasons has to run Spigot itself.

Everything else people give as a reason does not hold up. Spigot being closer to vanilla is not one of them: Paper does not change gameplay either, and vanilla vs Paper makes that case properly.

Good to know

• Neither project is a paid product and neither has a premium edition. Paper is free software maintained in the open, as is Spigot.
• Purpur is a further fork of Paper with optional gameplay additions. If the question is Paper versus anything, Paper vs Purpur is the other comparison worth reading.
• The Paper hub collects the install, configuration and tuning guides in reading order.

Common questions

Sources

Official documentation this guide was checked against.

• PaperMC documentation
• PufferHost knowledge base: Paper
• PufferHost knowledge base: Spigot