Valheim 1.0: what actually changes on disk, measured

Valheim 1.0 changes how the game writes worlds. Iron Gate says so in two sentences in its patch notes; we wanted to see the files. This page is the raw reading, with the method to redo it.

Nothing here is lifted from a press release: it all comes from Valheim 1.0 servers we run (l-1.0.7), plus one old world we watched convert.

The method, so you can reject it

Two readings, two sources. The shape of the files is read from the archives of our own 1.0 servers: open a world's archive, list what's in it, look at the bytes of the small files — no interpretation. The conversion of an old world was watched separately, on a machine rented for the occasion (2 shared vCPUs, 4 GB of RAM, Hetzner in Falkenstein): a world generated in the old format, shut down cleanly so that it got written, then the same data directory restarted with the new save system. That switch is what shows the conversion, and it is where the bytes in the table below come from.

Before: two files

In the old format, a saved world is a flat pair:

worlds_local/
  tickserv.db                              322,596 B
  tickserv.fwl                                  49 B
  tickserv.fwl.old                              49 B
  tickserv_backup_auto-20260906114306.fwl       49 B

Two things we didn't expect, and they matter if you move a world by hand. The .fwl is 49 bytes and exists from the moment the world is created: the .db only appears at the first save. So a folder holding just a .fwl isn't an empty world, it's a world that was never saved. And the game files its own copies next to the world, prefixed _backup_auto- — they are inside the folder you copy, with nothing to tell you.

After: a folder, and pieces

Restarted with the new save system, the same world becomes this:

worlds_local/
  tickserv/
    _main.1.fwl2                     49 B
    _main.1.db2                 133,435 B
    _main.1.chunks                   32 B
    _main.1.ok                        4 B
    00_00__0_1.chunk              1,464 B
    00_01__0_1.chunk                  6 B
  tickserv_backup_20260906-115918.db   322,596 B
  tickserv_backup_20260906-115918.fwl       49 B

The thing to take away: the extension changes. It is no longer .fwl but .fwl2, and the .db becomes .db2 alongside .chunk files. A tool looking for *.db and *.fwl — a backup script, a host's importer — will find nothing on a 1.0 world. And it's silent: no error, just a missing world.

The world's name lives in the folder name — and also, as we'll see below, inside the .fwl2. The files are generic, and their number goes up with each save (_main.1.* then _main.2.*).

The conversion keeps a full copy, and costs 42%

The server log says Moved old World save into backup!. The original pair is kept as-is, renamed <world>_backup_<timestamp>. Measured result:

That's +42%, not the doubling one might fear: the converted world (133 KB) is much smaller than the copy of the old one (322 KB) sitting next to it. That copy is also your only way out if the conversion goes wrong — the game cannot roll a world back on its own.

What doesn't change: the download

The dedicated server weighs the same as before. Read from SteamCMD's output: 1,761,753,577 bytes, about 1.76 GB — the same order as the 1.75 GB we read before 1.0. If you're resizing a machine for 1.0, the download is not what moved.

Network version: 39 in 1.0

The server announces Valheim version: l-1.0.7 (network version 39), where it used to say network version 36 before 1.0. That number is what decides whether a player gets in. Since Steam updates clients on its own, a server that hasn't switched yet is a server nobody can enter — until it updates.

The game's backups don't switch off with the image's

A hosting trap, this one. The lloesche image has a BACKUPS setting for its own hourly archives. It has no effect on the backups the game takes itself, and the server says so in its log:

Considering autobackup for World. […] short time: 7200, long time: 43200, backup count: 4

Those are the three defaults Iron Gate documents (-backups 4, -backupshort 7200, -backuplong 43200): up to four copies, one at two hours then three at twelve-hour intervals. They live in worlds_local, so inside any archive you make of that folder. On a server that only runs for a few hours at a time, the three "long" ones never fire — so -backups 1 loses almost nothing.

Renaming a world works, in both formats

Useful if you're moving house: Valheim loads a renamed world, it doesn't build a new one. Verified in both formats, and the judge is a log line — Done generating locations appears only for a new world.

In both cases the world's bytes were intact after renaming.

The world's name is written INSIDE the file — but the folder is what decides

The _main.<n>.fwl2 is not 49 bytes like the old .fwl: 179 to 232 bytes across our servers, because it carries the world's name, its seed, and the list of known players (id, nickname, token). Its first eight bytes are two 32-bit integers — the length of everything that follows, then the save system's format number (41, the same one in _main.<n>.ok and at the head of .chunks). Then comes the name, length-prefixed, then the seed:

e4 00 00 00   29 00 00 00   08 't','i','c','k','s','e','r','v'   0a 'R','b','j',…
 └ 228 = the    └ 41 = the     └ 8 + the name                      └ 10 + the seed
   rest of        save
   the file       format

And yet the FOLDER is what decides what loads. A world whose .fwl2 says MyRun, placed in a folder called tickserv/, is loaded without complaint by a server started with -world tickserv — which is exactly the case of a world brought in by a player and filed under the name the server opens. The server says so itself, naming both:

ZNet.LoadWorld: MyRun (tickserv), save number 8
ZoneSystem.Load => Loaded 12,327 locations

That's the line to look for when you want to know whether a server loaded YOUR world or built another one: the first name is your world's, the second the one the server asked for. The save number counter goes up with every save — handy to check a world is still alive.

What we did not measure

The RAM and CPU of a 1.0 server with players on it: that needs real players, and we didn't want to publish an estimate dressed up as a measurement. Since the Deep North only appears on unexplored ground, the question won't really bite until a few exploration sessions in.

The conversion's behaviour with mods wasn't tested either — Iron Gate explicitly writes that the new save system hasn't been.

These readings come from running Valheim servers ourselves. If you'd rather not deal with any of it: see Valheim.