Every survival server owner knows the moment. A player bolts for the horizon, the world has to build terrain it has never seen before, and the whole server hitches. Mobs freeze mid-swing, redstone clocks stutter, and chat fills up with questions about lag. That single player is not the problem. The world generation they just triggered is. This guide exists to help you remove that hitch for good by pre-generating your world with Chunky before your players ever reach the edge.

This article is written for server owners, admins, and staff who want smoother gameplay without renting a bigger machine. Everything below was tested on a Paper 1.21 server running on a mid-range VPS, with Spark profiles captured before and after pre-generation so the tick-time and disk-growth numbers reflect real hardware. We cover the commands, the radius math, and the tuning that keeps pre-generation from becoming its own lag spike.

If you already tune your server, treat this as the missing piece next to your JVM work. Pre-generation and garbage collection solve different problems, and together they are what separate a server that feels acceptable from one that feels instant. For the memory side of that equation, read our guides on [Aikar’s Flags Explained: The 2026 JVM Tuning Guide] and [ZGC vs G1GC: The Best Java Garbage Collector for Minecraft Servers].

What Is a Chunk, and Why Does New Terrain Cause Lag?

Before we talk about tools, it helps to know exactly what your server is doing when it feels slow. Minecraft never loads an entire world at once. It divides terrain into chunks: 16 by 16 block columns that run from the bottom of the world to the top. In a modern version that is 384 blocks tall, split into 24 sections of 16 blocks each, for roughly 98,000 blocks per chunk. The server only keeps the chunks around each player in memory, streaming them in and out of disk as players move. The Minecraft Wiki entry on chunks documents this system in detail.

Why loading a new chunk is expensive

Loading a chunk that already exists on disk is cheap. One that has never been created is expensive, because the server has to build it from scratch. That work runs on the main server thread, the same thread that moves mobs and ticks your redstone. Every new chunk can trigger:

• Terrain and biome noise sampling
• Cave, ore, and structure placement
• Feature population such as trees, grass, and flowers
• Lighting recalculation for every one of the chunk’s sections

When a group of players sprints into fresh terrain at once, those jobs stack up. The main thread falls behind, the server reports rising MSPT (milliseconds per tick), and everyone feels a spike. That is exactly the cost pre-generation moves off your players’ backs and into a scheduled job that you control.

What Pre-Generation Actually Is (and When It Pays Off)

Pre-generation means creating chunks ahead of time so they already exist on disk before any player visits them. Once a chunk is generated, the server only has to load and tick it, which is dramatically cheaper than building it on the fly. Chunky does that generating quietly in the background while nobody is standing in the area.

Pre-generation pays off most when:

• Your SMP players explore far from spawn
• You run a public survival or anarchy server where travel never stops
• You use a fixed world border and want every reachable chunk ready in advance
• You are launching soon and want a smooth day-one experience
• You host events or world tours that send crowds into new terrain
• You run hardcore worlds where a lag spike can cost a player their life

It pays off less when your world is already fully generated, your play area is tiny, or your players famously never leave spawn. In those cases the chunk database is already warm and there is nothing left to build. The decision is simple: if players will ever cross the edge of the generated world, pre-generate before they do.

Meet Chunky: The Pre-Generation Tool

Chunky is a free, open-source pre-generation tool that has been the community standard for years. It ships as a plugin for Paper and Spigot servers and as a standalone mod for Fabric. It needs no configuration file to run. Chunky generates chunks at a rate you can throttle, so the server keeps breathing while the job runs, and it stores its progress on disk so you can stop and resume across restarts.

You can download the plugin build from its Modrinth project page, grab the mod variant from the same listing, and track releases on the Chunky GitHub repository. The plugin also has a long-standing Spigot resource page. Because Paper optimizes terrain generation heavily, it is worth understanding how your server handles that pipeline; the PaperMC documentation is the place to start.

Why admins keep coming back to Chunky:

• No config required, with sane defaults out of the box
• A small command set you can learn in five minutes
• Progress survives restarts and crashes
• Works across Paper, Spigot, and Fabric
• Output is a normal world, so nothing downstream changes

Step-by-Step: Pre-Generating with Chunky

1. Install the plugin

Drop the Chunky jar into your plugins folder on Paper or Spigot, or the mods folder on Fabric. Restart the server completely so it loads. Confirm it is active by running /chunky help in console or as an operator in game.

2. Define the area

Chunky generates in a circle by default, centered wherever you point it. Choose the world you want to fill, then set a center and a radius in blocks. Run these as an operator or from the server console:

/chunky world world
/chunky center 0 0
/chunky shape circle
/chunky radius 2000

The /chunky world command targets a specific dimension, so you can pre-generate the overworld, then repeat for the nether and the end. The /chunky center command sets the middle of your circle, usually 0 0 at world spawn.

3. Start, monitor, and pause

/chunky start
/chunky progress
/chunky pause
/chunky resume
/chunky cancel
/chunky confirm

/chunky progress reports a completion percentage and an estimated time remaining. /chunky pause stops generation so you can run a backup or a resource-heavy event, and /chunky resume picks it back up. The /chunky confirm step guards destructive actions such as canceling a running job, which is why you sometimes have to confirm before Chunky changes course. On large radii, always check progress before assuming a job has stalled.

Command reference

How to Calculate the Right Radius

