27 January 2026

Hytale Server Settings Guide: Every Configuration Option Explained

The Hytale settings worth knowing about — what lives in `config.json`, the launch flags that matter, and some honest advice on JVM memory so you don't copy Aikar flags for the wrong game.

Hytale Server Settings Guide: Every Configuration Option Explained

Hytale's Early Access launch in January 2026 means the server is still young — there are fewer knobs to turn than you'd find on a mature Minecraft setup, and honestly that's a good thing. This guide walks through every Hytale server setting worth knowing about: what lives in config.json, what you can change from the launch command, and a couple of JVM pointers that won't get you into trouble.

I'm going to skip the stuff that's obvious ("set a password, pick a server name") and focus on the settings I actually get asked about.

Where the settings live

Hytale uses a JSON config file — config.json — in the root of your server directory. That's worth underlining: it's not a flat server.properties like Minecraft. If you've been editing Minecraft configs for years, the first thing to know is that you cannot paste key=value lines into a Hytale config. JSON is fussy: matching braces, commas between fields, strings wrapped in double quotes.

Each world also has its own config.json under universe/worlds/<world_name>/ — that's where world-scoped settings (seed, difficulty, world-specific rules) live, separate from the top-level server config. Server-wide stuff goes in the top-level file; per-world stuff goes in the world's own file.

On LOW.MS you don't need to touch any of this via FTP unless you want to. Open Configuration Files in the control panel, pick the config you want, and edit it in the browser with syntax highlighting. File Manager is there as a fallback if you'd rather browse the whole directory tree.

Important: the server reads configs on startup, and in-game actions may overwrite them on shutdown. Stop the server first, edit the file, then start it again. Editing while the server is running is a recipe for losing your changes.

Server-level settings

These live in the top-level config.json. Exact key names and casing have shifted a bit between Early Access builds, so if something in this guide doesn't match what you see in your own file, trust your file over me.

The settings worth caring about:

  • Server name — what players see in the Hytale browser and their favourites list. Keep it short enough to fit in a list view.
  • Password — if set, players have to enter it to join. Useful for a quick-and-dirty private server, though whitelisting is more robust. Both options are covered in the whitelist and password guide.
  • Max players — set this to match what your RAM tier can comfortably hold. Don't set it to 50 on a 4 GB server because you read somewhere that Hytale is "lightweight". It isn't, and the first time everyone logs on at once you'll find out.
  • Game mode — Exploration or Creative. You can flip between them without losing the world, but you'll want to stop the server and take a backup before you do.

Everything else — MOTD, connection limits, rate limits — can be left on the defaults until you have a reason to touch them. There aren't enough players pushing the limits in Early Access to need aggressive tuning.

World generation settings

World settings live inside each world's own config.json under universe/worlds/. The interesting ones:

  • Seed — set this if you want a reproducible world, or leave it to roll a random one. If you find a seed you love, write it down; it's the only way to get that exact world back.
  • PvP — on or off. Turn it off on creative and build servers unless you enjoy griefing as a sport.

World-gen settings are baked into chunks as they generate. If you change biome rules or the seed after players have been exploring, only newly generated chunks pick up the new rules — the old area stays as it was. So pick your world settings before you let anyone in.

The launch command and startup flags

The Hytale server is a JAR file: HytaleServer.jar. The normal launch command looks like this:

java -jar HytaleServer.jar --assets Assets.zip

On Java 25 you can speed up startup significantly by pointing it at an AOT cache:

java -XX:AOTCache=HytaleServer.aot -jar HytaleServer.jar --assets Assets.zip

The first run builds the cache; subsequent runs use it. On LOW.MS this is configured for you — you don't need to think about it.

A couple of flags worth knowing:

  • --bind 0.0.0.0:<port> overrides the default UDP port. Use this if you're running multiple servers on one host or your provider has assigned you a specific port. On LOW.MS your port is set at provisioning, so you won't need this unless you're self-hosting.
  • --help prints the full list of flags the current server build accepts. If you're on a newer build than this guide, that's the source of truth.

On LOW.MS the launch command lives in Commandline Manager. If you need to add a custom flag, that's where it goes.

Networking: port and protocol

Hytale uses the QUIC protocol over UDP. Default port is 5520 UDP. TCP is not used at all — don't waste time forwarding it in your firewall.

If you're self-hosting and players can't connect, the checklist is: did the server finish its /auth login device authentication on first launch? Is UDP 5520 open in your firewall? If you're behind a NAT, is UDP 5520 forwarded to the right machine? Nine times out of ten, connection problems fall into one of those three buckets.

On LOW.MS the port is opened automatically at provisioning, and DDoS protection is on by default.

JVM memory allocation

This is the one place where there's actually a meaningful dial to turn. Hytale is a Java server, so you control how much memory the JVM can use with -Xms (initial heap) and -Xmx (max heap).

A couple of opinions:

  • Set -Xms and -Xmx to the same value. Letting the JVM resize the heap at runtime just adds garbage collection work for no benefit.
  • Leave around 1 GB of headroom for the operating system. On a 4 GB plan, allocate about 3 GB to the JVM; on 8 GB, allocate 7.
  • Don't copy-paste Minecraft's "Aikar flags" into your Hytale server. Those are tuned for a specific Minecraft Paper workload and aren't validated for Hytale. Java 25's defaults are much better than the defaults from the Java 8 era, and the AOTCache flag Hypixel ships is the main JVM trick worth using.

On LOW.MS memory is pre-configured for your plan — you don't need to set anything. If you're self-hosting and want to know whether you're memory-bound, watch for rising CPU with a stable player count. In a Java server that's usually GC pressure, and the fix is either more RAM or fewer mods.

Mods and the mods/ folder

Mods go into the mods/ folder at the root of your server directory as .zip or .jar files. Restart the server after adding or removing anything.

The genuinely nice thing about Hytale is that mods are delivered from the server to players at connect time. You install them once on the server, and everyone who joins gets them automatically — no mod loader, no version-mismatch hunt, no begging your friends to install a launcher. This is easily the best modding experience I've run in years. The full panel walkthrough is in the mods, assets, and plugins guide.

A few things that aren't in config.json

Some things Minecraft admins expect to be config settings are handled elsewhere in Hytale:

  • Permissions and ranks live in permissions.json. Full breakdown in the permissions and ranks guide.
  • Whitelist entries live in whitelist.json, and bans live in bans.json. You edit these through the control panel's Configuration Files just like the main config.
  • Scheduled restarts and other recurring tasks are handled by the control panel's Scheduled Tasks feature rather than anything in the server config itself.
  • Backups are handled by LOW.MS automatically. You can trigger a manual backup any time from Cloud Backup, and restore from Cloud Restore if something goes sideways.

Applying changes

The rhythm on LOW.MS is: stop the server from the control panel, edit the config in Configuration Files, start it again. Most settings apply on the next boot. A few (like the server name) can also be changed live through admin commands, but a restart is the safe default when you're not sure.

If you want to see whether your changes actually landed, open Web Console and watch the startup logs — the server prints the loaded config when it boots. If you made a JSON typo, it'll tell you right there rather than silently falling back to defaults.

Join our Discord to chat with our staff and community!
Join Discord