Minecraft world border and pre-generation with Chunky

Two decisions cap how much land a Minecraft server will ever have to build: a world border, and one pre-generation run inside it. /worldborder set 10000 bounds the work and the disk. Chunky then walks every chunk inside that border once, at three in the morning, so that afterwards walking to the edge of the map is a decompress and a parse off NVMe instead of terrain being computed in the middle of a tick. The stutter that people blame on the host usually stops happening.

That is the whole idea. The rest of this post is the numbers behind it: what a chunk costs, how big a border should actually be, the exact commands, and what to do about a world that is already far too large.

Why generating a chunk is the expensive part#

A chunk does not arrive finished. It moves through a pipeline of stages, and each one has to wait for its neighbours: biomes are decided, then the noise that makes the shape of the land, then the surface layer, then carvers dig caves and ravines, then features are placed - trees, ore veins, structures, decorations - and finally the light is calculated. Only then can the chunk be handed to a player.

Reading a chunk that already exists is a completely different job. The server finds it inside a region file, decompresses a few kilobytes, parses the block data and the block entities, and hands it over. Generating a fresh chunk is tens of milliseconds of CPU work; loading an existing one is one to two orders of magnitude cheaper. That gap is the whole argument for pre-generation.

Now the arithmetic that makes it urgent. With the default view-distance=10, one player needs a 21 by 21 square of chunks around them - 441 chunks. Walk one chunk east and 21 new chunk columns are required immediately. A player sprinting crosses a chunk every second or so; a player on an elytra with rockets is doing roughly two chunks a second, which is about 40 new chunks a second demanded from a single person. On generated land that is disk work. On fresh land it is the most expensive thing the server knows how to do, and it happens while twenty other people are waiting for their tick.

Modern Paper builds push a good deal of generation onto worker threads, which helps, but those threads run on the same CPU share you are paying for, and the final hand-off of a chunk into the live world is still main-thread work. Off-thread does not mean free. This is why a server can sit at a perfect 20 TPS all evening and then drop to 12 the moment somebody decides to go find a mushroom island.

What a border actually buys you#

A world border is not a restriction so much as a budget. It bounds five things at once, and only the first is obvious:

• Disk. A world can only ever be as large as its border. Without one, the limit is 60 million blocks square and your plan's disk quota, whichever you hit first.
• Generation work. Once the inside is generated, the expensive operation described above simply stops occurring.
• Backup size and restore time. Backups are of the world folder. A world that grows without limit means a backup that takes longer every week - and the whole point of backups that actually restore is that you can restore one in a hurry.
• Map render cost. Dynmap, BlueMap and squaremap render tiles for generated chunks. An unbounded world means an unbounded tile directory, which is usually larger than the world itself. See web maps with Dynmap and BlueMap.
• Moderation and cleanup. A finite map is one you can search, roll back, and reason about.

Say the uncomfortable part out loud: 10,000 blocks square is an enormous world. That is 100 million square blocks of surface. A large survival base occupies maybe 200 by 200. Ten thousand square gives every member of a twenty-person community roughly 5 million square blocks each, and nobody will ever see most of it. Communities that set 4,000 or 5,000 for a season find the map feels busier and more social, not smaller, because people actually run into each other.

Border sizes, chunk counts and disk#

/worldborder set takes a diameter in blocks, not a radius. A border of 10,000 means 5,000 blocks in each direction from the centre. The numbers below assume the centre is spawn.

The region-file column is where those sizes come from. A region file - region/r.0.0.mca and its neighbours - holds a 32 by 32 block of chunks, which is 512 by 512 blocks of world. Since 1.18 raised the build range to -64 to 320, a fully generated overworld region file usually lands somewhere between 4 and 12 MB compressed, which is a few kilobytes per chunk. Multiply and you get the table. Your own numbers will differ with version, biome mix and how much people have built, so measure your world folder after a run rather than trusting a table, including this one.

The other dimensions matter less than people expect. The Nether is on an eighth scale, so a 10,000 overworld border corresponds to 1,250 in the Nether if you want portal links to keep working the way players assume. The End is only worth pre-generating out to a few thousand blocks unless your community does end-busting for a living, and the outer islands are cheap terrain anyway.

Setting the border in vanilla#

The border is a vanilla feature and needs no plugin. Every command runs from the panel console without a leading slash, or in-game with one.

worldborder center 0 0worldborder set 5000worldborder warning distance 32worldborder warning time 10worldborder damage amount 0.2worldborder damage buffer 5worldborder get

Two details catch people. The border is per dimension: running the command in the overworld does not touch the Nether. Set each one explicitly and then confirm it:

execute in minecraft:the_nether run worldborder set 625execute in minecraft:the_end run worldborder set 5000execute in minecraft:the_nether run worldborder get

And max-world-size in server.properties is the ceiling the border can be set to, not the border itself. Its default is 29,999,984. Lowering it is a belt-and-braces measure against somebody with operator rights typing a very large number; it does not generate or delete anything on its own. Every other key in that file is covered in server.properties explained.

The vanilla border is always a square, it blocks movement and block placement, and because players cannot get past it, normal play generates nothing beyond it. It does not retroactively remove land that was generated before it existed. If you want a circle, or want the border drawn on your web map, the ChunkyBorder companion plugin enforces the same shapes Chunky can generate.

Pre-generating with Chunky#

Chunky is the standard tool and exists for Paper, Fabric, Forge and NeoForge. Drop the jar in plugins/ (or mods/), restart, and it registers /chunky. Everything below works from the panel console too.

chunky world minecraft_overworldchunky center 0 0chunky shape squarechunky radius 2500chunky start

