Why PaperMC Left Spigot Behind for Server Owners

For nearly a decade, the path to launching a modified multiplayer Minecraft instance began with Spigot. As the primary successor to CraftBukkit, Spigot established the modern conventions of plugin administration, entity tracking distances, and chunk generation ceilings. Over recent release cycles, however, that dynamic shifted permanently. What was once viewed as a community fork for performance-focused tinkerers has become the de facto standard, while Spigot has slipped into maintenance status.

PaperMC has separated itself from its roots by moving beyond simple micro-optimizations. The project no longer merely patches bottlenecks in Spigot's codebase; it fundamentally replaces Minecraft's internal architectures to keep servers performant under modern load demands.

The Technical Divergence

Historically, running Spigot meant accepting the limitations of the single-threaded server tick loop. The platform introduced configuration knobs to reduce tick rates for inert entities and cull unnecessary computations, but the underlying work remained largely serial. Paper tackled this issue by dismantling the standard chunk system entirely.

Through successive rewrites of world-loading code—culminating in modern asynchronous chunk management—Paper decoupled world input/output, generation, and chunk serialization from the central game thread. Where an unassisted Spigot instance would experience severe tick rate degradation whenever multiple players flew through ungenerated terrain using Elytra, Paper isolates that work onto background worker pools. The main thread continues processing combat, redstone, and plugin logic with minimal disruption.

Alongside threading changes, Paper altered the baseline expectations of vanilla compatibility. Bukkit and Spigot long held a philosophy of adhering as closely as possible to vanilla mechanics, outside explicit performance tweaks. Paper diverged by treating exploits, memory leaks, and unintended tick order quirks as engineering bugs that demand resolution. While this occasionally broke fragile, unmaintained community plugins, it ensured server stability across high-density environments.

The Workflow Difference

Beyond runtime behavior, operational ergonomics widened the gap between the two platforms. Spigot still relies on the BuildTools compilation pipeline. To legally produce a runnable spigot.jar, an operator must run a local tool that pulls Mojang's vanilla server files, downloads external dependencies, deobfuscates bytecode, and applies Spigot's patches on the local machine. This process was engineered to circumvent copyright claims following the CraftBukkit DMCA incident in 2014.

Paper eliminated this friction by distributing pre-patched binaries directly. By utilizing modern runtime patching and clear legal separations, Paper distributes standard executable files directly through an automated pipeline. Continuous integration builds are available minutes after a commit lands. For hosting providers, automated container deployments, and operators running orchestrators like Docker, managing Paper requires downloading a single file via an API endpoint, rather than maintaining build environments on deployment nodes.

This usability extends to the server administrator's config directory. Modern Paper instances condense settings into organized, version-controlled formats, abandoning the sprawling and duplicated settings split between bukkit.yml and spigot.yml. Settings for anti-xray obfuscation, entity limits per chunk, and redstone algorithms exist natively inside Paper's configuration trees without requiring third-party additions.

API Evolution and Plugin Ecosystems

For developers, the baseline Bukkit API has proven too restrictive for modern features. Paper expanded the API footprint considerably, adding events and accessors that allow plugins to interact with newer engine features without resorting to brittle reflection or direct Netty networking calls.

Features such as Adventure—the modern text and component library—are built directly into Paper. Developers targeting Paper can utilize rich text formatting, hover events, and native client translation keys cleanly, while developers targeting Spigot often need to shade external translation libraries into every jar file. Many high-profile plugins now treat the Paper API as a hard dependency, refusing to initialize if loaded on a plain Spigot server.

This division has also reshaped public server hosting. According to measured player counts across Minecraft servers, the majority of large installations handle player activity using customized forks built atop Paper, rather than vanilla or base Spigot code. In public environments like Minecraft SMP servers, where players group together and construct automated farms, running on vanilla logic without Paper's entity tracking fixes often makes stable uptime impossible. Even in purist configurations found on Minecraft vanilla servers, administrators running Paper to maintain tick rates must explicitly toggle Paper's vanilla-faithfulness options to restore standard behavior.

When Spigot Still Applies

The cases where Spigot remains preferable to Paper have dwindled to edge scenarios. Legacy networks with deeply entrenched, custom-built proprietary software sometimes encounter incompatibilities with Paper's internal refactoring. If an older plugin relies on private fields within Mojang's raw code or depends on tick timings that Paper has altered, running Spigot provides the older behavior without requiring a full code audit.

Outside legacy preservation, Spigot acts primarily as an upstream base. Paper and its derivatives pull changes from Spigot, meaning the Spigot project still performs valuable work in maintaining base Bukkit compatibility for the wider developer ecosystem. However, treating Spigot as the production runner on an active public server has become an active disadvantage. Paper provides better resource utilization, automated deployment, and ongoing security fixes, making it the practical starting point for any contemporary setup.