A scheduled restart on a Valheim server is worth having, and it is safe as long as one rule holds: the server must be stopped with an interrupt signal, never killed, because the clean stop is what writes the world to disk. Once a day for a busy or modded server, a few times a week for a small vanilla group, at an hour nobody plays. Vanilla Valheim cannot warn players from the server side, so the warning goes out through Discord or a mod, or you only restart when the server is empty. Updates can ride along with the restart, but only on a vanilla server - a modded one should never update itself.
The rest of this guide is how to build that on your own Linux machine with cron and systemd, inside Docker, and on a panel, plus the mistakes that turn a harmless restart into a lost evening of building.
Why restart a Valheim server at all#
A Valheim server that runs for weeks keeps working, but it drifts. The reasons a scheduled restart helps are specific:
- Memory creeps. The server holds every loaded zone and every object instance in memory. As players explore and build, the working set grows, and it does not always shrink back when they leave an area. A restart brings it back to the cost of the world as saved.
- Mods leak. BepInEx plugins are written by volunteers against a game that changes under them. A mod that holds on to references or grows a cache is common, and a daily restart hides a slow leak that would otherwise end in an out-of-memory stop at the worst moment.
- Updates need one. A Valheim patch is applied by stopping the server, running SteamCMD and starting it again. If the restart is already scheduled, the update can happen inside it.
- A clean slate for stuck state. Rubber-banding ships, a raid that never ends, objects that refuse to sync - most of these clear on a restart because zone ownership is handed out fresh to whoever arrives first.
What a restart does not fix is just as important. It does not make a world with a giant terraformed base cheaper to run, it does not cure one player's bad connection, and it will not stop a crash that happens on load. If the server is slow straight after a restart, the problem is the world or the plan, and Valheim server performance and lag is the place to look.
One side effect catches crossplay groups: the six-digit join code changes every time the server starts. A daily restart means a daily new code, so if console players join that way, the restart routine should post the new code somewhere they will see it. More on that below.
How often, and at what time#
There is no magic interval. Pick it from how the server is used:
| Server | Interval | Why |
|---|---|---|
| 2-5 friends, vanilla | Weekly, or twice a week | Little growth, few objects, no mods to leak |
| 6-10 players, vanilla, mature world | Daily | Large builds and many tames add up |
| Any modded server | Daily | Plugins are the usual source of creeping memory |
| Public community server | Daily, plus before events | More players means more zones loaded at once |
Run it when the server is usually empty. Check when your group really plays rather than guessing - the log records every connection, and a week of it tells you the quiet hour. For a European group that is often between 04:00 and 07:00. If the group spans time zones there may be no empty hour, which is the case for a warning, covered next.
Two timing details matter more than the hour itself. First, know which time zone the scheduler uses. Cron uses the machine's zone, many containers default to UTC, and a panel schedule follows whatever the panel is set to. Write the restart down in UTC in your notes and you will not be surprised by daylight saving. Second, do not stack jobs on the same minute. A backup that starts while the server is shutting down copies a world that is half-way through being written. Leave a gap of a few minutes between restart, backup and anything else. Cron expressions explained covers the five-field syntax if it is unfamiliar.
The one rule: stop cleanly so the world saves#
Valheim keeps the world in memory and writes it out every -saveinterval seconds, 1800 by default. It also saves when it is asked to stop politely. On Linux that means SIGINT, the same signal as pressing Ctrl+C in a terminal. The server catches it, writes World saved to the log, and exits. SIGKILL cannot be caught: the process vanishes and everything since the last save goes with it.
Every restart method below comes down to sending the right signal and then waiting long enough. A large, old world can take tens of seconds to write, and a slow disk makes it longer. If your tool gives up after ten seconds and escalates to a kill, you lose data on exactly the worlds that matter most.
The relevant part of a systemd unit looks like this:
[Service]User=valheimWorkingDirectory=/home/valheim/serverExecStart=/home/valheim/server/start_server.shKillSignal=SIGINTTimeoutStopSec=120Restart=on-failureRestartSec=10Test it once by hand before you trust it: sudo systemctl restart valheim, then journalctl -u valheim -n 50 and look for the save line before the start-up lines. If the save is missing, the signal is not reaching the server process - usually because the start script launches it in the background or does not exec it. The full unit, including logs and restart policy, is in running Valheim as a systemd service.
Restarting with cron or a systemd timer#
On a machine you control, the simplest scheduled restart is one line in root's cron, using the unit above to do the stopping and starting:
# Every day at 05:00 machine time0 5 * * * root /usr/bin/systemctl restart valheimFiles in /etc/cron.d take a user field (root here), unlike a personal crontab. If you would rather keep it inside systemd, a timer does the same job and logs to the journal:
[Unit]Description=Daily Valheim restart[Timer]OnCalendar=*-*-* 05:00:00Persistent=false[Install]WantedBy=timers.target[Unit]Description=Restart the Valheim server[Service]Type=oneshotExecStart=/usr/bin/systemctl restart valheim.serviceEnable it with sudo systemctl enable --now valheim-restart.timer and check the next run with systemctl list-timers. Persistent=false matters: with it set to true, a machine that was off at 05:00 would run the missed restart as soon as it boots, which is pointless for a restart.
LinuxGSM
If the server was installed with LinuxGSM, it brings its own commands: ./vhserver restart, ./vhserver update (stops, updates and starts only when a new build exists) and ./vhserver monitor (starts the server again if it has died). These go into the vhserver user's crontab. LinuxGSM vhserver covers the setup and its trade-offs against a plain script.
Warning players before the restart#
Vanilla Valheim has no server console input and no broadcast command. You cannot type "restart in five minutes" into the server and have it appear on screen. That leaves three honest options.
- Restart only when nobody is on. For a small group this is the best answer. A restart at an empty hour needs no warning at all.
- Warn through Discord. Most groups already have a channel. A script posts to a Discord webhook, waits, then restarts.
- Use a mod. Server Devcommands adds a
broadcastcommand, but it is typed by a connected admin, not run by cron. Server-side announcer mods exist; check that any you pick is maintained for the current game version.
The Discord route is a dozen lines of shell:
#!/usr/bin/env bashset -euo pipefailWEBHOOK="https://discord.com/api/webhooks/REPLACE/ME"say() { curl -fsS -H "Content-Type: application/json" \ -d "{\"content\":\"$1\"}" "$WEBHOOK" >/dev/null || true}say "Valheim restarts in 10 minutes. Find a safe spot."sleep 540say "Valheim restarts in 1 minute."sleep 60systemctl restart valheimsay "Valheim is restarting. Back in about two minutes."Point the cron line at the script instead of systemctl. The || true keeps a Discord outage from cancelling the restart. Treat the webhook URL as a password: anyone who has it can post to the channel. Discord webhooks for server status goes through creating one and formatting messages.
Skipping the restart when people are playing
You can also check whether anyone is online and skip the restart if so. The server answers Steam queries on the game port plus one (2457 by default), and the python-a2s library reads the player count:
$ pip install python-a2s$ python3 -c 'import a2s,sys; sys.exit(1 if a2s.info(("127.0.0.1",2457)).player_count else 0)' \ && systemctl restart valheimThe command exits non-zero when players are connected, so the restart only runs on an empty server. Test the query on your own server first - if it times out, the restart will never happen, which fails safe but silently. Valheim server monitoring and player counts covers the query in detail, including when it does not answer.
Updating on restart, and when not to#
A restart is the natural moment to update. On a systemd install, add the SteamCMD update as a pre-start step so every start runs it:
[Service]ExecStartPre=/usr/games/steamcmd +force_install_dir /home/valheim/server \ +login anonymous +app_update 896660 validate +quitTimeoutStartSec=600The path to steamcmd depends on how it was installed - /usr/games/steamcmd is where the Ubuntu and Debian package puts it; a manual install lives wherever you unpacked it. Raise TimeoutStartSec so a slow download is not treated as a failed start. When there is no new build, the step takes a few seconds.
For a vanilla server this is the right default. After a patch, players update their game and find the server already matches. The alternative is the "Incompatible version" error and somebody messaging you at midnight - see updating a Valheim server for how the version check works.
For a modded server it is the wrong default, every time. A game update breaks BepInEx plugins until their authors catch up, sometimes for days. A server that updates itself on the morning restart greets everyone with a crash on start or a wall of mismatch kicks. Remove the pre-start step, update by hand when your mods have been updated, and take a backup first. Keep the scheduled restart; just keep the update out of it.
In the lloesche/valheim-server Docker image the same split is two variables: RESTART_CRON (daily at 05:00 by default) and UPDATE_CRON (every 15 minutes by default), each with an _IF_IDLE switch that holds the action while players are connected. For a modded container, set UPDATE_CRON to an empty value and keep RESTART_CRON. Valheim in Docker has the full variable table.
Restarts and backups together#
Order matters. A backup copies the files on disk, and those files are only as fresh as the last save. If you back up first and restart second, the backup can be up to a full save interval old. If you restart first, the clean stop writes the world, and a backup taken a few minutes later contains everything up to the restart.
The sequence that works:
- Warn players (if anyone could be on).
- Restart, which saves on the way down.
- Wait until the server is fully up again - two to five minutes for a large world.
- Take the backup, then copy it off the machine.
Do not schedule the backup for the same minute as the restart. A copy taken while the server is writing its final save can capture a truncated .db, which is exactly the file you would reach for after a disaster. Valheim's own -backups rotation is not a substitute: it lives in the same folder on the same disk. Valheim server backups and world corruption covers restoring and spotting a damaged world.
Doing it on a panel#
On a hosted panel you do not write cron lines or units; the same building blocks are tasks in a schedule. On RE:NODE, the Schedules tab takes a cron expression and an ordered list of tasks with delays between them, and each task is a console command, a backup or a power action. A daily restart with a fresh backup is two tasks:
| Order | Task | Delay before it | Purpose |
|---|---|---|---|
| 1 | Power action: restart | - | Clean stop saves the world, then start |
| 2 | Backup | 5 minutes | Captures the world as just saved |
The Restart power action sends a clean stop, so the world is saved before the server goes down, and backups are stored off the machine they protect. A console command task is not useful for warnings on vanilla Valheim, because the server does not read console input; post the warning from Discord, or schedule the restart for an empty hour. The crash watcher that warns about repeated restarts does not count restarts you asked for, so a daily schedule will not trip it. The schedules section of the guides shows where each field is.
One thing a panel schedule cannot see is whether players are online. If that matters, pick the hour carefully or use a server-side mod that delays restarts while people play.
When a scheduled restart goes wrong#
The world rolled back after the restart. The stop was a kill, not an interrupt. Check the log for World saved just before shutdown. On systemd, set KillSignal=SIGINT and raise TimeoutStopSec. In Docker, set stop_grace_period to a minute or two.
The server did not come back. Look at the start-up log, not the shutdown. The usual causes after a scheduled restart are an update that broke a mod, a SteamCMD download that failed half-way, or a world that now needs more memory than the limit to load. Valheim server crashes on start lists the errors.
The restart ran at the wrong hour. Time zone. Compare date on the machine with what you expected, and remember containers often run in UTC.
Players got "Incompatible version" the morning after a patch. The server updated and their clients had not yet - or the reverse, if you removed the update step. Tell the group to update and restart Steam.
Console players cannot rejoin. The join code changed. Post the new one; the crossplay guide covers where it appears.
FAQ#
Does a restart save the Valheim world?
Only a clean stop does. The server writes the world when it receives an interrupt signal, as a normal stop on a panel or systemctl stop with KillSignal=SIGINT sends. A forced kill, an out-of-memory stop or a power cut loses everything since the last timed save.
Can I send a warning message from the server console?
Not on vanilla Valheim. The dedicated server has no console input and no broadcast command. Use a Discord message before the restart, a mod that adds server announcements, or a restart time when nobody is online.
How long does a Valheim restart take?
Usually one to three minutes: the save on the way down, then loading the world. Large, heavily built worlds on slow disks take longer, and an update check adds whatever the download needs.
Should a modded server update automatically on restart?
No. Game patches break BepInEx mods until they are updated, and an automatic update turns a routine restart into a server that will not start. Restart on a schedule, update by hand once your mods support the new version.
Will daily restarts wear anything out or cost progress?
No. A clean restart costs nobody anything except the minute or two of downtime. Progress is only lost if the stop is not clean, which is why the signal and timeout settings matter more than the schedule.