Note that Chunky's radius is a radius, while the vanilla worldborder set is a diameter. radius 2500 matches worldborder set 5000. Getting this backwards and generating four times the intended area is the single most common Chunky mistake.

Chunky writes its progress down, so a restart in the middle of a run is survivable - chunky continue picks it up rather than starting over. The rate it reports is the number to watch. On a shared container expect somewhere between 10 and 60 chunks a second depending on version, CPU share and how many structures are in the way. At 30 chunks a second, the 391,000 chunks of a 10,000 border is about three and a half hours. A 20,000 border at the same rate is fourteen hours, which is a different kind of decision.

Memory is the part people get wrong. Pre-generation holds a great many chunks in flight, and a 2 GB server that is perfectly happy with five players will hit its heap ceiling during a run. Give it headroom, keep an eye on the memory graph, and see how much RAM a Minecraft server needs for the sizing. On RE:NODE a container that reaches its memory limit is stopped and restarted clean rather than left to swap, so an over-ambitious run ends as a restart and a resumable Chunky task rather than an hour of thrashing.

Running it without ruining the evening#

1. Take a backup first and confirm it exists. Pre-generation is not destructive, but you are about to write gigabytes and you want a known-good copy.
2. Set the border in every dimension you care about, and verify with worldborder get.
3. Empty the server, or accept that it will be unpleasant for anyone on it.
4. Drop view-distance to 6 for the duration. The generator does not need it and the reduction leaves more CPU for the actual work.
5. Start the run, then chunky quiet 300 so the console is readable afterwards.
6. Check chunky progress once, then leave it alone.
7. When it finishes, restart the server, put view-distance back, and look at the size of the world folder.

The Schedules tab turns steps 3 to 5 into something that happens while you sleep: a task at 0 4 * * * that runs the console commands, and another later that restarts. Cron expressions explained covers the five fields if the syntax is unfamiliar, and scheduled tasks worth having has the other jobs worth putting there.

One honest warning about shared hardware: a pre-generation run will sit at 100% of your CPU allocation for hours. On RE:NODE that is a hard throttle to the share you bought rather than something that spills onto neighbours, and a server at 100% is slow, not in trouble - it is never grounds for suspension. But it does mean the run will take as long as your share allows, and buying a bigger share for one night is a reasonable thing to do.

Trimming a world that is already too big#

This is the common case: a two-year-old survival world with no border, 40 GB of region files, and a handful of chunks a thousand blocks out where somebody once ran in a straight line for an hour.

Two tools do the job. chunky trim deletes every chunk outside the current selection in the current world, and asks for confirmation before it does. MCA Selector is the external option: it opens the region folder, shows you the map chunk by chunk, and can select by InhabitedTime - the number of ticks players have actually spent in a chunk. Filtering for InhabitedTime under a minute or two finds the land that was generated in passing and never used, which is almost always the bulk of the waste.

The order matters, and there is no undo:

1. Stop the server. Trimming a running world is how you get corrupt region files.
2. Download a full backup and confirm the archive opens. This is the step people skip.
3. Set the border you actually want, and check what it excludes against your web map.
4. Trim the overworld, then the Nether, then the End - each is its own folder and its own decision.
5. Start the server and fly the perimeter before announcing anything.

What pre-generation does not fix#

It is worth being clear about the limits, because "pre-generate the world" gets offered as a cure for every kind of lag.

Pre-generation fixes stutter caused by terrain being created. It does nothing for a mob farm holding four thousand entities, a hopper chain under somebody's base, a redstone clock that never stops, a plugin running a database query on the main thread, or garbage-collection pauses from a badly sized heap. If your server is slow while everybody is standing still at spawn, generation is not your problem. Measure first: why TPS drops and what to do has the order to work through, and reading a spark report turns a guess into the name of a plugin. The Paper settings that cap entity and block-entity work live in the Paper optimisation guide.

The other thing it does not fix is a chunk-loading pattern. Pre-generated land still has to be read, decompressed and sent. Twenty players spread across a 10,000-block map each hold their own 441 chunks, and that is a real memory and I/O cost even with nothing to generate. What NVMe actually changes is mostly about this: the read is fast, so what is left is CPU and memory.

FAQ#

Does a world border stop chunks generating completely?

In normal play, yes - players cannot walk past it, so nothing beyond it is ever requested. A few edge cases still reach outside: Nether portal linking near the line, and anything with operator rights teleporting. It is a budget that holds, not a wall in the filesystem.

How long does pre-generation take?

At a typical 10 to 60 chunks a second, a 5,000-block border is roughly one to three hours and a 10,000-block border is three to ten. Chunky prints its own rate and estimate a minute into the run, and that estimate is more trustworthy than any figure on the internet because it is measured on your CPU share.

Will pre-generating make my world folder enormous?

It makes it exactly as large as the border you set, which is the point of setting one. Budget 2 to 5 GB for a 10,000-block overworld and check it against your plan's disk before you start. Pre-generation does not create more data than exploring the same area would; it just creates all of it at once.

Can I pre-generate while people are playing?

You can, and it will be obvious to them. If you have to, cut the radius into slices and run them overnight with chunky pause scheduled before your busy hours. Chunky keeps its place across restarts, so a run spread over five nights is perfectly normal.

Do I need to pre-generate the Nether and the End?

The Nether, usually yes - it is only an eighth of the area and Nether travel is fast, so players cover it quickly. The End, rarely: the main island is tiny and generated already, and the outer islands are cheap terrain that nobody visits in bulk.

Does shrinking the border delete what is outside it?

No. Shrinking the border only stops people reaching that land; the region files stay on disk and in every backup. Removing them is a separate, deliberate step with chunky trim or MCA Selector, and it is not reversible without a backup.