# Multiverse-Core: the plugin that made multiple Minecraft worlds manageable > Multiverse-Core is the original Bukkit multi-world plugin, created at the dawn of Bukkit's multiworld support and now the core of a family of addons for portals, per-world inventories and per-world nether and end dimensions. It is BSD licensed, published on four distribution channels at once, and built with a single Gradle command. **Multiverse/Multiverse-Core** — The original Bukkit Multi-World Plugin! - Repository: https://github.com/Multiverse/Multiverse-Core - Stars: 1,103 · Forks: 357 - Language: Java - License: BSD-3-Clause - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/multiverse-multiverse-core ## The plugin that made multiple worlds normal The repository description is a claim and a piece of history at once: the original Bukkit Multi-World Plugin. The About section expands on it. Multiverse was created at the dawn of Bukkit multiworld support, and has since grown into a complete world management solution, providing what the README calls the easiest to use world management solution for a Minecraft server, big or small. The problem it solves is easy to underestimate until you have run a server with more than one world. Minecraft's own world management assumes one overworld, one nether and one end. A server that wants a survival world, a creative world, a minigame arena and a hub has to create those worlds, set their spawn points, control who may enter them, decide what happens to inventories and player stats when someone walks through a portal, and keep all of that consistent across restarts, reloads and plugin reloads. None of that is interesting work, and all of it has to be right. The value of a plugin like this is that the interactions between worlds, inventories, statistics and permissions were solved once, by people who ran big servers, rather than by each server owner in turn. The project is also careful to say it is a family, not a single plugin. The addons it names, Portals and NetherPortals, are described as great addons, and the newer wording calls the whole thing a complete world management solution. ## Four sub-modules, each solving one problem The README lists four sub-modules, and the list reads as a map of the questions a multi-world server raises. Multiverse-NetherPortals gives you separate nether and end worlds for each of your overworlds, which is the first thing you hit when you run a survival server and a creative server on the same installation and discover that they share one nether. Multiverse-Portals makes custom portals to any destination, so the teleport destinations are data rather than configuration, and a hub world can send players to the right place without every plugin needing to know about every world. Multiverse-Inventories has separated player stats and inventories per world, or per group of worlds, which is the second thing you hit and the one with the most data-loss risk if it is wrong. Multiverse-SignPortals turns signs into teleporters, which is the classic way players expect to move between worlds in a server that does not have a portal plugin. The family structure is also how the project maintains itself. Each addon is a separate repository, so a bug in the portal code does not block a release of the core, and a server owner can pick exactly the addons their design needs rather than installing a fixed set. For a server administrator reading this, the practical test is which of the four questions above their players have already asked. Each addon corresponds to one of them, and the answers are independent. ## The same plugin on four distribution channels The badges at the top of the README are worth attention, because they are unusual for a plugin of this size. The same project is published on Modrinth, on Hangar, on Bukkit, and on Spigot. The reason is historical and practical. Bukkit is the API the plugin targets, and Spigot is its commercial descendant and the platform a lot of servers run. Modrinth and Hangar are the newer plugin distribution platforms, and both are linked from the README badges. Publishing to all four is a distribution decision with a cost, because each platform has its own review process, its own build pipeline and its own release cadence, and a version can reach one platform before another. The release list shows how that plays out in practice, with a 5.8.1-pre.3 prerelease on 2026-08-25, then 5.8.1 on 2026-08-28, and then a 5.8.2-pre prerelease on 2026-10-09. The prerelease tags are the interesting part. A 5.8.2-pre sitting as the newest tag means the project offers pre-release builds, which is a way of getting fixes into the hands of server operators before the stable release lands, and which also means a plugin manager that tracks prereleases will install a different build than one that tracks stable. The other badges are the support and funding routes: a Discord, a GitHub Sponsors link and an Open Collective page for the plugin family. ## Building it is one Gradle command The Building section is a single line, which is what you would expect from a plugin that uses the standard build for the platform: ```bash ./gradlew build ``` The repository is set up for that, with build.gradle and settings.gradle at the root, the gradlew and gradlew.bat wrappers for Unix-like systems and Windows, and a gradle/ directory holding the wrapper configuration. The src/ directory holds the Java sources, config/ holds the plugin configuration resources, and docs/ holds documentation, with .github/ for the workflows. The wrapper is worth noting rather than ignoring. Shipping gradlew and gradlew.bat means a contributor or a server administrator does not need a matching Gradle installation, and the wrapper pins the Gradle version the project expects, which is the difference between a build that works for everyone and one that works on the maintainer's machine. For a Java project of this size, that is the whole build story. There is no code generation step, no native build, and no external service in the loop. ## The wiki, the issue labels and the way in The project runs on a documentation-first model, and the README spends as much space on how to help as on what the plugin does. The documentation lives in the GitHub wiki, with a Basics usage guide, and there is a dedicated site, mvplugins.org, hosting the wiki. The About section points newcomers at the wiki and the usage guide to get started. The contribution routes are specific rather than a general invitation. The first is to take a look at the issues labelled Bug: Unconfirmed, where issues need extra testing and investigation. The second is to join the Discord community and help other users with issues and setup. The third, for anyone with a Multiverse guru's habit, is to update the wiki with the latest tips, tricks and guides, and the wiki is open for all to edit, with the wiki source in a separate repository, multiverse-web. For coders, the route is the issue tracker, with two labels that describe the state of a ticket: State: Open to PR and Resolution: Accepted. That pairing is a small, good piece of process design, because it tells a contributor which issues are actually welcome work and which have already been decided, and it means a bug report that has been verified becomes a well-defined task rather than an open discussion. The funding routes are the last item, GitHub Sponsors and an Open Collective for the plugin family, and the README closes by thanking the people who have supported the project over the years. ## Where Multiverse is the wrong tool The first wrong-tool case is a single-world server. If your server has one world and no plans for more, a multi-world manager is configuration you do not need and a set of behaviours to reason about, including the inventory and statistics separation that a single-world server has no reason to enable. The second is a server that has already solved this with a different approach. A server that manages its worlds with its own custom plugin, or with a platform feature, is now facing a migration: the world data, the permissions model, the portal configuration and the inventory handling all have to be reconciled, and the README documents none of the migration path, which is understandable for a project of this age but means the cost is yours to estimate. The third is a platform outside the four. The plugin targets Bukkit and its descendants. It is not a Paper plugin in the modern sense with a paper-plugin.yml, and it is not a Fabric or NeoForge mod, so on a server built on a different platform it is simply not applicable, and the four distribution channels are the complete list of where it can come from. There is also a version-management point, and it is the one that bites in practice. Because the plugin is released in parallel across four platforms, in stable and prerelease flavours, a server whose plugin manager tracks prereleases can end up on a different build than a server that tracks stable, and the failure appears in the world data rather than in a load error. ## BSD-3-Clause, version 5.8, and a project that predates most of the ecosystem Multiverse-Core is licensed under the BSD-3-Clause License, with LICENSE.md at the repository root. The version line is where the age shows. The releases are 5.8.2-pre from 2026-10-09, 5.8.1 from 2026-08-28 and 5.8.1-pre.3 from 2026-08-25. So the plugin is at 5.8, which for a project that started at the dawn of Bukkit multiworld support says more about longevity than about any single feature. The repository is not archived, and the last push was on 2026-10-09, the same day as the newest tag, so the project is still worked on. The default branch is main, and the language is Java, with the bukkit and bukkit-plugin topics alongside hacktoberfest, which is a fair description of a mature community project. What stands out is the shape of the contribution model. The plugin that pioneered a feature in its ecosystem has turned into a platform with a family of addons, a wiki with its own repository, a Discord, two funding channels, and a labelled-issue workflow. For an adopter, that means the interesting questions are not about the core plugin, which is a solved problem, but about which addons to install and which channel to track for updates. ## Conclusion Adopt Multiverse-Core if you run a Minecraft server that needs more than one world and you want the ecosystem around it, since Portals, NetherPortals, Inventories and SignPortals all assume the core is present. Do not adopt it for a single-world server, where the extra configuration buys nothing, and do not expect it to be a plugin you can extend with your own code without reading the wiki first, because the extension points are documented on the project's own site rather than in the repository. Before you deploy, read the wiki and the usage guide, and check which of the four distribution channels your server platform actually pulls from, because the versions are released in parallel and a mismatch there is the most likely source of confusion. ## FAQ ### What does Multiverse-Core do for a Minecraft server? It is a world management plugin for Bukkit-based servers, created at the dawn of Bukkit multiworld support and now described as a complete world management solution. It handles creating and managing multiple worlds on a server, big or small, and is the core of a family of addons. ### Which Multiverse addons exist and what do they do? Multiverse-NetherPortals gives separate nether and end worlds for each overworld, Multiverse-Portals makes custom portals to any destination, Multiverse-Inventories separates player stats and inventories per world or group of worlds, and Multiverse-SignPortals turns signs into teleporters. ### How do I install Multiverse-Core? The plugin is published on four platforms at once, Modrinth, Hangar, Bukkit and Spigot, so you install it from whichever one your server platform uses. The README points to the wiki and the Basics usage guide to get started. ### How do I build Multiverse-Core from source? With Gradle, using the wrapper committed in the repository: run ./gradlew build. The tree holds build.gradle, settings.gradle, the gradlew and gradlew.bat wrappers, the src/ directory with the Java sources, config/ for plugin resources and docs/ for documentation. ### What licence is Multiverse-Core released under? BSD-3-Clause, with LICENSE.md at the repository root. The most recent tag is 5.8.2-pre, dated 2026-10-09, and the last push was on the same day. ## Sources - [Issues](https://github.com/Multiverse/Multiverse-Core/issues) - [License: BSD-3-Clause](https://github.com/Multiverse/Multiverse-Core/blob/main/LICENSE) - [Multiverse/Multiverse-Core on GitHub](https://github.com/Multiverse/Multiverse-Core) - [README](https://github.com/Multiverse/Multiverse-Core/blob/main/README.md) - [Releases](https://github.com/Multiverse/Multiverse-Core/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/multiverse-multiverse-core