Multiverse-Core: multiple Minecraft worlds

Multiverse-Core lets one Paper server run as many worlds as you like - a survival world, a creative flat world, a resource world that resets monthly - with players moving between them by command or portal. You create a world with /mv create <name> normal, import an existing folder with /mv import <name> normal, and teleport with /mv tp <name>. Three add-ons do the rest: Multiverse-Portals for portals between worlds, Multiverse-NetherPortals to give each world its own Nether, and Multiverse-Inventories to keep creative items out of survival. Every extra world shares the server's one main thread, memory and disk, so worlds are cheap when empty and unloaded and expensive when they keep chunks loaded. For separate game modes with their own plugins and restarts, separate servers behind a proxy are usually the better design.

What Multiverse does, and what it does not#

A Paper server normally runs exactly three worlds: the Overworld from level-name in server.properties, plus world_nether and world_the_end. Bukkit has always been able to load more worlds at runtime, but it has no commands or configuration to manage them. Multiverse-Core is that management layer. It:

• creates new worlds and imports existing world folders
• remembers which worlds exist and loads them at startup
• stores per-world settings: game mode, difficulty, PvP, spawning, spawn point and more
• provides teleport commands and a destination syntax shared by its add-ons

It does not make worlds independent servers. Every world runs inside the same process, ticked one after another on the same main thread, with the same plugins, the same player list and the same chat. A lag machine in the creative world slows the survival world too. That is the central trade-off, and it comes back in every section below.

Multiverse is a plugin, so it needs Paper or another Bukkit-compatible server. It does not run on Fabric, NeoForge or vanilla, and it is not supported on Folia. Install the jar in plugins/, restart, and it creates its folder with a worlds.yml that lists every world it manages.

Creating, importing and removing worlds#

The commands you will use most:

/mv create creative normal/mv create mining normal/mv create void_lobby normal/mv import oldsurvival normal/mv list/mv info creative/mv tp creative/mv unload mining/mv load mining/mv remove oldsurvival/mv delete mining/mv confirm

The second argument is the environment: normal, nether or the_end. It decides the dimension type - sky, lighting, how beds and respawn anchors behave - not just the terrain.

Optional flags set the seed, the world type and a generator. In Multiverse-Core 4 they look like this:

/mv create flatland normal -t FLAT/mv create seeded normal -s 8675309/mv create custom normal -g Terra:OVERWORLD

Version 5 accepts the same information with reworked flags; /mv help create shows the exact form. A generator from a plugin such as Terra needs that plugin installed first. Custom world generation covers generators and seeds in more detail.

Importing is how you bring in a world someone else made - an adventure map, an old season, a world from single-player. Upload the folder into the server root next to world, then /mv import <foldername> normal. If the world came from vanilla or single-player, its Nether and End are inside it as DIM-1 and DIM1; Paper will not use those as separate worlds, so import them separately if you need them, or move them into their own folders first. Paper, Fabric or vanilla explains the folder layout difference.

Removing comes in two strengths. /mv remove stops Multiverse managing the world but leaves the files on disk. /mv delete deletes the folder, after /mv confirm. There is no undo, so take a backup first.

Unloading keeps a world registered but out of memory. An unloaded world costs nothing except disk space, which makes it the right state for an old season you want to keep.

Per-world settings#

Each world has its own settings in Multiverse's worlds.yml - game mode, difficulty, whether PvP is on, whether animals and monsters spawn, the spawn location, whether it is hidden from /mv list, an alias for display, and where players respawn when they die there.

Change them with commands rather than editing worlds.yml while the server runs. In version 4 the form is /mv modify set <property> <value> <world>:

/mv modify set gamemode creative creative/mv modify set pvp false creative/mv modify set difficulty peaceful creative/mv modify set monsters false creative

Version 5 orders the arguments differently; again, /mv help modify is authoritative. The spawn point for a world is set by standing where you want it and running /mv setspawn.

Settings outside Multiverse are per world too, and this is where most confusion comes from:

• Game rules. Vanilla /gamerule applies to the world the sender is standing in. From the console it applies to the main world. Multiverse provides its own gamerule command that takes a world name, which is the reliable way to set rules on a world nobody is in.
• Paper settings. Paper reads config/paper-world-defaults.yml for every world, then a paper-world.yml inside each world folder for overrides. Put creative-world view distance or entity limits there.
• Spigot settings. spigot.yml has a world-settings section with a default entry and optional entries named after each world.
• server.properties applies to the main world only. level-seed, level-type and generate-structures mean nothing to worlds created by Multiverse; each takes its own options at creation.
• Datapacks are loaded from the main world's datapacks/ folder and apply across the server.

Portals and nether links#

Players need a way between worlds that is not a command. The add-ons handle it.

Multiverse-Portals creates portals of any shape. Select the region with the portal wand (or a WorldEdit selection if WorldEdit is installed), then create the portal with a destination:

/mvp wand/mvp create to_creative w:creative/mvp create to_hub w:world

Destinations use a prefix syntax shared across the Multiverse add-ons: w:<world> for a world's spawn, p:<portal> for another portal, and e:<world>:<x>,<y>,<z> for exact coordinates. A pair of portals pointing at each other with p: gives you a two-way link between specific spots, which is how most hub worlds are built.

Multiverse-NetherPortals decides where nether and end portals lead. By default it follows a naming convention: a world called survival2 has its Nether portals lead to survival2_nether and its End portals to survival2_the_end, if those worlds exist. Create them with the matching environment:

/mv create survival2 normal/mv create survival2_nether nether/mv create survival2_the_end the_end

