Running a Hytale server is mostly about two things: how you launch it and how you talk to it once it is online. Launch options and config files define the baseline, but day-to-day control lives in commands. These are what you type into chat (with a leading slash) or into the server console to move players, shape worlds, and keep a community in line.
How Hytale server commands work
Hytale uses a familiar slash-command system. From in-game chat, you type something like /tp or /ban; from the console you drop the slash. Most powerful commands are permission-gated, so regular players can’t arbitrarily kick people or rewrite terrain.
Permissions are managed through the server’s permissions.json file and through the /perm and /op commands. A typical flow is to start the server, grant yourself operator status, then use in-game commands to manage everything else.
There is also a separate command layer for the binary itself. Launching the server uses a Java command such as:
java -jar HytaleServer.jar --assets Assets.zipExtra options like --bind, --auth-mode, and --backup change how the server behaves before commands and plugins even come into play.
Admin commands for moderating a Hytale server
Admin commands handle the core moderation and configuration work: banning, kicking, managing plugins, and bringing the server down safely. These usually require elevated permission or operator status.
| Command | What it is used for |
|---|---|
/spawning |
Controls NPC spawning. Useful for debugging mob density or creating controlled encounters. |
/ban |
Blocks a player from joining the server again. Entries are written into bans.json. |
/unban |
Removes an existing ban and lets a player rejoin. |
/gamemode |
Switches a player between modes like Adventure or Creative, matching the server’s default game mode options. |
/give |
Spawns items directly into a player’s inventory. |
/heal |
Restores a character to maximum health and stamina, useful after testing damage or boss fights. |
/kick |
Disconnects a player without banning them, often used for disruptive behavior or to force a profile reload. |
/op |
Grants operator-level access to a player, giving broad control over commands. |
/perm |
Adjusts fine-grained permissions for users or groups on top of the basic operator flag. |
/plugin |
Coordinates plugin lifecycle and options once the server supports them. |
/stop |
Shuts down the server process cleanly, flushing world and player data to disk. |
/sudo |
Executes another command as if a different player had typed it. |
/tp |
Teleports players to coordinates or to each other, critical for staff mobility. |
/whitelist |
Controls the list stored in whitelist.json, restricting access to named accounts. |
World commands for time, weather, and terrain
World commands let you shape the environment and inspect the underlying simulation. They control weather, time of day, lighting, pathing, and world-level data structures such as chunks.
| Command | World impact |
|---|---|
/block |
Operates on block states, toggling debug data or forcing state changes within a region. |
/chunk |
Inspects and controls chunk loading, which is tied directly to memory and performance. |
/fluid |
Manipulates liquids in an area, including flow behavior and placement. |
/lighting |
Adjusts lighting configuration and exposes data about how the engine is rendering light. |
/path |
Edits NPC patrol routes, which is essential for scripted encounters or safe zones. |
/time |
Shifts the in-game clock, overriding the day/night cycle settings defined per-world. |
/weather |
Forces specific weather states, which affects visibility and world ambience. |
/world |
Handles global world management and interacts with the universe/worlds directory layout. |
Hytale stores each world under universe/worlds/[WorldName]/ with its own config.json. World commands are essentially runtime controls for many of the flags that appear in those configs, such as time progression, NPC spawning, and simulation ticking.
Builder commands for fast editing
Builder commands are the power tools. They let staff define selections, copy structures, paste them elsewhere, and manage prefabs. Used correctly, they turn a live world into a design canvas.
| Command | Build workflow role |
|---|---|
/pos1, /pos2 |
Sets opposite corners of a selection box, creating the region you want to edit. |
/copy |
Copies the blocks within the current selection to a clipboard buffer. |
/cut |
Copies and removes the selection, leaving empty space. |
/paste |
Places the clipboard contents relative to the player or another reference point. |
/fillblocks |
Flood-fills air inside a selection with a specific block type, ideal for walls or floors. |
/replace |
Swaps one block type for another inside the region, used for palette changes and biome tweaks. |
/editprefab |
Enters prefab editing mode for existing or new structures. |
/prefab |
Saves, loads, lists, or deletes prefabs to reuse complex builds across worlds. |
/undo |
Reverts the last change, essential insurance for large edits gone wrong. |
These tools are powerful enough to corrupt an area if misused. Limit them to trusted builders and pair them with a reliable backup strategy, whether through the server’s own backup options or external snapshotting.
Player-facing commands for everyday use
Not every command needs admin rights. Some are safe to expose to all players because they provide quality-of-life improvements without compromising security.
| Command | Typical use |
|---|---|
/spawn |
Teleports the user back to the world’s spawn, which helps lost players regroup. |
/warp |
Lets players move to predefined locations configured by staff. |
/ping |
Shows latency and tick information, helping troubleshoot lag complaints. |
/whoami |
Prints the player’s identity and possibly current permission context. |
/help |
Lists the commands the current user is allowed to run, which doubles as a documentation index. |
/emote |
Triggers animations, giving players basic expression tools. |
/mount |
Handles mounting and dismounting, and inspects a player’s mount status. |
/damage |
Inflicts damage on a target player, generally reserved for admins testing content. |
/kill |
Kills and respawns the target, often used when a player is stuck. |
How permissive you are with these commands depends on your server culture. Warps and spawn are usually safe for everyone, while damage and kill are better kept behind admin roles.
Server launch options and console-only commands
Some of the most important controls never appear in chat at all. They live on the command line where you start the Java process. These options define how the server binds to the network, how it authenticates with Hytale’s services, and whether it performs automated backups.
| Server option | Effect | Default |
|---|---|---|
--assets <path> |
Points to Assets.zip, which the server needs to load the game content. |
None (required) |
--bind <ip:port> |
Sets the IP address and UDP port the server listens on. | 0.0.0.0:5520 |
--auth-mode <mode> |
Switches between authenticated and offline modes. | authenticated |
--backup |
Turns on periodic backups of world data. | Disabled |
--backup-dir <path> |
Sets where those backups are written. | ./backups |
--backup-frequency <mins> |
Controls the backup interval in minutes. | 60 |
--disable-sentry |
Disables crash reporting, which is recommended on dev servers. | Crash reporting enabled |
--allow-op |
Permits use of operator commands from in-game once permissions are set. | Disabled |
--accept-early-plugins |
Loads experimental plugins that might not be fully supported yet. | Disabled |
On top of server options, you also have JVM options for memory and performance:
| JVM option | Usage |
|---|---|
-Xms, -Xmx |
Set the initial and maximum heap size, like -Xms4G -Xmx4G for a 4GB heap. |
-XX:+UseG1GC |
Enables the G1 garbage collector, which generally suits servers with 8GB or more memory. |
-XX:AOTCache=HytaleServer.aot |
Uses the Ahead-Of-Time cache file shipped with the server to reduce warmup time. |
A typical production launch on Linux might look like this:
java -Xms6G -Xmx6G -XX:+UseG1GC -XX:AOTCache=HytaleServer.aot \
-jar HytaleServer.jar --assets Assets.zip --backup --backup-frequency 60To inspect all server options at any time, you can run:
java -jar HytaleServer.jar --helpAuthentication and the /auth flow
Hytale’s dedicated servers authenticate against the central account system. This enables official APIs, helps fight abuse, and unlocks planned features like discovery and payments.
After the first launch, the console prints a device login prompt:
/auth login device
===================================================================
DEVICE AUTHORIZATION
===================================================================
Visit: https://accounts.hytale.com/device
Enter code: ABCD-1234
Or visit: https://accounts.hytale.com/device?user_code=ABCD-1234
===================================================================
Waiting for authorization (expires in 900 seconds)...Once someone with access to the Hytale license completes the flow in a browser, the server confirms success and proceeds in authenticated mode. A single game license can authenticate up to 100 servers; networks that need more capacity can move to a server provider model instead.
Network, ports, and firewall rules
Many “commands not working” reports are actually connectivity failures. Hytale uses QUIC over UDP, not TCP, so firewalls and routers must be configured with that in mind.
The default server port is 5520/UDP. To change it, you bind to another port when launching the server:
java -jar HytaleServer.jar --assets Assets.zip --bind 0.0.0.0:25565On Windows, an example firewall rule is:
New-NetFirewallRule -DisplayName "Hytale Server" -Direction Inbound `
-Protocol UDP -LocalPort 5520 -Action AllowOn Linux with iptables:
sudo iptables -A INPUT -p udp --dport 5520 -j ACCEPTWith ufw:
sudo ufw allow 5520/udpWhen hosting behind a home router, forward the chosen UDP port to your server’s internal IP. Forwarding TCP alone is not enough; clients talk to Hytale servers exclusively over UDP.
Configuration files that interact with commands
Several JSON files in the server root work hand in hand with commands. Commands modify them at runtime; direct edits while the server is running are likely to be overwritten on the next save.
| File | Role |
|---|---|
config.json |
Main server settings like ServerName, MaxPlayers, and MaxViewRadius. |
permissions.json |
Permissions for roles and players, which back the behavior of /op and /perm. |
bans.json |
Stores the player identifiers affected by /ban and /unban. |
whitelist.json |
Records players approved by /whitelist subcommands. |
The main config.json also includes values that heavily affect how far commands need to reach. For example, MaxViewRadius determines how much terrain is kept active around players. The server documentation recommends dialing this down to 12 chunks (384 blocks) for most cases, as the default value can push RAM usage high.
The command set in Hytale is broad enough that you rarely need to touch files or scripts once everything is running. Admin, world, builder, and player-facing commands give you live control over moderation, terrain, and flow, while launch options and JSON configs define the frame those commands operate in. If something is unclear, /help inside the game and --help on the server binary are the two entry points that reveal exactly what your instance can do.
