serverconfig.json and servermagicnum.json
Most day-to-day settings — world name, password, player count, chunk radius — live in serverconfig.json inside your server’s data folder. A smaller number of deeper performance settings, including entity tracking range, live in a separate file called servermagicnum.json. If you set up your server using a custom --dataPath as recommended in our guide to playing with friends, both files live inside that folder rather than mixed in with your single-player settings.
If you’re running mods, this is doubly worth reading — heavier modpacks are exactly when these settings start to matter, as covered in our mods guide.
The four settings worth adjusting
Controls how far from each player the world loads and simulates — the single biggest lever for server performance. Dropping this to 8–10 noticeably reduces CPU and memory load on busy servers, and most players won’t consciously notice the difference in view distance during normal play. If you’re seeing tick lag with several players spread across the map, this is the first setting to touch.
Governs how often things like crop growth and natural block changes get processed per chunk. Dropping it from 20 to 15 is invisible to players day to day, but saves real CPU time across hundreds of loaded chunks on a busy server. This and MaxChunkRadius together account for most of a server’s routine per-tick workload.
Sets how far away creatures and other entities stay actively simulated. Reducing this to around 96 blocks means animals and mobs outside that range stop consuming CPU for pathfinding and behaviour, without players noticing anything different up close.
Your player cap. Set it to what your hardware can genuinely support smoothly rather than what sounds impressive — an overloaded server that struggles at 20 players is a worse experience than a well-tuned one that holds steady at 10. Our troubleshooting guide covers the symptoms of a server that’s genuinely over capacity.
Two settings people tweak and shouldn’t
Not every knob in the config file is worth turning — these two cause more problems than they solve.
This controls how often the server processes a game tick. Lowering it sounds like it should improve responsiveness, but it actually just causes the server to attempt updates faster than it can keep up with — producing tick lag rather than fixing it. Raising it makes the game feel sluggish. The default is already tuned correctly; changing it is very rarely the right move.
It’s tempting to disable this thinking it’s unnecessary overhead, but it protects your world save from corruption if the server crashes unexpectedly. The performance cost is genuinely negligible — a brief 1–2 second pause during the save itself — while the downside of disabling it is potentially losing the entire world. Not worth the trade.
All settings at a glance
| Setting | File | Default | Recommended |
|---|---|---|---|
MaxChunkRadius | serverconfig.json | 12 | 8–10 for busy servers |
RandomBlockTicksPerChunk | serverconfig.json | 20 | 15 |
DefaultEntityTrackingRange | servermagicnum.json | 128 | 96 |
MaxClients | serverconfig.json | — | Match your hardware, not ambition |
TickTime | serverconfig.json | Tuned | Leave alone |
Autosave | serverconfig.json | Enabled | Leave enabled |
World size and generation are configured separately — see our dedicated map size guide for that.
