Hytale server administration is built around slash commands, permission groups, and a few launch-time recovery options. To give yourself or another player full access, use /op add <player> from an authorized console or operator account; if nobody can grant OP, launch with --allow-op and run /op self. For permanent access, add the player’s UUID to the OP group in permissions.json while the server is stopped.
Command names and arguments can change with server releases. Start every session with /help, verify a command using /help <command>, and confirm that the client and server use the same protocol version. The reference below covers the documented commands, permission delegation, moderation, gameplay administration, plugins, shutdowns, and safe updates.
What are Hytale server admin commands?
Hytale admin commands are privileged instructions entered in player chat or the dedicated-server console. They control access, moderation, gameplay state, plugins, and server maintenance. A leading slash is normal in chat; many server consoles accept the command name without the slash, although the exact console convention depends on the wrapper or host.
The command surface is release-sensitive. HytaleNet’s command reference tells administrators to type /help for the complete list, while the official Hytale Server Manual notes that client and server must match the exact protocol version. An update can therefore add, remove, rename, or alter an argument even when a command appears in an older guide.
How should I read command syntax?
- Replace angle-bracket placeholders such as
<player>with a real value; do not type the brackets. - Square brackets indicate an optional argument. For example,
/heal [player]can target the sender or, when supported by your build, a named player. - Use
/help <command>immediately before relying on optional flags or nested subcommands. - Run destructive or privilege-changing commands from the console or an already trusted operator account whenever possible.
How do I get administrator or OP access?
There are three documented routes: an existing operator can grant it, a temporary launch flag can recover access, or you can persist the OP group in permissions.json. They differ in permanence, scope, and risk.
Have an existing operator grant OP
From an authorized console or operator account, use:
/op add <player>
/op remove <player>
Use the exact player name shown by the server. The community administrator guide notes that a player’s UUID remains stable even if the username changes, so UUID-based permission management is safer for long-term staffing. If your release reports a syntax error, run /help op and follow the displayed form.
What if nobody can grant OP?
Use the temporary --allow-op launch option. Stop the server, start it with the matching executable and flag, then issue /op self in the server console:
# Linux or macOS
./hytale-server --allow-op
# Windows
hytale-server.exe --allow-op
# In the server console
/op self
This is a recovery route, not automatically permanent access. Restarting without --allow-op removes the temporary route unless you subsequently persist OP membership in permissions.json. The official manual lists --allow-op among supported server launch arguments.
How do I make OP access permanent?
Stop the server before editing its permissions file. Add the player’s UUID to the OP group and ensure that group has the wildcard permission:
{
"users": {
"YOUR_UUID_HERE": { "groups": ["OP"] }
},
"groups": {
"Default": [],
"OP": ["*"]
}
}
Save the file and restart the server. The wildcard * grants full administrative access, so reserve this group for trusted operators. Manual edits made while the server is running can be overwritten: the official manual says configuration files are read at startup and written when in-game actions occur.
Which OP method should I choose?
| Method | Permanence | Scope | Execution context | Main risk |
|---|---|---|---|---|
/op add <player> |
Persistent when the server saves the permission state | Full OP privileges | Authorized console or operator account | Granting the wildcard to the wrong account |
--allow-op then /op self |
Temporary unless saved afterward | Full access during the recovery launch | Launch command plus server console | Forgetting that a normal restart removes the temporary route |
permissions.json |
Persistent after restart | Full OP or a narrower custom group | Offline file edit | Malformed JSON or edits being overwritten while online |
How can I discover the exact commands on my server?
Use the running server as the authority rather than copying an unverified subcommand. Type /help to list available commands, then /help <command> for that command’s arguments and permission requirements.
/help
/help op
/help ban
/help whitelist
/perm --help
/plugin --help
This workflow is especially important after an update, when a command family may still exist but its flags or nesting may have changed. If a command works in chat but not in the console, check the console’s slash convention and then inspect the server log for the actual parser error.
How does Hytale’s permission system work?
Ordinary players have no command permissions by default. OP accounts receive the * wildcard, while the console can use commands without being a player. For moderators and helpers, create narrower groups or assign specific permission nodes through permissions.json or the /perm command family.
What /perm commands are available?
| Purpose | Command |
|---|---|
| Show permission help | /perm --help |
| List a user’s permissions | /perm user list <uuid> |
| Add or remove a user permission | /perm user add <uuid> <permission>/perm user remove <uuid> <permission> |
| List, add, or remove a user’s groups | /perm user group list <uuid>/perm user group add <uuid> <group>/perm user group remove <uuid> <group> |
| Inspect or change a group | /perm group list <group>/perm group add <group> <permission>/perm group remove <group> <permission> |
| Test whether a permission resolves | /perm test <permission> |
Why does a permission node look unfamiliar?
Permission names depend on where a command comes from. System commands use a form such as hytale.system.command.{commandname}. Built-in mod commands use a generated hytale...command... form, and nested commands are checked through their parent chain. Granting only a deep child can therefore fail if the parent permission is still missing.
Examples documented by Hytale permission references include hytale.command.gamemode, hytale.command.op.add, and hytale.command.op.remove. Confirm the exact node on your build before assigning it, then use /perm test <permission> to verify the result for the relevant account.
Which commands moderate players and control access?
The following families cover bans, kicks, and the whitelist. Check each command with /help because optional argument names, including ban-reason flags, can change between releases.
| Task | Command | Notes |
|---|---|---|
| Ban a player | /ban <player> [--reason <text>] |
Use /help ban to verify the reason option. |
| Remove a ban | /unban <player> |
Use the exact identifier accepted by your server. |
| Kick a player | /kick <player> |
Useful for immediate removal without a lasting ban. |
| View whitelist entries | /whitelist list |
Inspect the current allow-list before changing it. |
| Enable or disable the whitelist | /whitelist enable/whitelist disable |
Enabling affects who can connect. |
| Add or remove an entry | /whitelist add <player>/whitelist remove <player> |
Apply changes using the server’s displayed player identifier. |
Ban and whitelist operations affect access rather than only the current session. Announce planned changes to your community, double-check the target, and keep an operator available so an accidental whitelist restriction can be reversed.
Which commands change gameplay or act for another player?
Gameplay administration commands alter player state or execute an instruction under another identity. Use them sparingly on a live world and confirm every argument with the current server’s help output.
| Command family | Typical form | Use |
|---|---|---|
| Game mode | /gamemode <mode> |
Changes the sender’s or the command’s selected game mode according to the build’s syntax. |
| Give an item | /give <player> <item> |
Places an item in a named player’s inventory when permitted. |
| Heal | /heal [player] |
Heals the sender or an optional target if supported. |
| Teleport | /tp <player-or-coordinates> |
Teleports to a player or coordinate form shown by /help tp. |
| Execute as another player | /sudo <player> <command> |
Runs a command as that player; treat it as highly privileged. |
/sudo can bypass the assumptions a player normally makes about who is issuing a command. Limit it to senior staff, record its use when investigating incidents, and never grant it as a convenience permission to an untrusted helper.
How do I manage plugins and shut down safely?
Plugin administration
/plugin --help opens the plugin command family on servers that have it available. Use the displayed subcommands to inspect or manage installed plugins rather than assuming a subcommand from a different release. A plugin may add its own permission nodes and nested command chain, so test those nodes separately with /perm test.
Safe shutdown
Run /stop for a controlled shutdown. Wait for the console to confirm that saving and shutdown have completed before closing a terminal, restarting a host, or replacing files. Forced process termination risks losing recent world or permission changes.
How do I update a Hytale server from the console?
Use the update workflow in stages: inspect availability, download the package, check its status, and apply it only during a maintenance window. The official manual documents these commands:
/update check
/update download
/update download --force
/update status
/update apply --confirm
/update cancel
/update patchline [name]
/update setup
- Back up first. Preserve the world and configuration before changing the server. The documented update configuration can back up
config.json,permissions.json,bans.json, andwhitelist.json. - Check availability. Run
/update check, then review the result with/update status. - Download deliberately. Use
/update downloadfor the available package. The--forceform is for a forced download and should not replace a normal check without a reason. - Schedule the restart. Warn players, stop automated jobs, and make sure the backup is complete.
- Apply the staged update. Run
/update apply --confirm. The manual says this applies the update, backs up files, and shuts down with exit code 8 so a wrapper can restart the server. - Verify after restart. Confirm the server version, test
/help, inspect permissions, and check that clients can connect using the matching protocol.
The default automatic update check interval is 3,600 seconds, or one hour. /update setup writes launcher scripts when the server is running from a Server/ directory. Use /update patchline [name] only when you intentionally need a specific update channel and have verified the name in your build’s help output.
What server setup details affect administration?
The official Hytale Server Manual, updated 12 October 2026, documents Java 25 and at least 4 GB of memory as the baseline environment. A server that is under-provisioned may appear to have command or permission problems when it is actually stalling or being terminated by the host.
Which port and protocol should I expose?
Hytale uses QUIC over UDP, not TCP. A normal installation uses UDP port 5520; if you launch with a custom --bind port, forward that UDP port instead. TCP forwarding is not required for the game connection.
What does first-run authentication require?
The documented launch form is:
java -XX:AOTCache=HytaleServer.aot -jar HytaleServer.jar --assets Assets.zip
On first run, authenticate from the console with /auth login device. The server prints a device URL and code; complete that flow before expecting players to connect.
Is there a license-side server limit?
The manual states a maximum of 500 servers per Hytale game license. That is a licensing limit, not a command permission, memory, or network limit; each instance still needs its own correctly configured files and port.
Why does a command say I lack permission?
A permission error usually means the account is not OP, the assigned node is incomplete, the command is being run in the wrong context, or the syntax changed. Diagnose it in this order:
- Run
/help <command>on the current server to rule out a renamed argument or subcommand. - Check the account’s groups with
/perm user group list <uuid>. - Inspect direct permissions using
/perm user list <uuid>. - Test the expected node with
/perm test <permission>. - For a nested command, verify the parent-chain permissions as well as the child node.
- Confirm that you are using the intended execution context: chat may require a leading slash, while a console may reject it or require it.
- If you edited
permissions.json, stop and restart the server so the file is read at startup.
Do not solve a narrow moderator problem by granting * automatically. Assign the smallest group or command permission that satisfies the job, then test it with a non-OP account.
What is the safest routine for daily administration?
- Keep one break-glass console route available and protect host credentials.
- Use
/helpafter every server update before reusing scripts or staff documentation. - Grant OP only to trusted operators; use groups for moderators who need bans, kicks, or whitelist access without full control.
- Record who performed bans, whitelist changes, permission edits, and
/sudoactions. - Stop the server before editing JSON files and keep a dated backup of the previous version.
- Back up before updates, run
/update checkand/update status, and apply changes only when players can tolerate a restart. - After updating, verify the protocol match, authentication state, port binding, permissions, whitelist, and a representative set of commands.
Frequently Asked Questions
Can I identify a player reliably if they change their username?
Use the player’s UUID for long-lived permission assignments and group membership. Names are convenient for one-off moderation, but a UUID remains stable when the account’s username changes.
Do I need to forward TCP as well as UDP for a Hytale server?
No. Hytale’s game traffic uses QUIC over UDP. Forward UDP 5520 for the default binding, or the UDP port selected by your custom --bind setting.
What should I do if an update leaves players unable to connect?
First compare the client and server protocol versions and confirm that the server completed its restart. Then check the bound UDP port and run /help locally; an update can change command behavior even when networking is configured correctly.
Can a moderator have ban access without becoming OP?
Yes. Create or use a group with only the required permission nodes, add the moderator’s UUID to that group, and verify the result with /perm test. This avoids giving the account the OP wildcard.