Paper configuration beyond server.properties

server.properties is vanilla Minecraft's configuration. Paper has three more files, and they hold the settings that decide whether a busy server runs well, which is why a server tuned entirely through server.properties has usually left its biggest wins untouched.

PaperMC publishes a full configuration reference. This is the map of which file holds what, and which handful of entries are worth your attention.

Which file does what

• server.properties: vanilla settings, read once at boot.
• paper-global.yml: settings that apply to the whole server.
• paper-world-defaults.yml: defaults for every world.
• config/paper-world.yml per world: overrides for one world specifically.

The per-world split matters more than it sounds. A nether that needs different mob settings from the overworld is configured separately, and people who edit only the defaults file wonder why their change did not apply where they expected.

Entity and tile-entity activation

Paper's activation ranges decide how far from a player an entity keeps thinking. Outside the range, mobs stop pathfinding and simply exist.

This is the single largest performance lever on a survival server with farms, because a mob farm builds enormous entity counts by design. Lowering the range for monsters and animals reduces the work without visibly changing anything at the distances players are actually at.

The tell that you need it: tick time that scales with how long the server has been up and drops sharply after a restart. That pattern is entities accumulating, not a leak, and it is a different diagnosis from an actual crash.

Chunk loading, and the settings that hide a problem

Paper exposes controls over chunk loading and generation rates. Turning them down makes a struggling server feel better while doing nothing about the cause.

They are worth touching when you know why: a server whose players are constantly exploring new terrain genuinely does need different limits from one on a finished map. They are not worth touching as a first response to lag, and most guides present them that way.

Pregenerating the world is the real answer for exploration load, and it moves the cost to a time when nobody is playing.

Anti-xray, and what it costs

Paper can obscure ores from clients that have not legitimately discovered them. It works, and it is not free: the engine rewrites chunk data before sending it, which is CPU on the main thread.

Whether that trade is worth it depends on whether you have an x-ray problem, which most small servers do not and assume they do. Turning it on pre-emptively is a common way to spend performance on a threat that was not there: the same instinct that leads people to over-configure anti-cheat on Source servers before anyone has cheated.

Hoppers, and the setting that is always worth changing

Hoppers are the one entry where the default is wrong for almost every server that has players in it. Every hopper checks the block above it on a schedule, and a large storage room contains hundreds of them doing that check forever, whether or not anything is moving.

Paper exposes the check interval and how many items move per transfer. Raising the interval and raising the amount moves the same items with a fraction of the checks. Players notice nothing except that sorting systems feel marginally chunkier, and the server stops spending a measurable share of every tick on empty containers asking an empty block whether it has anything.

It is the clearest example of the general rule in this file: the default is tuned for a single-player world, and a server is not one.

The timings and profiling question

Every setting above is a guess until you measure. Paper ships a profiler and it will tell you which plugin, which entity type and which world is consuming the tick.

Reading that report is the skill that separates an admin who fixes lag from one who restarts the server, and it takes an hour to learn once. Everything else in this article is a hypothesis that the profiler either confirms or kills, which is why monitoring over days beats tuning in an afternoon.

What not to do

Do not paste a configuration from a server with a different player count, a different plugin set and a different world. The settings interact, and the ones that helped somebody with two hundred players on a five-year-old map will not help a new server with twelve.

Do not change six things at once. You will not know which one worked, and one of them will have quietly made something worse.

Start with activation ranges, measure, and stop when the tick time is healthy. A server that runs well with a nearly-default config is not under-optimised: it is a server that did not need the other settings, and the effort is better spent on the things that make people stay.