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

CommandAction
/update checkCheck for a newer build
/update downloadDownload an available update into staging
/update download --forceDownload even when already current
/update statusShow the installed version and staging state
/update apply --confirmBack up applicable files, then apply the staged update
/update cancelDelete the staged update
/update patchline [name]View or select the update patchline
/update setupGenerate the official wrapper scripts

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

ModeBehaviorBest use
DisabledRequires /update apply --confirmModded and production servers
WhenEmptyApplies after all players leaveSmall servers with tested backups
ScheduledApplies after the configured delay and warns playersManaged 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

  1. Read the official patch notes for server, permission, protocol, mod, and world changes.
  2. Run /update status and record the installed version and patchline.
  3. Confirm a recent full backup exists outside the live world directory.
  4. Back up universe/, config.json, permissions.json, whitelist.json, bans.json, and compatible mods.
  5. Check every required plugin against the target version.
  6. Schedule downtime and notify players.
  7. 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:

  1. Stop the server and preserve the failed installation for diagnosis.
  2. Copy the current world and logs to a separate location.
  3. Restore the backed-up server files and Assets.zip as directed by the wrapper.
  4. Restore configuration or world data only when the failed build changed them.
  5. Start privately and verify the world, players, permissions, and mods.

Never overwrite the only backup while attempting recovery.

Official references

Related pages