Hytale Server Config Guide: config.json Settings
Safely edit Hytale server and world config.json files, understand important settings, validate JSON, and avoid overwritten changes.
Last updated: 2026-08-17
Hytale uses a root config.json for server-wide behavior and a separate config.json inside each world directory. Stop the server before editing either file, make a backup, change one group of settings at a time, and validate the JSON before restarting.
Verification status: File locations, world keys, update settings, and write behavior were reviewed against the official Hytale Server Manual on August 17, 2026. Plugins can add their own configuration, so a generated file may contain more fields than the examples below.
Where Hytale configuration lives
| Scope | Typical location | Controls |
|---|---|---|
| Server or universe | Server/config.json | Server-wide systems, including built-in update behavior |
| Individual world | Server/universe/worlds/<world>/config.json | World generation, PvP, saving, ticking, NPCs, time, objectives, and required plugins |
| Permissions | Server/permissions.json | Roles and permission grants |
| Access control | Server/whitelist.json and Server/bans.json | Allowed and blocked players |
| Plugin-specific | Usually under mods/ or a plugin-defined path | Settings owned by an installed plugin |
The exact root depends on how the server was installed. The official bootstrap layout places Assets.zip and the launcher script above the Server/ directory.
Safe editing workflow
- Tell players that the server is stopping.
- Shut it down cleanly with
/stopand confirm the Java process exits. - Copy the file you plan to edit to a dated backup.
- Edit with a plain-text editor that preserves UTF-8.
- Validate the JSON before starting the server.
- Start the server and read the first relevant message in
logs/. - Join and verify the setting in the intended world.
Configuration files are read at startup and can be written by in-game actions. Manual changes made while the server is running may be overwritten.
Understanding world config.json
The official example contains settings like these:
{
"IsTicking": true,
"IsBlockTicking": true,
"IsPvpEnabled": false,
"IsFallDamageEnabled": true,
"IsGameTimePaused": false,
"IsSpawningNPC": true,
"IsSavingPlayers": true,
"IsSavingChunks": true,
"IsUnloadingChunks": true,
"IsObjectiveMarkersEnabled": true,
"GameplayConfig": "Default",
"RequiredPlugins": {}
}
Treat this as a field reference, not a replacement file. Keep the generated Version, UUID, world-generation, storage, and plugin data already present in your world.
| Setting | Practical effect |
|---|---|
IsPvpEnabled | Allows or prevents player-versus-player damage for that world |
IsFallDamageEnabled | Controls fall damage |
IsGameTimePaused | Stops or resumes progression of world time |
IsSpawningNPC | Controls normal NPC spawning |
IsSavingPlayers | Controls persistence of player state |
IsSavingChunks | Controls persistence of changed chunks |
IsUnloadingChunks | Allows unused chunks to leave memory |
RequiredPlugins | Records plugins required by the world |
Do not disable saving on a production world just to improve performance. A world that does not save players or chunks can discard progress.
Configure automatic updates
The built-in updater reads this object from the root config.json:
{
"Update": {
"Enabled": true,
"CheckIntervalSeconds": 3600,
"NotifyPlayersOnAvailable": true,
"Patchline": null,
"RunBackupBeforeUpdate": true,
"BackupConfigBeforeUpdate": true,
"AutoApplyMode": "Disabled",
"AutoApplyDelayMinutes": 30
}
}
Disabled means an administrator must apply a staged update manually. WhenEmpty waits until no players are connected. Scheduled applies after the configured delay and can interrupt active players, so use it only with clear warnings and tested backups.
See the automatic-update guide before enabling unattended changes.
Avoid common JSON mistakes
- Use double quotes around keys and text values.
- Do not leave a comma after the final item in an object or array.
- Keep
true,false, numbers, andnullunquoted. - Do not paste comments into standard JSON.
- Preserve braces, brackets, generated identifiers, and plugin-owned sections.
- Restore the last known-good copy if the server reports a parsing error.
Which config file should I edit?
If a setting affects only one playable world, begin with that world's file under universe/worlds/. If it affects updates or the whole server process, begin with the root file. When a plugin is involved, use that plugin's documentation rather than guessing where it stores settings.
After changing a setting
Check that the server reaches a stable running state, the correct world loads, players retain their data, and a fresh backup completes. If the file immediately changes back, confirm that the server was stopped during the edit and that you edited the active installation rather than an old copy.