VGKAMI
Advertise Get listed

Game Guides

Hytale Server Settings Explained: The Best Config for Your Group

October 26, 2026 12 min read

For a private Hytale group, start with the root config.json: set a recognizable server name and MOTD, add a password, cap MaxPlayers at the number who may play together, and begin with MaxViewRadius set to 12 chunks (384 blocks). Put rules such as PvP, fall damage, NPC spawning, and paused game time in the affected world’s universe/worlds/<world>/config.json. Stop the server before editing, keep a backup, and allow Hytale’s default QUIC traffic through UDP port 5520. A dedicated server can start with at least 4 GB of memory and Java 25, but real capacity depends on CPU, memory, entities, and how independently players explore.

What is the best starting configuration for a private Hytale server?

The safest general-purpose profile is a small, password-protected Adventure server with an eight-player cap, compression enabled, and a 12-chunk view-radius limit. These values are a practical starting point for a group, not an official promise that one machine can sustain eight players in every situation. Change the cap to match your actual group and verify performance while people play.

{
  "Version": 3,
  "ServerName": "Our Hytale Group",
  "MOTD": "Private server for friends",
  "Password": "choose-a-private-password",
  "MaxPlayers": 8,
  "MaxViewRadius": 12,
  "LocalCompressionEnabled": true,
  "Defaults": {
    "World": "default",
    "GameMode": "Adventure"
  }
}

Keep the password out of public posts and replace the example values before starting. The root file also contains connection timeouts, rate limits, modules, logging, mods, and storage-provider settings, so preserve fields you did not intend to change.

Which Hytale file controls each setting?

Hytale separates server-wide controls from rules that belong to one world. Editing the wrong file can make a change appear not to work or unintentionally affect every world.

Location Use it for Examples
config.json in the server root Values shared by the server and connection ServerName, MOTD, Password, MaxPlayers, MaxViewRadius, LocalCompressionEnabled, default world, default game mode, timeouts, rate limits, modules, logging, mods, and storage providers
universe/worlds/<world>/config.json Rules for one world IsPvpEnabled, IsFallDamageEnabled, IsGameTimePaused, IsSpawningNPC, saving and unloading flags, GameplayConfig, compass updates, and objective markers
permissions.json Permission assignments and operator-style access Who can perform administrative actions
bans.json Players who are blocked from joining Ban records
whitelist.json Allow-list data Entries managed through the whitelist permission system

The exact world directory name replaces <world>. If you run several worlds, repeat world-level edits in each relevant directory rather than putting gameplay flags in the root file.

How do I change Hytale server settings without losing them?

Always make configuration changes while the server is stopped. The setup guidance warns that manual edits made while the process is running can be overwritten, and configuration files may be written during actions such as permission changes.

  1. Stop the server completely. Wait for the process to exit and for its final save to finish.
  2. Back up the configuration and world data. Copy the root config.json, the universe/ directory, and access-control files such as permissions.json, bans.json, and whitelist.json to a separate location.
  3. Edit the correct JSON file. Use a text editor that preserves UTF-8 text and does not add comments. JSON requires double quotes, commas between properties, and matching braces.
  4. Start the server and read the logs. A syntax error or unknown value should be fixed before inviting the group.
  5. Test with one or two players. Check the connection, the intended gameplay rule, and whether the server remains responsive while the players move through new terrain.
  6. Keep the backup through a normal restart. If the setting survives stopping and starting the server, archive the previous copy rather than deleting it immediately.

If a setting reverts, compare the file after shutdown with your edited copy. A running process, a permission action, an update operation, or an edit to a generated world file can explain why the value changed.

What should MaxViewRadius be?

Use 12 chunks, equal to 384 blocks, as the initial maximum. Hypixel Studios recommends limiting maximum view distance to 12 chunks (384 blocks) for both performance and gameplay. The configuration guidance describes 12 as standard and 16 as high; treat 16 as an experiment only after testing your host with the group’s real activity.

View radius is the largest performance lever exposed in this profile. Hypixel Studios explains that doubling view distance from 192 to 384 blocks quadruples the amount of world around the player. More loaded terrain means more chunk work, entities, memory pressure, and background activity, especially when players travel in different directions.

Profile MaxPlayers example MaxViewRadius When to use Important qualification
Two-to-four-player co-op 4 12 chunks / 384 blocks Building, quests, or local exploration Still observe memory and CPU when new terrain loads
Small private group 8 12 chunks / 384 blocks The baseline profile shown above Eight is a cap example, not a capacity guarantee
Larger group or independent explorers Set to the number who may actually connect 12 chunks / 384 blocks initially Players spread across several regions Lower the cap or radius if CPU, RAM, or garbage collection becomes unstable
High-distance test Your tested cap 16 chunks Only after measuring the host under normal play 16 is described as high; it is not a guaranteed supported workload

