Hytale downloader: how server files are actually fetched
If you are trying to script your Hytale dedicated server updates, the short answer is that you cannot fully automate them today, and it is worth understanding exactly why before you build something that will break.
Hytale server files are not on a public mirror and there is no anonymous download. They are fetched by an interactive downloader that authenticates against a Hytale account which owns Early Access. That single design decision is what rules out an unattended cron job.
What the downloader actually is
It is a single self-contained binary, distributed per platform, for example hytale-downloader-linux-amd64. It is not a verb-driven command line tool: there are no get server, get assets or check-update subcommands to call from a script. You run the binary and it walks you through a session.
What it does internally, in order:
- Authenticates over OAuth. It talks to Hytale's account and OAuth hosts and, on first run, needs a real browser sign-in. If a saved session exists it will try to reuse it, and reports an error if that session can no longer be loaded.
- Reads a version manifest. The manifest describes each build as a version, a download URL and a
sha256, so the tool knows what the current build is and can verify what it pulled. - Requests a signed, time-limited URL for the actual game assets, rather than exposing a permanent link.
- Downloads and writes the archive to disk, reporting progress as it goes.
The important consequence is in step 1 and step 3. The asset URLs are signed and short-lived, so you cannot bookmark one and wget it on a schedule, and the session behind them is tied to an account login rather than an API key you can put in a script.
Two different things get confused here: fetching files, and running the server
Almost every argument about "automating Hytale" mixes up two separate problems. They have different answers.
Fetching the build cannot be scripted
Downloading the server archive goes through the interactive downloader above. There is no anonymous mirror, the asset URLs are signed and short-lived, and the first run needs a real browser sign-in. The tool also has explicit handling for a saved session it can no longer load, so a pipeline built on a cached session will fail at exactly the moment a patch lands and you most want it to work. If the account holding Early Access has two-factor, every re-authentication needs a code no cron job can supply.
So the realistic pattern is a person running the downloader when a build ships, then moving the files onto the server. The hytale-cli check-update --json style workflow you may have seen does not exist.
Running the server CAN be authenticated headlessly
This part is genuinely automatable, and it is the piece most guides miss. A Hytale server authenticates using the OAuth 2.0 device authorization flow against oauth.accounts.hytale.com, with a public client id of hytale-server. The sequence is:
- The server requests a device code and gets back a short user code and a verification URL.
- You open that URL once, on any device, and approve it against your Hytale account.
- The server polls until approval completes, then receives an access token and a refresh token.
- The refresh token is what makes this durable. The access token is refreshed on a timer, so the server keeps its session alive without anyone signing in again.
- Session and identity tokens are then passed to the server process at launch.
That is a one-time human approval, not a permanent manual chore. It is the same device-code pattern a smart TV uses. The practical failure mode is not expiry but loss: if the stored refresh token is deleted, or the account's sessions are revoked, the server needs the device approval again.
A workable self-hosted routine
You can still make this fast and safe, you just cannot make it hands-off:
- Run the downloader on a workstation, not on the game server itself. The server does not need to hold the account you download with.
- Keep every downloaded build. Name archives by version and keep the previous one. A rollback is only possible if you kept the file, because you cannot re-request an old build on demand.
- Verify before you deploy. The manifest ships a
sha256for a reason. An interrupted download that half-writes an archive is the usual cause of a server that will not start after an update. - Stop the server, swap the files, start it. Do not unpack over a running server.
- Back up your world before every update, not after. This is the step people skip and the only one that is unrecoverable.
On the runtime side, Hytale servers need Java 25. Running an older JDK is a common cause of a server that will not boot after an update.
If an update leaves you with a broken archive rather than a broken world, the Assets.zip corruption fix covers the repair. If the downloader itself will not sign in, see authentication failed.
If you would rather not do the file side at all
Everything above is the work of keeping a self-hosted server current: watching for a build, running the downloader, verifying it, swapping the files, backing up first.
On a hosted server that part is already done for you when a build ships. Signing in to your own Hytale account stays yours either way, because it has to: it is your account, and it is one device-code approval rather than an ongoing chore.
Supercraft Hytale servers handle that side of it. If you would rather run your own, how to make a Hytale server covers the full setup.
A note on what you will read elsewhere
There are guides circulating that show a hytale-cli binary with auth login, get server, get assets and check-update --json subcommands, wired into a cron script. Those commands do not exist. Neither does the download host they usually cite. If you have been trying to make that workflow run and it has been failing, nothing is wrong with your setup.
Related
- Hytale Early Access 2026, what shipped and what a server needs.
- Automated server management, the parts of running a Hytale server you genuinely can script.
- Authentication failed, when the sign-in itself is the problem.