Set up personal homes and teleport requests with HuskHomes

HuskHomes provides named homes, teleport requests and optional cross-server travel. Start with one backend server and two ordinary test accounts. Personal homes should remain private unless their owner deliberately makes them public; shared warps are a different feature with different permissions.

Install the appropriate release

Check the project's setup instructions for your Minecraft version, platform and Java runtime. A Fabric mod build and a Bukkit-family plugin build are different downloads. Stop the server, make a completed backup and place the correct build in the directory used by that platform. Keep only one installed copy.

Start once to generate configuration, inspect Console for dependency or database errors, then stop before editing. Preserve the generated files rather than replacing them with a configuration copied from another version. See the plugin installation guide for the panel file workflow.

Decide which plugin owns home and teleport commands. EssentialsX or another teleport plugin may already register similar names. Check the installed release's command and alias documentation before changing aliases; a command completing successfully does not prove HuskHomes handled it.

Create and use a private home

For a controlled trial, give the test group the documented permissions for the features you want, rather than an administrator wildcard. The documented command permissions include huskhomes.command.sethome and huskhomes.command.home. Check the release's separate limits and permission defaults before promising a particular number of homes.

Stand at a safe location and run /sethome trial. Move away, use /homelist to check the entry and return with /home trial. Confirm the destination, world and facing direction. Restart normally and repeat the return test to check persistence.

Keep this test home private. If public homes are part of your service, the documented privacy command is /edithome trial privacy public; return it to private afterwards. Check access from the second player rather than assuming the owner's view represents everybody's access.

Check requests, delays and protection

Use /tpa followed by the other test player's name, then have that player use /tpaccept. Check the resulting location and any configured warmup, cooldown or charge. Test refusal or expiry as well as acceptance. Avoid request spam while measuring behaviour.

Confirm that your intended restrictions work in protected areas and excluded worlds. Plugin support for a protection system must be verified with the relevant versions. Test as a non-operator; operators can bypass rules that ordinary customers encounter.

Prepare a network separately

Cross-server homes require the documented shared database and messaging configuration, with distinct backend server names. Use an isolated test database and messaging namespace first. Keep authentication and player UUID handling consistent across the network; changing these can make existing homes appear to belong to different players.

Do not point a live clone at production storage to see what happens. Back up data before a network change, stop affected writers during a planned migration and compare the resulting home records. The shared database is not a replacement for recoverable server backups.

If a command fails, report the exact message, server and plugin versions, backend name and relevant redacted configuration. Never include database passwords. Further reading: official setup and commands and permissions.

Looking for another plugin? Browse the Minecraft plugin guide directory.