Serveur Valheim dédié : ce que change un monde persistant sur l'expérience de jeu

A persistent Valheim server behaves nothing like the session you spin up on your own PC for a weekend raid. When the Viking world stays online around the clock, world save continuity, zone loading, tick rate and the latency felt by distant players all shift in ways that reshape exploration, building and combat for the whole crew.

How an Always-On Valheim Server Changes World Persistence

When you host Valheim from your own machine, the world only exists while your game is open. Close it, and every boss timer, raid event, and growing crop freezes until the next session. An always-on setup removes that pause button entirely. Trees keep growing, Greydwarves keep spawning near outposts, and the Eikthyr or Moder events you triggered before logging off can still resolve while you're away, because the simulation never stops running.

This matters for a few concrete reasons:

• Bases left unguarded continue to face troll raids and skeleton waves on schedule, not just when someone is watching.
• Portals and workbenches stay active for teammates logging in at different hours, without anyone needing to "open the world" first.
• World events (eclipse-like weather shifts, boss summons triggered by sacrifice) progress on real time rather than on whoever happens to be hosting that night.

If you want this kind of continuous Viking world without babysitting a machine yourself, dedicated resources built for this exact workload are covered under Valheim server hosting, where the instance keeps running independently of whether your own computer is on.

Player-Hosted Session vs Always-On World

Behavior	Player-hosted session	Always-on world
World state when host logs off	Frozen	Keeps simulating
Zone loading for offline players' bases	Unloaded, no updates	Still subject to raids and decay timers
Save file writes	Tied to host's session	Scheduled, consistent intervals
Availability for other players	Only when host is online	Reachable anytime

World Save Continuity and Zone Loading

Valheim stores its world in two files per world: a .db file holding terrain, structures and objects, and a .fwl file with metadata like the seed and world key. A persistent server writes these at regular intervals controlled by the -saveinterval launch parameter, which matters a lot more once the world is expected to run for weeks without a manual save.

Zone loading works on a radius around active players. Areas without anyone nearby get unloaded from active simulation to save CPU cycles, but on a continuously running instance, zones get loaded and unloaded far more often across a day than during a short solo session, simply because players connect from different time zones. This puts more sustained load on CPU and memory over time than a casual player-hosted game ever experiences.

Recommended Save Settings

-saveinterval 1800
-backups 4
-backupshort 7200
-backuplong 43200

These values save the world every 30 minutes, keep four short-term backups taken every two hours, and a long-term backup every twelve hours. On Fly-Serv, automatic backups through the panel add a second safety net on top of these in-game settings, which is useful if a mod update corrupts the world file or a plugin conflict forces a rollback.

Tick Rate, Latency and Distant Players

Tick rate determines how often the simulation updates positions, combat hits and physics. Valheim isn't as tick-demanding as something like Rust or ARK, but a persistent instance running 24/7 accumulates far more simulated ticks over its lifetime, and any CPU bottleneck shows up as stutter during combat or delayed structure placement, especially once several bases and tamed creatures are active simultaneously.

Latency is a separate issue from tick stability. Players connecting from far outside the region where the machine is physically located will always see higher ping than someone nearby, regardless of how well the world runs. A few practical points:

• Pick a server location geographically centered on where most of your crew actually plays.
• High base clock CPUs (Ryzen-class processors handle this well) keep tick processing consistent even as the world grows with more structures and tamed animals.
• NVMe storage reduces the time spent writing those periodic save files, which avoids a brief freeze during autosave on busy worlds.
• Anti-DDoS protection at the infrastructure level matters more for a persistent world than a short session, since it's reachable and exposed around the clock, which is why it's included by default rather than optional.

Why Combat Feels Different Online vs Solo

In solo or LAN play, you never notice network sync because there's no round trip to a remote machine. On a persistent server, every hit registration, stagger and dodge roll travels over the network first. That round trip is what players mean when they describe combat as feeling "floaty" on a distant server compared to a nearby one, and it's purely a function of distance and connection quality, not world configuration.

Configuring a Persistent Valheim Instance

The core configuration lives in the server start command and a handful of text files. A typical Linux start script looks like this:

#!/bin/bash
export templdpath=$LD_LIBRARY_PATH
export LD_LIBRARY_PATH=./linux64:$LD_LIBRARY_PATH
export SteamAppId=892970

./valheim_server.x86_64 \
  -name "Midgard Outpost" \
  -port 2456 \
  -world "Midgard" \
  -password "ChangeThisPassword" \
  -public 1 \
  -crossplay \
  -saveinterval 1800 \
  -backups 4 \
  -backupshort 7200 \
  -backuplong 43200

export LD_LIBRARY_PATH=$templdpath

Access control runs through three plain text files placed in the save directory:

# adminlist.txt
76561198000000001
76561198000000002

# bannedlist.txt
76561198099999999

# permittedlist.txt
76561198000000001
76561198000000002
76561198000000003

If you're running this from your own machine or a self-managed VPS rather than a managed instance, the firewall needs the right UDP ports opened before anyone can connect:

ufw allow 2456:2457/udp
ufw status

Through a panel like Pterodactyl, most of this is handled without touching the command line directly: you edit the start parameters in a form, drop adminlist.txt straight into the file manager, trigger a restart from the console, and schedule backups without writing a cron job by hand. That's the main practical difference between configuring a persistent world manually versus through a managed game server panel.

Mods on a Persistent World

BepInEx-based mods (build expansion packs, quality-of-life inventory tweaks, boss difficulty adjustments) work the same way on an always-on instance as locally, but updates need more care: a mod that breaks on load can stall the save cycle for everyone currently connected, not just you. Testing mod updates on a separate world copy before pushing them to the main persistent world avoids this entirely.

For admins who prefer full control over the operating system layer rather than a managed panel, a Linux instance or a Pterodactyl-ready instance gives you SSH access to manage the Valheim process, mod files and firewall rules directly, which some communities running heavily modded worlds prefer over a fully managed setup.

Official documentation on launch parameters and save behavior is available on the Valheim Wiki, which is worth checking whenever a game update changes default flags or adds new ones.

Keeping the World Stable Long Term

A world running for months accumulates more structures, more tamed creatures and larger save files than any short session ever will. Watch save file size growth, keep backup rotation enabled, and restart the process on a schedule (weekly is common) to clear memory rather than letting it run indefinitely without a refresh. Admin lists should be reviewed periodically too, especially for open communities where player turnover is frequent.

None of this replaces good habits: a strong server password, a maintained admin list, and backups you've actually tested by restoring them at least once. Persistence rewards a world that's been configured carefully far more than one left on default settings and forgotten.

For broader comparisons across other survival and sandbox titles running on similar always-on logic, the Fly-Serv blog covers configuration notes for several other games sharing this same persistence model.

A persistent Valheim world rewards the setup work: save continuity, sane backup intervals and a stable connection matter more than they ever do in a short solo session. Get the configuration right once, and the Viking world keeps evolving whether or not anyone is actively watching it.

FAQ

How often should a persistent Valheim world be restarted?

A weekly restart is a common practice to clear accumulated memory, even if the world itself runs continuously. Pair it with a backup right before restarting so you can roll back instantly if anything looks off after the restart.

Why do some players see worse latency than others on the same world?

Latency depends on the physical distance between each player and the machine's network location, not on world configuration. Choosing a location central to your group's geography reduces the gap, but some variance between players will always remain.

Will installing BepInEx mods affect world save stability?

It can, if a mod update conflicts with the current save format. Test mod changes on a duplicate world file first, keep backups enabled with short intervals, and only push updates to the main world once you've confirmed they load cleanly.