A downloaded “best config” can make a server look faster by removing the gameplay your players came for. Start with settings you understand, keep the original files and judge each change during the same busy activity.
There is no best configuration for every Paper server. Use a small distance experiment first, then investigate measured hotspots and version-specific world settings.
Keep the original configuration and a baseline
Stop cleanly and copy the world and configuration before editing. Record the Paper build, Java release, plugin versions and a repeatable workload. Keep an untouched copy of the generated files so you can undo your experiment.
If your server is already healthy, decide what you want to improve: shorter exploration stalls, less CPU load at spawn or more consistent ticks. “Higher performance” is too vague to evaluate.
Try distance settings as an explicit experiment
The following is a modest test configuration for a server whose current distances are higher. It is not a recommended value for every player count, farm or modpack. Edit existing properties rather than appending duplicate keys, restart and compare the same route or base.
view-distance=8
simulation-distance=6
Players will see or simulate a smaller area. Tell your community what is changing and check its effect on farms before deciding to keep it.
Know which file wins
Paper has global settings, world defaults and per-world overrides. Inspect the files generated by your exact release and check the current reference before editing a key. An override in one world can explain why a default change appears to do nothing.
Do not paste a full paper.yml from an old tutorial into a modern configuration layout. Preserve indentation in YAML and change one documented key at a time.
Treat entity and farm changes as gameplay decisions
Activation ranges, ticking behavior and mob spawning can change how a survival community plays. Before reducing them, identify the expensive area and speak to the players using it. Sometimes redesigning a single farm is better than changing behavior across the whole server.
Use a test copy for aggressive experiments. A timer that clears every item is not a substitute for understanding a profile, and a large list of “lag plugins” can add its own work.
Write down a before-and-after result
Use the same software, player activity and observation period. Record tick measurements and any gameplay differences; a quiet five-minute sample should not be compared with the busiest hour of yesterday. Use the performance workbench to retain a local record of genuine measurements.
If the change does not help, restore the original setting before trying the next one. When the server is stable, save the working configuration alongside a fresh backup.
Before you finish
- Save a baseline and original files.
- Try one documented setting at a time.
- Check per-world overrides.
- Measure performance and gameplay together.
Common questions
Should I copy somebody else’s whole Paper configuration?
Use it as a set of questions, not as a replacement for understanding the current release. Unsupported or outdated keys may do nothing, and working keys may alter gameplay.
Does a low simulation distance have no downside?
It changes the simulated area and can affect activities outside it. Test with the farms and travel your own community uses.
Official documentation
Commands and configuration depend on your installed software version. Check its current documentation, keep a backup and test one change at a time.
Build a setup that fits your server
Compare monthly allocations and CPU tiers, or use the plan finder for a starting estimate.
Compare Minecraft hosting plans Find a plan