How to Auto-Update a Hytale Server Safely
Configure Hytale server update checks, staging, automatic application, backups, wrapper scripts, patchlines, and rollback.
Last updated: 2026-08-17
Hytale's built-in updater can check, download, stage, and apply server updates. A safe setup uses the official folder layout and wrapper script, creates backups before replacement, keeps release and pre-release installations separate, and verifies mods before reopening the server.
Verification status: Commands, folder layout, configuration keys, automatic-apply modes, exit behavior, and rollback locations were reviewed against the official Hytale Server Manual on August 17, 2026.
Required folder layout
The updater expects this structure:
game/
├── Assets.zip
├── start.sh or start.bat
├── jvm.options (optional)
└── Server/
├── HytaleServer.jar
├── HytaleServer.aot
├── config.json
└── ...
Start the server from Server/, with assets and the launcher one directory above it. Bootstrap installation and the Hytale Downloader CLI create the supported layout automatically.
If you manually copied the files, run /update setup to write the wrapper scripts. /update download --force can download a fresh staged copy of the current version, including assets and wrappers.
Update commands
| Command | Action |
|---|---|
/update check | Check for a newer build |
/update download | Download an available update into staging |
/update download --force | Download even when already current |
/update status | Show the installed version and staging state |
/update apply --confirm | Back up applicable files, then apply the staged update |
/update cancel | Delete the staged update |
/update patchline [name] | View or select the update patchline |
/update setup | Generate the official wrapper scripts |
Recommended conservative configuration
Add or review the Update object in the root config.json:
{
"Update": {
"Enabled": true,
"CheckIntervalSeconds": 3600,
"NotifyPlayersOnAvailable": true,
"Patchline": null,
"RunBackupBeforeUpdate": true,
"BackupConfigBeforeUpdate": true,
"AutoApplyMode": "Disabled",
"AutoApplyDelayMinutes": 30
}
}
This checks hourly but leaves application under administrator control. It is a good starting point for modded or important worlds because you can inspect patch notes, verify backups, and check plugin compatibility before applying.
Automatic apply modes
| Mode | Behavior | Best use |
|---|---|---|
Disabled | Requires /update apply --confirm | Modded and production servers |
WhenEmpty | Applies after all players leave | Small servers with tested backups |
Scheduled | Applies after the configured delay and warns players | Managed maintenance windows |
Automatic does not mean unattended forever. Monitor backup completion, available disk space, restart success, protocol compatibility, and plugin errors.
What happens during application
Updates download to updater/staging/. When application begins, the server exits with code 8. The official wrapper detects that code, replaces staged server binaries and assets while preserving configuration, saves, and mods, then starts the server again.
Running the JAR directly can download an update but cannot complete the wrapper-controlled restart correctly. Use start.sh or start.bat for the built-in update workflow.
Before applying an update
- Read the official patch notes for server, permission, protocol, mod, and world changes.
- Run
/update statusand record the installed version and patchline. - Confirm a recent full backup exists outside the live world directory.
- Back up
universe/,config.json,permissions.json,whitelist.json,bans.json, and compatible mods. - Check every required plugin against the target version.
- Schedule downtime and notify players.
- Apply the staged update and watch the first restart.
Client and server protocol versions must currently match. Delaying a release update can prevent updated clients from connecting, but immediately auto-applying can break an unverified mod stack. Use a short, controlled maintenance process rather than either extreme.
Release and pre-release separation
Keep release and pre-release installations in separate directories with separate worlds, mods, logs, configuration, and backups. A world opened by a pre-release build may not be safe to roll back merely because an older server still starts.
Roll back a failed update
The wrapper stores previous files under updater/backup/. If the server crashes shortly after an update, the official script reports that location and provides rollback guidance.
Before restoring:
- Stop the server and preserve the failed installation for diagnosis.
- Copy the current world and logs to a separate location.
- Restore the backed-up server files and
Assets.zipas directed by the wrapper. - Restore configuration or world data only when the failed build changed them.
- Start privately and verify the world, players, permissions, and mods.
Never overwrite the only backup while attempting recovery.