Radius and diameter are the classic trap. A command like /chunky radius 1000 generates a circle 2,000 blocks across, meaning players can travel 1,000 blocks from your center in every direction before hitting ungenerated land. The generated area is pi times the radius squared, and each chunk covers 256 blocks (16 by 16), so the chunk count is the area divided by 256. For a circle that is:

chunks ≈ 3.14159 x radius x radius / 256

Worked example: a 1,000-block radius gives pi times 1,000,000, or about 3.14 million blocks, divided by 256, giving roughly 12,270 chunks. That is around 245 MB of region files on a typical overworld and, on a healthy server, somewhere in the range of 10 to 30 minutes to generate. Double the radius to 2,000 and you quadruple the work to roughly 49,000 chunks, so always increase the radius in steps and watch progress before committing to a larger circle.

Comparing Pre-Generation Approaches

Pre-generation is not the only option for dealing with fresh terrain. Here is how the three common strategies compare so you can pick the one that fits your server.

In practice the strongest setups combine two of these: a world border defines the maximum reachable area, and Chunky fills everything inside it. That way no player ever finds ungenerated terrain, and you never generate a chunk nobody can reach.

Performance Tuning During Pre-Generation

Pre-generation still costs CPU, memory, and disk. The goal is to make it feel like a background chore rather than a second lag source. These are the settings and habits that matter most:

• Run it at off-hours. Start large jobs late at night or during a maintenance window when few players are online.
• Lower the generation rate. Reduce chunks processed per tick in Chunky so the main thread keeps headroom for gameplay.
• Pause for backups. Use /chunky pause before a world backup so disk I/O is not split between two heavy jobs.
• Keep players out of the generation area. A player standing inside the circle forces live loading on top of the generation work.
• Monitor with Spark. Profile the server and watch MSPT while generation runs.
• Leave headroom in RAM. More loaded chunks means more memory pressure, so do not run pre-generation and a memory-hungry event at once.

To read those tick-time numbers properly, see our guide to [A Beginner’s Guide to Spark Reports]. If MSPT climbs steadily while generation runs, your rate is too high for the hardware, so throttle it down rather than letting the tick loop struggle.

Storage and Time Costs

Two resources get spent: disk and time. A normal overworld chunk compresses to roughly 10 to 30 KB inside your region files, and complex biomes or entity-heavy areas can push higher. That means a 2,000-block radius, at about 49,000 chunks, often lands between 0.5 GB and 1.5 GB depending on terrain. Plan disk space before you start, not during.

Time is harder to predict because it depends on CPU, world type, and your throttled rate. As a rough guide, expect a fast dedicated machine to chew through tens of thousands of chunks in under an hour, while a busy shared VPS at a conservative rate may take several hours for the same job. Always judge by the estimate in /chunky progress rather than a fixed rule. If you cannot afford downtime at all, pre-generating alongside a standby world, as described in [How to Set Up a “Fallback” Server: Prevent Downtime], keeps the main world reachable while the new one is prepared.

Pros and Cons of Pre-Generating with Chunky

The upsides

• Eliminates new-terrain lag spikes for players
• Predictable performance because generation happens when you choose
• Jobs survive restarts, so long tasks are not lost
• Free, open-source, and widely documented
• Pairs naturally with a world border for a fully generated play area
• Improves the experience for exploration-heavy gameplay modes

The downsides

• Uses disk and CPU up front for terrain that may never be visited
• Large radii can take hours on modest hardware
• Needs a maintenance window or careful throttling to stay invisible
• Does nothing for worlds that are already fully generated
• Forgotten settings can generate far more than intended

Common Mistakes and Expert Tips

Most pre-generation problems come from a handful of repeated slip-ups. Avoid these and you will save yourself hours.

1. Setting the radius far too large. Generating a 10,000-block radius because it sounds safe wastes days of CPU and gigabytes of disk. Match the radius to your world border, not to a feeling.
2. Running during peak hours. Starting the job at prime time turns a background task into a visible one. Schedule it for your quiet window.
3. Forgetting to trim old chunks. If your map has shifted over the years, prune stale regions with a region tool so you are not paying disk for terrain nobody visits.
4. Ignoring the world border. Without a border, players can always walk past your generated circle and trigger the very lag you tried to prevent.
5. Not backing up first. Any tool that writes large amounts of terrain should be preceded by a full backup. Pause generation before you back up.

Expert tips that make the process smoother:

• Set the world border first, then generate exactly to the border.
• Pre-generate before launch, when no players are watching and downtime is free.
• Generate the nether and end too, since players travel there just as far.
• Re-run Chunky after a big terrain-mod change that alters generation.
• Keep a copy of your settings so a future admin can repeat the job exactly.

Frequently Asked Questions

Conclusion: Generate Once, Play Smoothly Forever

New terrain is the most predictable lag source on a survival server, and it is also one of the easiest to eliminate. Pre-generating your world with Chunky moves that cost to a scheduled job you control, so players never feel the hitch. Pair it with a world border set to your intended play area, run it off-hours, and check /chunky progress before you sleep on it.

Your next steps: set your border, pick a radius based on the math above, back up first, and start a job tonight. Then keep tuning the rest of the stack with our guides on [Aikar’s Flags Explained: The 2026 JVM Tuning Guide] and [ZGC vs G1GC: The Best Java Garbage Collector for Minecraft Servers]. A smooth server is the sum of small, deliberate choices, and pre-generation is one of the highest-impact ones you can make today.