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 was all measured on 6 September 2026, on a machine rented for the occasion, before the public release.

The method, so you can reject it

The new format has lived on Valheim's public test branch since May 2026 — so it is observable before 9 September. You reach it with the Steam code yesimadebackups, and the lloesche/valheim-server image gets there with PUBLIC_TEST=true.

The reading was taken on a 2 shared-vCPU, 4 GB machine at Hetzner in Falkenstein. A world was generated on the stable branch (0.221.12), shut down cleanly so that it got written, and then the same data directory was restarted on the test branch. That switch is what shows the conversion.

Before: two files

On 0.221.12, 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 on 0.221.13, 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. The files inside 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 on the test branch: 1,761,753,577 bytes, about 1.76 GB. If you're resizing a machine for 1.0, the download is not what moved.

Network version goes from 36 to 37

The server announces Valheim version: l-0.221.13 (network version 37), against network version 36 on 0.221.12. That number is what decides whether a player gets in. Since Steam updates clients on its own, a server that hasn't switched yet becomes, at release, 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.

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.