Paper, Spigot or Vanilla?

The short answer

For most people running a server with plugins, Paper is the sensible default. It runs Spigot plugins, adds performance work and ships a ready-to-run JAR. Spigot matters when a specific plugin only works there. Vanilla matters when you want no plugins at all.

Vanilla: the official server

Vanilla is the server JAR published by Mojang. It matches the client exactly, so redstone, mob behaviour and world generation are the reference implementation. It has no plugin API and no configuration beyond server.properties and the game rules.

If you only want to play survival with friends and never install a plugin, Vanilla is the least surprising choice. The trade-off is that you cannot add permissions, economy, anti-cheat or quality-of-life tools, and a large world with many players will use more CPU than the same world on Paper.

Spigot: the plugin baseline

Spigot is a fork of CraftBukkit and the origin of the Bukkit/Spigot plugin API that most plugins target. A JAR built against the Spigot API expects the classes and events that Spigot provides. That is why Spigot is the compatibility baseline: if a plugin says it supports Spigot, it will usually run on Spigot.

Spigot includes performance patches over Vanilla, but it is conservative. It does not distribute prebuilt JARs from its own site; builds are produced with BuildTools from source. That extra step is one reason people move to Paper, which publishes builds directly.

Paper: Spigot plus performance

Paper is a fork of Spigot. It keeps the Spigot plugin API, so Spigot plugins generally run unchanged, and adds optimisations: asynchronous chunk loading, better entity and hopper handling, configurable behaviour and a large set of bug fixes. On a busy server the difference in tick rate is usually noticeable.

Paper also publishes builds you can download and run directly, which removes the BuildTools step. Its configuration files are more detailed than Spigot's, so there are more knobs to tune and more places to make a mistake. The defaults are sane; change them only when you have a reason.

Forks: Purpur and friends

Purpur is a fork of Paper that exposes extra gameplay and configuration options. Other forks exist for specific needs such as proxies or large networks. A fork inherits the plugin API of its parent, so a Paper plugin usually runs on Purpur.

Forks are not automatically better. Every layer adds its own update cadence and its own bugs. If you do not need a fork's specific features, staying on Paper means fewer moving parts when a new Minecraft version lands.

Why Paper is faster

The performance difference is not one trick. It is a long list of small changes:

• Chunk work is spread out. Loading and saving chunks is handled with less main-thread blocking.
• Entity and hopper logic is cheaper. Large farms and item piles cost less per tick.
• Pathfinding and AI are tuned. Mobs spend less CPU when many are loaded.
• Network handling is improved. Player movement packets are processed with less overhead.
• Configurable limits. You can cap behaviours that a specific world does not need.

None of this fixes a bad setup. If the server has 2 GB of RAM for 20 players, or the world sits on a slow disk, Paper will still struggle. Performance software buys headroom; it does not replace adequate hardware.

Plugin compatibility in practice

Compatibility runs in one direction more than the other:

• Spigot plugin on Paper: usually works. Paper keeps the Spigot API.
• Paper plugin on Spigot: may fail if it imports Paper-only classes.
• Bukkit plugin on either: usually works, but very old plugins can break on new Minecraft versions.
• Plugin on Vanilla: does not work at all. Vanilla has no plugin loader.

The Minecraft version matters as much as the server type. A plugin built for 1.21.x will not load on 1.20.x regardless of whether the server is Paper or Spigot. Check the plugin card or its documentation before you download.

How to choose

1. No plugins, just survival with friends: Vanilla is enough.
2. You need plugins and want the simplest path: Paper.
3. A plugin explicitly requires Spigot and fails on Paper: Spigot.
4. You want Paper plus extra gameplay toggles: Purpur, if you accept the extra layer.
5. You run a network with a proxy: Paper behind Velocity or BungeeCord is the common setup.

The FerNode plugins (UltraTreeFeller, AutoRefill and FerKunG Stacker) are Bukkit-style plugins. They run on Paper and Spigot. They do not require a fork and they do not use Paper-only API.

Java versions

The FerNode plugins are compiled for Java 17 or newer. That is the minimum for the plugins themselves. The server software can require more: recent Paper and Minecraft releases need a newer runtime than older versions did.

Check the requirement for the exact server build you download. If the server refuses to start with an UnsupportedClassVersionError, the runtime is too old. Install a current 64-bit JDK (Temurin 21 is a common choice) and point the server or FerNode at it.

Switching server software safely

1. Stop the server and confirm it has exited.
2. Back up the world folders and plugins/.
3. Keep the old server JAR; you may need it to roll back.
4. Download the matching build of the new software for the same Minecraft version.
5. Replace only the server JAR. Keep server.properties, world/ and plugins/.
6. Start once and read the console for plugin errors before inviting players.

Going from Spigot to Paper is the low-risk direction. Going from Paper to Spigot can break Paper-specific plugins and Paper configuration files, so test on a copy first if the world matters.

The takeaway

Use Paper unless a concrete reason stops you. It is the pragmatic default for a plugin server: Spigot compatibility, better performance and a direct download. Use Vanilla when you want the reference game with no add-ons, and Spigot when a specific plugin demands it. Whichever you pick, match the Minecraft version to your plugins and back up before you switch.

Proxies and multi-server networks

A proxy such as Velocity or BungeeCord sits in front of several Paper servers. Players connect to the proxy, and the proxy sends them to a backend server. This is how networks offer a lobby, survival and minigames with separate worlds.

A single server does not need a proxy. If you add one, the network changes the security model:

• The proxy handles authentication. Backend servers usually run with online-mode=false and accept only connections forwarded by the proxy.
• Backend ports must not be public. If players can reach a backend directly, they can bypass the proxy's checks.
• Forwarding must match. Velocity modern forwarding and legacy BungeeCord forwarding are configured differently; mixing them causes "invalid session" or "not authenticated" errors.
• Use one Paper build across backends. Mixed versions complicate plugins and world transfer.

Velocity is the current choice for new networks; BungeeCord still works but is older. Both expect Paper on the backend. Set this up only when you actually need more than one server, because it adds a component that can fail on its own.