Do not raise the radius simply because the machine has unused memory while nobody is moving. Test during the busiest pattern your group creates: simultaneous travel, combat, entity-heavy bases, and players exploring separate directions.

How many players can a Hytale server support?

MaxPlayers limits simultaneous connections; it does not certify that the server can sustain that many active players. Actual capacity changes with CPU speed, available RAM, entity counts, loaded terrain, view radius, and whether players remain together or explore independently.

Choose a cap from the number of people who may be online together, then validate it rather than treating it as a hardware specification. During a busy session, watch CPU utilization, memory consumption, and garbage-collection behavior. If the server stutters when several players load new areas, reduce the view radius first; if the host remains saturated, reduce the player cap or move to stronger hardware.

  • CPU pressure: look for sustained high utilization or delayed simulation while players travel or entities accumulate.
  • Memory pressure: watch for steadily rising use, allocation failures, or frequent collection pauses.
  • Workload shape: eight players in one base can stress the server differently from eight players generating eight separate regions.
  • Repeatability: test after a restart and during the same activities your group normally performs, not only during an empty-server check.

How much RAM and which Java version does Hytale need?

The official server manual lists at least 4 GB of memory and Java 25 for a dedicated server. Treat 4 GB as a floor for trying the server, not as a recommendation for a busy group. The manual also makes clear that real usage depends on players, entities, and how much of the world is loaded.

Reserve memory for the operating system and other services instead of assigning every gigabyte to Java. If the machine hosts backups, monitoring, voice chat, or other game servers, those workloads reduce the headroom available to Hytale. A server that starts successfully with 4 GB can still become unstable when the group spreads out or creates many entities.

What should I monitor during a test session?

  • Peak and sustained RAM use while players explore independently.
  • CPU load during terrain generation, combat, and entity-heavy areas.
  • Garbage-collection frequency and pause behavior in the server logs or runtime monitoring.
  • Connection delay, tick or simulation stalls, and whether players are disconnected when load rises.

Change one major variable at a time. For example, keep the radius at 12 while raising the player cap, or keep the cap fixed while testing a radius of 16, so you can identify which change caused a regression.

How do I change PvP, fall damage, NPCs, and other gameplay rules?

Edit the affected world’s universe/worlds/<world>/config.json, not the root server file. The world configuration example includes these controls:

Setting Effect to verify in-game
IsPvpEnabled Whether player-versus-player combat is enabled in that world
IsFallDamageEnabled Whether falling harms players
IsGameTimePaused Whether the world’s game time is paused
IsSpawningNPC Whether NPC spawning is enabled
IsSavingPlayers Whether player state is saved
IsSavingChunks Whether world chunks are saved
IsUnloadingChunks Whether unused chunks can be unloaded
GameplayConfig Which gameplay configuration the world uses

The same example includes switches for compass updates, objective markers, and related world behavior. After changing a flag, test that world specifically; changing the default world in the root file does not retroactively apply a world-level rule to every existing world.

Which port does Hytale use, and what do I forward?

Hytale’s default connection uses QUIC over UDP on port 5520. Forward UDP 5520 from the router to the server’s local address and allow the same UDP port through the host firewall. The official manual says TCP forwarding is not required for this setup.

  1. Give the server machine a stable local address so the router rule does not point to a different device later.
  2. Create a router port-forward for UDP 5520 to that local address.
  3. Create or enable a host-firewall rule allowing inbound UDP 5520.
  4. Start the server and confirm the listening port in its startup output.
  5. Have a player outside your home network test the connection; a local client may succeed even when the internet-facing rule is wrong.

If port 5520 is unavailable, change the port with the server’s --bind argument, then update both the router forward and firewall rule to match. Changing the argument on the server alone does not change the router’s destination.

How should I control access to a private server?

Use more than one layer when the server is intended for friends. A password prevents casual joins, while permissions, bans, and the whitelist provide ongoing control.

  • Password: set Password in the root config.json and share it only with the intended group.
  • Whitelist: Hytale’s Update 6 changed whitelist handling so the allow-list uses the hytale.server.join permission. Whitelist commands grant or revoke that permission, and existing whitelist data may be migrated.
  • Bans: use bans.json and the server’s ban controls for players who must not reconnect.
  • Administrative permissions: review permissions.json and give elevated rights only to people who need them.

Whitelist behavior is release-sensitive. Before upgrading, read the official notes for that release and verify that existing entries still map to the expected permission. Keep a copy of the access-control files before migration.

Why did my Hytale server settings get overwritten?

