The Best Modpack Server Settings for Stable TPS

A modpack server can show 20 TPS while everyone is standing still, then fall apart the moment three players head in different directions. That is why the best modpack server settings are not just about giving Minecraft more RAM. They are about controlling the work your server performs each tick: world generation, entity AI, mod machines, chunk loading, and disk activity.

For a private pack with friends, you can often prioritize a bigger exploration radius. For a public server with 20 players, predictable TPS matters more than letting every player generate a new continent at the same time. Start with a stable baseline, measure what happens under real player load, then change one setting at a time.

Start with hardware that fits modded Minecraft

Modded Minecraft is unusually sensitive to CPU speed. RAM determines whether the server has room for loaded chunks, mods, and player data, but a slow CPU core is still a slow CPU core. When a tick takes too long, extra memory does not fix it.

For most modern Forge and Fabric packs, plan around high single-core performance, NVMe storage, and enough memory for the pack plus active players. NVMe matters because modpacks create frequent disk activity through region files, player data, backups, and chunk generation. Slow storage turns teleports, exploration, and restarts into noticeable stutters.

As a practical starting point, 6 GB is workable for lighter modpacks and a small group. Most medium-to-heavy packs are more comfortable with 8 GB to 10 GB. Large kitchen-sink packs, busy worlds, or communities running multiple dimensions commonly need 12 GB or more. Do not blindly jump to the largest allocation, though. Giving Java nearly all available memory can leave no headroom for the operating environment and can make garbage collection pauses worse — our modded RAM breakdown and the RAM calculator help you land on a number.

Elysium's Ryzen and EPYC-based plans are built around the part that matters most when ticks get expensive: consistent CPU performance, backed by Gen4 NVMe storage for faster world reads and writes.

Use the right Java version and memory allocation

Before adjusting configs, confirm that your Java version matches the modpack's Minecraft version and loader requirements. Many 1.18 through 1.20.4 packs expect Java 17, while newer 1.20.5+ setups generally require Java 21. An incorrect Java version can cause launch failures, random mod errors, or performance issues that look like a server problem.

Set both minimum and maximum memory deliberately. For an 8 GB server plan, a sensible starting point is often -Xms6G -Xmx7G, not -Xmx8G. This gives the machine breathing room while allowing the Java heap to stay large enough for the pack. If your host manages Java flags for you, keep the allocation inside the panel recommendation rather than pasting a random flag string from an old forum post.

Modern Java garbage collection is usually fine with G1GC, which is the default for many deployments. Advanced JVM flags can help in specific cases, but they are not a magic TPS fix. If your profiler shows one mod consuming 60 ms per tick, no flag package will repair that. Fix the workload first.

The settings that decide tick stability

The most effective performance settings are usually in server.properties. They reduce unnecessary simulation without changing the pack itself.

Keep view distance realistic

A view distance of 8 to 10 is a strong default for most modded servers. At 10, each player can keep a large area of chunks active, and the cost multiplies quickly as players spread out. A 16-chunk view distance may feel great for screenshots, but it is expensive on a modded server where every loaded chunk can contain machines, mobs, crops, pipes, and ticking blocks.

If TPS drops when players explore, try lowering view-distance to 8 first. Players will barely notice the difference compared with a server that freezes during terrain generation.

Lower simulation distance before view distance

simulation-distance controls how far the server actively processes chunks. This is where crops grow, mobs move, redstone runs, and many modded blocks tick. Set it around 4 to 6 for most packs. Players can still see farther than the simulation area, but the server does less work.

A good starting combination is view distance 8 and simulation distance 5. If your community relies heavily on distant farms or chunk-loader builds, move simulation distance up carefully and watch TPS during peak hours.

Set a sensible player cap

Your max-players setting should reflect your actual hardware and pack, not an optimistic number on a server listing. Ten active players in separate dimensions can be more demanding than 30 players standing at spawn. Start with a cap you know the server can handle, then raise it after a real load test.

Also enable a whitelist while building and testing. It prevents surprise joins from turning your setup period into an accidental stress test.

Stop world generation from stealing every tick

New terrain is one of the biggest sources of modded lag. Every unexplored chunk may need structures, ores, biome calculations, modded features, and multiple datapack rules. When several players fly in different directions with speed-boosting gear, the server can spend more time creating chunks than processing gameplay.

Pre-generate the area your players will use before opening the server. The exact tool depends on the loader and Minecraft version, but the goal is the same: create the Overworld, Nether, End, and any major modded dimensions ahead of time. Run generation when players are offline, then restart the server before launch — the mechanics are covered in our guide to reducing chunk loading.

Set a world border if your project has a defined play area. This is not about making the world feel small. It gives you a performance boundary and makes backup sizes, disk usage, and pre-generation manageable. You can always expand it later during scheduled maintenance.

Avoid letting chunk loaders run without limits. A few community machines are fine. Dozens of permanently loaded bases full of processing systems are not. Most packs provide chunk-loading limits, and those limits should be tied to the server's real capacity.

Tune mods, not just Minecraft

The heaviest problem on a modded server is often inside the pack. One poorly configured mob mod, quarry, pipe network, storage controller, or automated farm can create more lag than every vanilla setting combined.

Check each modpack's server config folder before launch. Look for options related to mob caps, machine tick rates, world generation frequency, chunk loaders, fake players, and entity limits. Keep the pack author's defaults at first unless they are clearly intended for single-player use. Then tune based on what your players actually build.

For example, reducing hostile mob caps may improve performance on a combat-heavy pack, but it can break progression if players need mob drops. Slowing a machine's processing rate can protect TPS, but it may make a tech pack feel grindy. The right setting is the one that protects server health without changing the reason people joined your pack.

Use a profiler when TPS drops. Spark is a common choice on supported loaders, and timings-style tools can help identify expensive entities or mods. Run the profiler during the lag event, not after it disappears. You are looking for evidence: a dimension consuming ticks, thousands of item entities, a specific block entity, or a single machine cluster. The full workflow is in our modded server optimization guide.

Protect the world while you optimize

Performance tuning involves testing, restarts, config edits, and occasionally mistakes. Automatic backups are not optional for a modded world. Keep several restore points and make sure backups are stored away from the live server when possible.

Before changing configs, copy the current files and write down what you changed. A simple note like "simulation distance 6 to 5" makes rollback painless. Do not edit world files or remove mods from an established save without confirming that the pack supports it. Missing block IDs and dimensions can damage a world far more quickly than a low TPS number.

Schedule restarts for active communities. A restart every 12 to 24 hours can clear accumulated memory use and keep maintenance predictable, but restarting every hour only hides an unresolved issue. If memory climbs endlessly or TPS degrades after a specific player logs in, profile it and solve the cause.

A stable baseline to launch with

For a typical medium-sized Forge or Fabric modpack, begin with Java 17 or 21 as required by the pack, 8 GB to 10 GB of allocated RAM, view distance 8, simulation distance 5, a whitelist, and a pre-generated main world. Keep chunk-loading limits conservative, enable automatic backups, and use a realistic player cap.

That baseline will not be identical for every pack. A lightweight adventure pack may run beautifully with more view distance, while a factory pack full of always-on machines may need tighter simulation rules. Treat settings as a performance budget: spend it on the gameplay your community values most, and do not waste it on chunks and systems nobody is using.

The goal is not to squeeze the highest number into every setting. Build a server that stays responsive when players are exploring, automating, fighting bosses, and showing off their bases at the same time. When the world holds 20 TPS under those conditions, players stop thinking about the host and get back to playing — see our guide on hosting modpacks smoothly for the practical side.