Purpur and Pufferfish are both forks of Paper that run the same plugins and load the same worlds. Purpur adds hundreds of gameplay switches in a file called purpur.yml - ridable mobs, six-row ender chests, silk-touch spawners, villager behaviour - and otherwise behaves like Paper. Pufferfish adds performance patches, the best known being Dynamic Activation of Brain, which ticks distant mobs' AI less often. Neither is a magic speed-up: Purpur exists for the knobs, Pufferfish trades a little vanilla accuracy for tick time, and both put you one step further from the project that fixes Minecraft's security and stability bugs first. If you do not need a specific feature from one of them, plain Paper is still the right default.
Where the forks sit in the family tree#
Minecraft server software is a chain of forks, and understanding the chain explains every risk later in this post.
Each project takes the one above it and applies its own patches. When Mojang releases a new version, Spigot updates, then Paper, then the forks rebase their patches on the new Paper. A fork can only be as current as the thing it is built on, and it is often later.
Purpur has, for most of its history, been built on top of Pufferfish's patches rather than directly on Paper, which is why it has some of Pufferfish's optimisations as well as its own options. That relationship has shifted between Minecraft versions, so read the generated config files of the build you actually download rather than assuming which features it carries.
Two practical facts follow from the tree. First, every plugin that runs on Paper runs on both forks, because both keep the Paper API intact. Second, a plugin that uses Purpur's own extended API runs only on Purpur, not on Paper - rare, but worth checking before you depend on one.
Purpur: Paper with the switches exposed#
Purpur's pitch is configurability. It adds a large purpur.yml beside Paper's files, and almost every option in it defaults to vanilla behaviour, so installing Purpur and changing nothing gives you a server that plays like Paper. You opt in to each change.
A small selection of the options people actually use:
settings: use-alternate-keepalive: false blocks: barrel: rows: 3 ender_chest: six-rows: falseworld-settings: default: mobs: villager: lobotomize: enabled: false check-interval: 100 phantom: ridable: false| Option | Default | What it changes |
|---|---|---|
settings.blocks.barrel.rows | 3 | Barrel inventory size, 1 to 6 rows |
settings.blocks.ender_chest.six-rows | false | Doubles the ender chest |
settings.use-alternate-keepalive | false | Sends keepalives more often, can help flaky connections |
mobs.<mob>.ridable | false | Lets players ride that mob with a saddle |
mobs.villager.lobotomize.enabled | false | Turns off AI for villagers that cannot move |
The ridable switches are per mob, which is why purpur.yml is so long - nearly every mob has its own block of settings for riding, health, spawning and behaviour. Purpur's own documentation lists them all, with the exact key names for the version you run. Search that page rather than guessing a key: Purpur silently ignores a misspelt option, and the server starts as if you had changed nothing.
Two options deserve a closer look because they change how the server performs, not only how it plays.
Villager lobotomisation. A trading hall full of villagers locked in one-block cells is one of the most expensive things a survival server hosts, because every villager still runs its pathfinding and job-site logic every tick. With lobotomize.enabled: true, a villager that cannot move has its AI switched off, and check-interval controls how often Purpur re-checks whether it is still trapped. Trading still works, but exactly what a lobotomised villager still does - restocking in particular - has changed between versions, so test with one villager before converting a whole hall. On a server with several large trading halls this is one of the cheapest real wins available.
Alternate keepalive. The vanilla server sends a keepalive packet at a fixed interval and disconnects a player whose one reply arrives too late. Purpur's alternative sends them more often and only disconnects if none of them are answered within the timeout, which reduces "Timed out" kicks for players on unstable connections. It does nothing for latency.
Purpur also adds commands vanilla and Paper do not have, such as /tpsbar, /rambar, /ping and /uptime. They are useful, and they are another thing your staff will miss if you ever go back to Paper.
Pufferfish: performance patches with trade-offs#
Pufferfish is the successor to Airplane, an earlier performance fork, and is maintained by a hosting company of the same name. It keeps the Paper API and focuses on tick time. Its settings live in pufferfish.yml:
dab: enabled: false start-distance: 12 max-tick-freq: 20 activation-dist-mod: 8 blacklisted-entities: []enable-async-mob-spawning: trueenable-suffocation-optimization: trueinactive-goal-selector-throttle: trueDynamic Activation of Brain (DAB) is the headline feature. Minecraft's newer mobs - villagers, piglins, axolotls, goats, frogs and others - use a "brain" system that is expensive to tick. DAB reduces how often a mob's brain ticks the further it is from the nearest player. Inside start-distance (in blocks) mobs behave normally. Beyond it, the interval between brain ticks grows with distance, divided by activation-dist-mod, up to a ceiling of max-tick-freq ticks. Mobs in blacklisted-entities are never throttled.
The trade-off is in the name. A villager 40 blocks from the nearest player thinks less often. For most survival play nobody notices. For technical players with an iron farm, a villager breeder or a raid farm that relies on mobs making decisions at a distance, DAB can slow or break the design. The fix is either to raise start-distance, to blacklist the entity type the farm depends on, or to switch DAB off.
Async mob spawning moves part of the natural spawning work off the main thread. It does not change spawn rules, but it changes timing, and very precise spawn-proofing tests occasionally disagree with vanilla.
Inactive goal selector throttle makes entities outside their activation range run their older-style AI goals less often. It overlaps with Paper's own entity activation range settings in spigot.yml - which you should tune first, because they apply on Paper too.
Be honest about the size of the gain. On a server where entity AI is the bottleneck - lots of villagers, piglin farms, mob grinders - Pufferfish's patches can recover a meaningful share of each tick. On a server where the bottleneck is chunk generation, plugins, redstone or view distance, they change little. A spark profile shows which case you are in: if Villager and Brain frames dominate, Pufferfish is worth a test; if they do not, it is not.
The risks of running a fork#
None of these are reasons to never run Purpur or Pufferfish. They are the costs to weigh against the feature you want.
- Version lag. A new Minecraft release reaches Paper first, then the forks. Players with updated clients cannot join until your server catches up, unless you run ViaVersion to bridge the gap. Pufferfish's free builds in particular have, at times, trailed Paper by a long way.
- Security and crash fixes arrive later. When Paper patches a crash exploit or a dupe, the fork has to rebase before you get it. Usually that is hours or days. Occasionally it is longer.
- Support goes to the fork, not to Paper. Paper's developers will not debug a problem on Purpur or Pufferfish, and reasonably so - they cannot tell whether the fork's patches caused it. Reproduce bugs on plain Paper before reporting them upstream.
- Behaviour drift. Every option you turn on is a difference from vanilla that players, tutorials and farm designs do not expect. Ridable phantoms and six-row ender chests are fun; a farm design that silently fails because of DAB costs your technical players an afternoon.
- Abandonment. Forks depend on a small number of maintainers. If one stops, you inherit a migration on its timetable, not yours.
- Deeper forks multiply all of the above. There are further forks of Purpur - Leaf, Gale, DivineMC and others - that stack more patches on top, often including experimental multithreading. Each step down the chain adds lag and removes support. They can be fast; they are also where obscure bugs live.
Choosing: Paper, Purpur or Pufferfish#
| You want | Run | Why |
|---|---|---|
| The safe default for any server | Paper | First to update, the reference for plugins and support |
| Gameplay options without plugins | Purpur | Ridable mobs, inventory sizes, mob behaviour, all in config |
| Less tick time on a mob-heavy server | Pufferfish or Purpur | DAB and related patches |
| Exact vanilla mechanics for technical play | Fabric with Lithium | Paper and its forks change edge cases |
| More players than one thread can handle | Velocity and several servers, or Folia | A fork does not remove the main thread |
The last two rows are the important ones. Technical players who care about exact redstone and farm behaviour are better served by Fabric with server-side performance mods, which keeps vanilla behaviour intact. And if you have outgrown a single thread, the answers are a proxy network or Folia, not a different fork of the same single-threaded design. For the wider comparison of server software, see Paper, Fabric or vanilla.
Switching from Paper, and back#
Because both forks keep Paper's world layout and plugin API, moving is a jar swap.
- Stop the server cleanly and wait for the save to finish.
- Take a backup off the machine. The world is the same format, but you are about to change behaviour you cannot always undo - a lobotomised trading hall or a ridden mob stays where it ended up.
- Download the fork's build for exactly your Minecraft version. Purpur publishes builds through its website and a download API; Pufferfish publishes them from its own site. Do not mix versions.
- Replace the server jar and start. The fork creates its own config file (
purpur.ymlorpufferfish.yml) beside your existingserver.properties,bukkit.yml,spigot.ymlandconfig/directory, all of which it keeps reading. - Read the startup log for plugins that failed to load and for config warnings, then change one option at a time.
On your own machine, fetching a Purpur build can be scripted against its download API:
$ curl -o server.jar https://api.purpurmc.org/v2/purpur/1.21.1/latest/download$ java -Xms4G -Xmx4G -jar server.jar --noguiGoing back to Paper is the same in reverse. Paper ignores purpur.yml and pufferfish.yml, so leave them in place in case you return. What does not come back is any state the fork created: entities ridden somewhere unusual, inventories larger than vanilla allows (items in rows four to six of a six-row ender chest are the classic case - empty them before switching back), and anything that depended on a Purpur-only command.
On RE:NODE, Minecraft plans arrive running Paper with the matching Java version, which is the recommendation of this post. If you want Purpur or Pufferfish instead, upload the jar through the file manager or over SFTP and point the Startup tab at it - there is no whitelist of allowed server software, and no one-click switch either. Take a backup first; game plans have backup slots that can be locked against rotation while you decide whether the fork is staying.
Running a fork well#
If you do run one, a few habits keep it boring:
- Pin the build. Do not let a start script download "latest" on every boot. Fork builds can contain regressions, and you want to choose when you take one. Keep the previous jar beside the current one.
- Keep a change log of every non-default option. Six months later, nobody will remember why phantoms are ridable or why villagers 30 blocks away stopped breeding. A comment block at the top of
purpur.ymlcosts nothing. - Watch the fork's release notes for security fixes and rebases, and follow Paper's announcements too, because Paper's fixes are what you are waiting for.
- Test on a copy before a version upgrade. Minecraft version upgrades has the order that works, and it applies unchanged.
- Profile after every change. A fork option that should help and does not is a sign the bottleneck is somewhere else.
FAQ#
Is Purpur faster than Paper?
Not by itself. Purpur's own options mostly default to vanilla behaviour, and its performance is close to Paper's. Builds that include Pufferfish's patches can be faster on mob-heavy servers once options such as DAB or villager lobotomisation are switched on, but the gain comes from those options, not from the name.
Do Paper plugins work on Purpur and Pufferfish?
Yes. Both keep the Paper API, so any plugin that runs on Paper runs on them. The exception is a plugin written against Purpur's extended API, which runs only on Purpur. Plugin authors usually state that clearly.
Can I go back to Paper after running Purpur?
Yes. The world format and folder layout are the same, and Paper simply ignores purpur.yml. Empty any six-row ender chests and extra barrel rows first, because Paper has nowhere to put those items.
Does Pufferfish's DAB break farms?
It can. DAB slows the AI of brain-based mobs far from players, which affects villager breeders, some iron farms and raid farms that work at a distance. Raise dab.start-distance, add the affected mob to dab.blacklisted-entities, or turn DAB off on servers with serious technical players.
Should a new server start on a fork?
Usually not. Start on Paper, tune it, and switch only when you need a specific feature a fork provides. A fork chosen because it sounds faster tends to add version lag and support problems without solving anything the server actually has.




Comments
Completely anonymous: no account, no email, no cookie. We store the name you type, the text and the time - nothing else. Links are limited and markup is not rendered.