# Create a controlled Multiverse-Portal between worlds

Multiverse-Portals creates a defined gateway region that teleports players to a destination. It is useful for a hub or event entrance, but a portal does not automatically make the destination world safe or grant players permission to enter it.

## Prepare both ends

Install compatible Multiverse-Core and Multiverse-Portals releases on a supported server. Check each release's requirements instead of mixing an old addon with a newer Core major version. Confirm the source and destination worlds are already loaded, and record their actual identifiers.

Back up the worlds and Multiverse configuration before changing established travel routes. Keep a list of existing portal names and destinations. Choose a unique test name so the new gateway cannot accidentally replace a public entrance. See [game backups](https://help.cloudexa-hosting.com/books/game-hosting/page/back-up-game-files-before-making-changes) and [world management](https://help.cloudexa-hosting.com/books/minecraft-plugins/page/add-and-import-minecraft-worlds-with-multiverse-core).

## Select a small gateway

1. Join as an authorised administrator and build a modest entrance with a clear exit area. A decorative frame is not the teleport region itself.
2. Use `/mvp wand` to begin a selection. If the plugin reports that WorldEdit is handling selections, use the WorldEdit selection tool instead.
3. Select opposite corners of the intended gateway. Read the reported volume and correct it if it unexpectedly spans a large part of the world.
4. Confirm that the destination spawn is safe for a normal player. Avoid a location inside a block, over a drop or in the middle of a different portal region.
5. Use the installed help to create the named portal with the intended destination. Current documentation accepts a world destination such as `/mvp create lobby_exit w:survival`; replace both names with your verified values.

In-game commands include a leading slash. Selection steps require a player; pasting a position-dependent command into Console cannot reproduce the administrator's location.

## Grant only the intended travel access

For a portal named `lobby_exit`, the documented access node is `multiverse.portal.access.lobby_exit`. Grant it to the intended group with your permissions plugin. Keep world-access requirements in place where enforced; portal permission and destination-world permission are separate checks.

Do not disable all portal-access enforcement because one test player cannot travel. First check the exact portal name, destination, effective group permissions and any other region restrictions. Test with a non-operator account because administrators may bypass normal checks.

## Test return travel and failure cases

Walk through once, inspect arrival position, and verify the player can leave safely. Return travel is a separate design decision: creating a gateway does not necessarily create the reverse route. Check both directions if your announcement promises a two-way connection.

Also test a player who should be denied. Avoid enabling entity or vehicle travel until you have assessed farms, item transport and potential loops. Do not attach console-command portal actions simply to solve a basic destination issue; those actions can have much wider consequences.

If travel loops or arrives incorrectly, temporarily restrict use and inspect the named portal's destination. Keep the world data intact. Send support the two world identifiers, portal name and error time. Further reading: [portal selection and destinations](https://mvplugins.org/portals/fundamentals/basic-usage/) and [portal permissions](https://mvplugins.org/portals/reference/permissions-list/).

Looking for another plugin? [Browse the Minecraft plugin guide directory](https://help.cloudexa-hosting.com/books/minecraft-plugins/page/find-a-minecraft-plugin-setup-or-troubleshooting-guide).