For anything that does not follow the naming pattern, link worlds explicitly with /mvnp link nether <from> <to> and /mvnp link end <from> <to>. Without NetherPortals, every nether portal on the server leads to the main world_nether, which is the classic surprise on a server with two survival worlds.

The End has an extra subtlety: the dragon fight and the exit portal belong to the End world itself, so a second End is a second dragon. That is usually what you want for a second survival world, and not what you want for a resource world.

Per-world inventories#

Without Multiverse-Inventories, a player's inventory follows them everywhere. Walk from the creative world into survival and they bring a stack of beacons. The add-on fixes that by grouping worlds: worlds in the same group share inventories, and worlds in different groups do not.

A typical layout:

What a group shares is configurable - inventory, ender chest, health, hunger, experience, potion effects, bed spawn and more - so you can, for example, share experience everywhere while keeping inventories separate. Groups are defined in the plugin's groups.yml or through its commands; the plugin's documentation lists the share names for your version.

Two pieces of advice. Set up the groups before players start moving between worlds; splitting a shared inventory later means deciding which copy wins. And test the boundary deliberately: put an item in your inventory, walk through every portal, and check where it ends up. A gap in the configuration is how a server finds out that creative items can reach survival through the End.

What each extra world costs#

A world's cost depends on how much of it is loaded, not on how big it is on disk.

Ticking. Every loaded world is ticked once per server tick, in turn, on the main thread. A world with no players and no loaded chunks takes almost no time. A world with loaded chunks - because players are there, because spawn chunks are kept loaded, or because a farm or chunk loader keeps them loaded - is ticked like any other area, and its tick time adds to everything else's. Ten busy worlds on one server are one main thread doing ten worlds' work. Why TPS drops and what to do has the general picture.

Spawn chunks. Every world historically kept a block of chunks around its spawn loaded permanently. From Minecraft 1.20.5 that area is set by the spawnChunkRadius game rule, default 2; setting it to 0 in worlds that do not need it means an empty world keeps nothing loaded. On older versions Multiverse has a per-world setting to stop keeping spawn in memory. For a server with several worlds this is the single most effective setting.

/mv tp mining/gamerule spawnChunkRadius 0

Run it while standing in the world you want to change, as above, or use Multiverse's own gamerule command, which takes a world name and works from the console.

Memory. Each loaded world holds its own loaded chunks, entities and lighting data. Empty worlds with nothing loaded are small; worlds with players add memory in proportion to view distance and activity. Watch the memory graph after adding worlds, and see how much RAM a Minecraft server needs for the general sizing.

Disk and backups. Every world's generated chunks are on disk. A resource world that gets explored heavily every month and is never reset grows without limit. Every world is also part of your backups, which take longer and use more space as worlds are added. On RE:NODE, Minecraft plans have 15 to 100 GB of disk and two backup slots; the disk graph next to the console shows when worlds start to crowd the plan.

Autosave. Each world saves its own dirty chunks. Many busy worlds mean more write work during autosaves, which on a large server shows up as a periodic stutter.

A resource world that resets#

A common reason to install Multiverse is a mining world that resets on a schedule, so the main world stays unscarred. The pattern:

1. Create it: /mv create resources normal. Set spawnChunkRadius to 0 and set a world border, so exploration has a limit.
2. Link it from the hub with a Multiverse-Portals portal, and decide in Multiverse-Inventories whether items come home.
3. To reset it, delete and recreate it with nobody inside, or use Multiverse's regenerate command where your version provides one. Announce the reset in advance - anyone standing in it when it is deleted is moved to the main world's spawn.
4. Pre-generate the new world inside its border once it exists, so the first hour after a reset is not a lag spike. World borders and pre-generation has the Chunky commands.

Run the reset by hand a few times and write down the exact command sequence for your Multiverse version, including any confirmation step. Then automate it. On RE:NODE the Schedules tab runs ordered console commands with delays on a cron expression - an announcement, a wait, the reset commands, a pre-generation start - so a first-of-the-month reset can happen without anyone online. Take a backup in the same schedule beforehand.

Multiverse or a proxy network#

Multiverse puts several worlds in one server. A proxy such as Velocity puts several servers behind one address. They solve overlapping problems with different trade-offs:

Use Multiverse for worlds that belong to the same game: a survival world with a resource world, a creative plot world, a spawn hub. Use a proxy when the "worlds" are really different games - a minigame server, a modded server, an event world full of plugins you would not want running beside survival. Building a Velocity network covers the proxy side.

FAQ#

Does Multiverse-Core work on Fabric or NeoForge?

No. Multiverse is a Bukkit plugin and needs Paper or another Bukkit-compatible server. Fabric and NeoForge have their own mods for extra dimensions, which work differently and usually require the client to have them too.

Why do nether portals in my second world go to the main Nether?

Without Multiverse-NetherPortals, every nether portal leads to world_nether. Install NetherPortals and either name the worlds to its convention (name_nether, name_the_end) or link them explicitly with /mvnp link.

Do empty worlds cause lag?

Very little, if they have no chunks loaded. A world keeps chunks loaded around its spawn unless you turn that off; on 1.20.5 and later set the spawnChunkRadius game rule to 0 in worlds that do not need it, and unload worlds nobody uses.

How do I stop creative items reaching survival?

Install Multiverse-Inventories and put the creative world in a group of its own, separate from the survival worlds. Then test every route between them - portals, commands, the End - with an item in your inventory.

Can I import a single-player world with Multiverse?

Yes. Upload the world folder to the server root and run /mv import <foldername> normal. Its Nether and End are stored inside the folder in vanilla layout, so import them separately if you need them on Paper.