Hytale Server Files Explained: Where Your World Actually Lives

I got this wrong once, in public. A backup guide I wrote for a Hytale community forum I run told people to back up /opt/hytale/server/world. There is no world folder. Anyone who copied that line got a cron job that tarred up nothing, every night, without an error. A backup that silently backs up nothing is worse than no backup, because you think you're covered.

So I sat down with a real server directory, a dev server I use for plugin work, and went through what's actually there. This is the map I wish I'd had.

TL;DR: The world lives in universe/: universe/worlds/<name>/ holds the terrain, universe/players/ holds per-player data. Next to it sit config.json, permissions.json, whitelist.json, bans.json and mods/. Back up universe/ plus those four JSON files plus mods/. Skip the server jar, Assets.zip, logs and telemetry; they're replaceable or useless in a restore.

The backup line, first

Because that's why most people end up here:

sudo systemctl stop hytale
tar czf /backups/hytale-$(date +%F).tar.gz -C /opt/hytale/Server \
  universe config.json permissions.json whitelist.json bans.json mods
sudo systemctl start hytale

Adjust /opt/hytale/Server to wherever your HytaleServer.jar lives. Then check that the archive actually contains a world:

tar tzf /backups/hytale-$(date +%F).tar.gz | grep -m5 'universe/worlds/'

If that prints nothing, your path is wrong, and you just found out today instead of on the day the disk dies.

The top level

This is the server directory of my dev server, top level only:

Server/
├── auth.enc
├── bans.json
├── config.json
├── logs/
├── mods/
├── permissions.json
├── telemetry/
├── universe/
└── whitelist.json

Plus HytaleServer.jar and Assets.zip wherever your start script expects them; on my dev box they sit elsewhere. What each one is:

• config.json: the server config. Server name, MOTD, password, max players, the view radius limit, the default world and game mode, which mods are enabled, log levels. This is the file you edit most.
• permissions.json: who can do what, i.e. operator rights and permissions.
• whitelist.json: who may join, if you run a whitelist.
• bans.json: who may not.
• mods/: your mods and plugins, as jar files and folders.
• universe/: the world data. The one thing you can't redownload. More below.
• logs/: server logs, one file per start. Useful for debugging, worthless in a restore.
• telemetry/: compressed telemetry files the server writes. Not needed for anything you'd restore.
• auth.enc: the server's encrypted credential store, referenced in config.json under AuthCredentialStore. This is where the server keeps its login after you authenticate it.

Inside universe/

universe/
├── players/
│   ├── <player-uuid>.json
│   └── ...
├── worlds/
│   ├── default/
│   │   ├── chunks/          # *.region.bin, the terrain
│   │   ├── config.json      # per-world: seed, world gen, PvP, ticking ...
│   │   └── resources/       # per-world state: time, markers, events ...
│   └── <other worlds>/
└── memories.json            # or resources/Memories.json, see below

• worlds/: one folder per world. If you've ever created a second world, a build world, or a mod made one for you, it shows up here as its own folder. On my dev server there are several, from a spawn world to mod-specific ones.
• worlds/<name>/chunks/: the terrain itself, stored as region.bin files named by region coordinates. This is the bulk of the size.
• worlds/<name>/config.json: per-world settings. The seed lives here, along with world generation, PvP and ticking flags. Losing this file means losing the seed, which is annoying if you ever want to regenerate terrain.
• worlds/<name>/resources/: world-level state as JSON files: time of day, map markers, block counters, instance data and similar.
• players/: one JSON file per player, named by UUID. That's the per-player state the server keeps between sessions. Lose it and your players start over in a world they built.
• The memories file: global progress data. On an older snapshot of my dev server it sat directly in universe/ as memories.json; on a newer one I find universe/resources/Memories.json instead, next to GameFlags.json and Hardcore.json. Don't hardcode either path; back up the whole universe/ and you never have to care.

Two more things I found in there:

• Mods write into universe/ too. On my dev server an economy plugin had created its own folder and a warps plugin its own warps.json directly in universe/. That's one more reason to back up the directory as a whole instead of cherry-picking worlds/ and players/. My mods and plugins guide has more on mod data outliving the mod.
• Almost every JSON has a .bak sibling. config.json.bak, Time.json.bak, the player files, and so on. It looks like the server keeps the previous version next to the current one. Handy if a single file gets mangled, but it's on the same disk, so it's not a backup.

Gotcha: the world is not in world/

My own guide said world/. On the server I checked, it's universe/, and the worlds are one level down in universe/worlds/. Minecraft habits die hard.

If you inherited a backup script, check it:

grep -rn 'world' /etc/cron.d/ /etc/systemd/system/*.service /usr/local/bin/*backup* 2>/dev/null

Anything pointing at a bare world directory next to the jar is backing up air. My systemd backup and auto-restart post has the full timer setup; just make sure the paths in it match what you see on your own disk with ls.

What belongs in the backup

Why mods/ matters: a world saved with mod X version 1.2 and restored with version 1.4 may or may not load cleanly. Backing up the exact jars keeps the restore boring.

About auth.enc: I leave it out and simply authenticate the server again after a restore. If you do include it, your backup archive now contains a credential, and it should be treated like one: encrypted, not lying around on a public share.

Gotcha: copying a live world

Tarring universe/ while the server is writing chunks can give you a half-saved archive that looks fine until you try to restore it. Either stop the server for the few seconds the copy takes (the command at the top does that), or back up in a quiet window and accept the risk. For a small server, a few seconds of downtime at 4am is invisible.

Size-wise it's worth knowing what you're dealing with. On my dev server, universe/ is about 2.8 GB, mods/ about 75 MB, logs about 6 MB. The world dominates everything, so that's where compression and off-box storage matter.

du -sh /opt/hytale/Server/{universe,mods,logs}

Test the restore once

A backup you've never restored is a guess. Pull one into a scratch directory and look:

mkdir -p /tmp/restore-test
tar xzf /backups/hytale-2026-07-29.tar.gz -C /tmp/restore-test
ls /tmp/restore-test/universe/worlds    # your worlds in there? good.
ls /tmp/restore-test/universe/players | head

Then get the archives off the box. A backup on the same disk as the server dies with the server. I use encrypted restic backups to S3-compatible storage for that; plain rsync to another machine works too.

FAQ

Can I copy just one world to another server? Copy universe/worlds/<name>/ across, and if you want players to keep their stuff, universe/players/ as well. Make sure the target runs the same mods.

Where do I change view distance and max players? In the top-level config.json. Restart the server afterwards. If you're sizing RAM around view distance, see how much RAM a Hytale server needs.

Do I need the .bak files in the backup? They come along when you tar universe/, and they're small. Not worth filtering out.

Is this layout guaranteed to stay like this? No. Hytale is in active development, and the memories file already moved between builds on my own server. Check your own directory after updates. The rule that survives any layout change: back up all of universe/ plus the configs and mods.

Related posts

• How Much RAM Does a Hytale Server Need? The Formula I Actually Use
• How to Install Mods on a Hytale Server (Full Guide)
• How to Set Up a Hytale Dedicated Server (2026 Guide)