The most common cause is editing while the server is running. Hytale can write configuration during in-game actions, including permission changes, and the setup guidance warns that manual modifications may be replaced. Updates and migrations can also alter access-control data.

Recovery procedure

  1. Stop the server and preserve the current files before making another edit.
  2. Compare the current file with the backup, paying attention to commas, braces, and fields added by a newer version.
  3. Reapply only the intended values to the version currently installed; do not blindly replace a newer file with an old one.
  4. Start the server, inspect logs for parse or migration messages, and test the setting.
  5. Perform one clean restart and verify that the value remains before allowing normal play.

If only whitelist entries changed, check the release’s permission migration notes rather than assuming the entire root configuration was reset.

Should I enable automatic updates?

The update configuration supports update checks, a default 3,600-second check interval, player notifications, backups before applying an update, and three auto-apply modes: Disabled, WhenEmpty, and Scheduled.

Mode Operational behavior Best fit
Disabled Checks can remain under your manual control without automatic application Groups that review release notes and schedule maintenance themselves
WhenEmpty Applies an update when no players are connected A private group that wants unattended maintenance with less disruption
Scheduled Applies according to a planned schedule Groups with a predictable play calendar and a defined restart window

Enable backups before applying updates, notify players when an update is pending, and retain a known-good copy of the universe and configuration. For a friends-only server, WhenEmpty is a reasonable unattended choice; use Disabled when you need to inspect changes before they are applied.

What settings should I change first when performance is poor?

Start with the setting that expands the loaded world, then address concurrency and hardware. Avoid changing several values at once because you will not know which adjustment helped.

  1. Confirm the workload. Reproduce the slowdown with the same number of players, entity density, and exploration pattern.
  2. Lower MaxViewRadius. Return to 12 chunks if you tested 16, or reduce it further for a diagnostic test.
  3. Review MaxPlayers. Set the cap to the number the host can sustain rather than the total number in your community.
  4. Check CPU, RAM, and garbage collection. Determine whether the bottleneck is simulation, memory pressure, or pauses.
  5. Retest after a restart. A clean run distinguishes a persistent capacity problem from a temporary buildup of loaded entities or chunks.

Do not promise a player count based only on the cap or on the 4 GB startup floor. A group that spreads across the map can be substantially harder to host than the same number gathered in one area.

Which configuration profile fits my group?

Use these profiles as decision points, then confirm them with real play. The values are editorial starting points, not guarantees from Hypixel Studios.

Group situation Suggested cap Starting radius Access and operations
Occasional co-op with two to four friends 4 12 chunks Password, manual backups, updates disabled until reviewed
Regular private group of up to eight 8 12 chunks Password plus reviewed whitelist permissions; update when empty if unattended maintenance is useful
Players who routinely split up Actual simultaneous peak 12 chunks, lowered if exploration causes stalls Monitor CPU, RAM, and garbage collection during independent travel
Experienced operator testing higher distance Previously validated cap 16 chunks only after a load test Keep backups and a rollback plan before changing the radius

What is the practical final checklist?

  • Root config.json contains the server name, MOTD, password, player cap, and view-radius limit.
  • World-specific rules are in the matching universe/worlds/<world>/config.json.
  • The host has Java 25 and at least 4 GB of memory available, with additional headroom for the operating system and other services.
  • UDP 5520 is forwarded and allowed through the firewall, unless a different --bind port is configured.
  • Backups include the universe and access-control files, and edits are made only while stopped.
  • Whitelist permissions are checked against the release notes after updates.
  • CPU, RAM, garbage collection, and connection behavior are observed during the group’s normal workload.

The strongest general setup is therefore conservative: 12 chunks, a cap equal to the real simultaneous group, a password, world rules kept in world files, UDP networking configured explicitly, and a backup-and-test cycle around every change.

Frequently Asked Questions

Can I run a Hytale server on a machine that also hosts other services?

Yes, but the 4 GB figure is only the dedicated server’s stated minimum, not free capacity for the whole machine. Leave memory and CPU headroom for the operating system, backups, monitoring, and any other services, then test during simultaneous exploration.

How can I tell whether a connection problem is the router or the server?

Check the server startup output first, then confirm that the configured UDP port is allowed by the host firewall. An external player should test from outside your home network, because a local connection can work even when internet-facing forwarding is incorrect.

Will changing the default world change rules in worlds I already created?

No. The default world and game mode are root-level defaults, while PvP, fall damage, spawning, saving, and related behavior are stored in each world’s configuration. Edit every world that needs the rule.

What should I do before accepting a major Hytale update?

Back up the universe, root configuration, permissions, bans, and whitelist data, then read the release notes for migration changes. After updating, test joining, permissions, and the gameplay rules before inviting the full group.