Best Hytale Server Settings for 2026

Every game with an Early Access launch attracts a crowd of "best settings" guides within about a week, and Hytale hasn't been any different. Most of the ones I've skimmed are the same handful of fabricated numbers laundered through different wrappers – -XX:+UseG1GC block pasted straight from Minecraft Paper guides, fake "default view distance is 24" claims, and max-players=16 written as if Hytale's config were a flat properties file (it isn't – it's JSON).

This is my take on what actually matters in Early Access, based on running Hytale servers for a couple of months now. It's shorter than most similar guides because Hytale just doesn't have as many meaningful settings to tune as Minecraft does, and I refuse to pad it with fake ones.

Start here: pick the right size

The setting with the biggest impact on your server isn't in a config file at all – it's how much RAM you bought. Hytale's minimum is 4 GB. Beyond that, the rough shape is:

• Small vanilla friend group (up to ~6 players) – 4 GB is genuinely fine.
• Medium group, light modding (~10–15 players) – 6 to 8 GB.
• Larger community, moderate modding (~15–25 players) – 10 to 12 GB.
• Bigger public server or a heavy mod pack – 16 GB or more, and think about the premium CPU option.

If you've picked a tier that's too small and you see RAM sitting at 90%+ in Current Activity & Stats on the LOW.MS panel, no amount of config tuning is going to fix it – upgrade first, tune second.

The settings that actually matter

Hytale uses a JSON config (config.json at the root of your server directory – plus a per-world config.json under universe/worlds/<world>/ for world-specific stuff). Key names have drifted a bit between Early Access builds, so rather than paste in exact JSON snippets that might already be out of date, I'm going to describe what to set and why.

The handful that I'd actually change on a new server:

• Server name. Obvious but worth saying. Keep it short enough to fit in the server browser list view.
• Game mode. Exploration or Creative. Pick this before anyone joins – you can change it later, but you'll want to take a backup first.
• Max players. Set this conservatively based on your RAM tier. The fastest way to have a bad first night on a new server is to set max players to 50, have everyone log on at once, and watch the tick rate collapse. Start lower than you think you need and raise it once you've seen how the server handles a full lobby.
• World seed. If you have a seed you like, set it now. If not, leave it blank to roll a random world – but if you find a good one, write it down. The seed is the only way to reproduce the same world later.
• PvP. Off on build/creative servers, on for Exploration servers where PvP is part of the point. Turning it off later after griefing has already happened is too late.
• Password or whitelist. If the server is private, set one. Whitelisting is more robust than a password – the whitelist and password guide covers both.

Everything else in config.json – MOTD, connection timeouts, rate limits – can be left on the defaults. In Early Access there aren't enough players stress-testing those edges for the defaults to be wrong.

JVM settings: keep it boring

Here's the section where every other guide pastes in fifteen lines of G1GC tuning. I'm not going to do that, because those flags aren't validated for Hytale – they're Aikar's Minecraft Paper flags and they were tuned for a very different workload on a very different Java version.

The two JVM settings I'd actually use on a Hytale server in 2026 are:

-Xms<N>G -Xmx<N>G
-XX:AOTCache=HytaleServer.aot

-Xms and -Xmx should be set to the same value – letting the JVM resize the heap at runtime just adds GC work. Leave about 1 GB of headroom for the OS: on a 4 GB plan, use 3 GB; on 8 GB, use 7; on 16 GB, use 15.

The AOT cache flag is the one Hypixel ships with. It speeds up startup significantly on the second and subsequent boots. The first run builds the cache file; subsequent runs use it.

That's it. Java 25's defaults are enormously better than the Java 8 defaults everyone's muscle memory comes from, and the Hytale workload does not need anything more exotic. If your server is lagging and your instinct is to paste in more JVM flags, please read the performance guide instead – the answer is almost always RAM or a misbehaving mod.

On LOW.MS, memory is pre-configured for your plan and the AOT cache is enabled by default, so you don't need to touch any of this unless you specifically want to.

Settings by scenario

Rough shapes by server type, focusing on the handful of settings that actually differ between use cases.

Small vanilla server

• RAM tier: 4 GB.
• Max players: 8 or lower.
• Game mode: Exploration.
• PvP: up to the group.
• Whitelist: yes, if it's a friend group.
• Scheduled restart: one per day at a quiet time (Scheduled Tasks in the panel).

On a small vanilla server you mostly don't need to tune anything. Hytale's defaults are fine.

Medium server, 10–15 players, light mods

• RAM tier: 6 to 8 GB.
• Max players: set to match what your RAM tier can hold – 10 to 15.
• Game mode: Exploration.
• PvP: up to you.
• Whitelist or password: set one if you don't want random joins.
• Mod count: keep it focused. The temptation is to install every cosmetic pack you can find; resist it.
• Scheduled restart: daily at a quiet time.
• Pre-generate spawn area: worth doing once you've settled on a world.

Large community server, 20+ players

• RAM tier: 12 GB or more.
• Premium CPU: worth considering for the single-thread headroom.
• Max players: conservatively at first, raise once you've tested.
• Pre-generation: strongly recommended. Set a world border around the pre-generated area.
• Mod load: audit carefully. On a busy server, a badly-behaved mod will hurt every player at once.
• Scheduled restart: daily. Consider twice a day if you see RAM creep up noticeably over a 24-hour period.
• Monitor RAM and CPU in Current Activity & Stats during peak play, not at 3am when nobody's on.

Creative/build server

• RAM tier: 6 to 10 GB depending on player count and build size.
• Max players: higher than an equivalent Exploration server – creative mode skips most of the AI and resource work.
• Game mode: Creative.
• PvP: off. Builders do not need each other swinging weapons around.
• View distance: you can usually get away with a bit more than on an equivalent Exploration server because there's no mob simulation load to speak of.
• Backups: take them often. Creative servers accumulate irreplaceable builds and the one time you forget to back up is the one time something goes wrong.

Modded server

Modded is the most variable category because "modded" can mean anything from five cosmetic packs to a total-conversion pack that triples the entity count. A few rules of thumb:

• Start one tier higher in RAM than you'd pick for the equivalent vanilla server. Mods almost always want more memory than you think.
• Install mods before players join. Adding major mods to a populated server mid-campaign is asking for trouble.
• Check each mod's config file after installation, in the config/ directory. Many mods ship with defaults tuned for singleplayer and those defaults are often wrong for a dedicated server.
• Bisect ruthlessly if performance drops after a mod install – half the mods, restart, see if the lag is gone, and keep halving. The performance guide covers the process in more detail.
• Take a backup before every mod change. Really, every single one.

Networking

Hytale uses QUIC over UDP, port 5520. If you're self-hosting, open UDP 5520 in your firewall and (if you're behind a NAT) forward it. TCP is not used at all; ignore any guide that tells you to forward it. On LOW.MS, all of this is done for you at provisioning and DDoS protection is on by default.

A note on "best settings" guides in general

Almost every "best settings" guide for a new game is bullshit for the first six months of its life, because nobody has been running the game at scale long enough to actually know what the best settings are. Hytale is no exception. The settings I've described above are the ones I've found to be defensible in April 2026 – if you're reading this a year from now, the landscape will have shifted and some of the advice will have dated.

The closest thing to a universal rule is: start conservative, monitor your server under real load, and change one thing at a time. That's how you get a server that actually runs well, rather than one full of copy-pasted flags from a blog post.