Valheim dedicated server on a Linux VPS: sizing to updates

A Valheim server on a Linux VPS needs an x86-64 machine with two vCPUs, 4 GB of memory for a group of up to six (6-8 GB for ten, or for mods), 20 GB or more of SSD, Ubuntu LTS or Debian, and a location close to your players. Install the server with SteamCMD as an unprivileged user, open UDP 2456 and 2457 in both the VPS's own firewall (sudo ufw allow 2456:2457/udp) and the provider's network firewall if it has one, and run the server as a systemd service rather than in tmux, so it survives reboots and saves when stopped. Then keep two things updated on different schedules: the operating system automatically, and the game deliberately. That is the whole job; the rest of this post is the reasoning, the exact commands and the problems a VPS adds that a home PC or a game host does not have.

Is a VPS the right home for a Valheim server?#

A VPS gives you a whole Linux machine for a monthly price: root access, a public IP, and nobody else's rules. For Valheim that means any mod, any start argument, any backup scheme, several worlds on one box, and other things running beside the server - a Discord bot, a small website, a map viewer.

It also makes you the administrator. Nobody else patches the kernel, notices the disk filling, rotates the logs or restores the world when it corrupts. If that sounds like a hobby, a VPS is good value. If it sounds like a chore, a managed game server does the same job with a panel on top, and the price gap is smaller than people expect. VPS vs VDS vs dedicated server explains the differences in what you are actually renting.

Two things to rule out before you pay for anything:

• ARM instances. The Valheim dedicated server is built for x86-64 Linux only. The cheap ARM tiers some providers advertise will not run it natively, and emulation layers are not something to build a group's world on. Check the CPU architecture in the plan details.
• Burstable or heavily shared CPU. Plans that give you a fraction of a core with "burst credits" run fine for a few minutes and then throttle. Valheim's simulation is steady load, not bursts, so it will use the credits up and then stutter.

Sizing the VPS#

Valheim's server leans on one main thread, so a fast core matters more than many slow ones, but a second vCPU is worth having - saving, networking and SteamCMD updates happen off the main thread, and the operating system needs somewhere to run. Memory grows with the explored world and with the number of building pieces; a mapped world with four large bases needs much more than a fresh seed.

The figures below are for the whole VPS, so they include the operating system, SSH, a firewall and the memory spike during a SteamCMD update - roughly 0.5-1 GB on top of the game itself.

Disk use is modest: about 2 GB for the server, a world file that typically grows to between 20 and 150 MB, and backups. The extra space in the table is for the OS, SteamCMD's cache and a reasonable number of archived backups on the box itself. Prefer NVMe or SSD; the freeze during a world save is a disk write.

Location matters more than any spec. Pick the region with the lowest latency to most of your group; for a European group, a German or Dutch data centre will beat a faster machine in the United States every time. Valheim uses little bandwidth - tens to low hundreds of KB/s per player - so the port speed on the plan is irrelevant. The detail on how memory grows over a world's life is in how much RAM a Valheim server needs.

On shared virtualisation, check for CPU steal once the server is running with players on it:

$ vmstat 1 10# the last column, st, is time the hypervisor gave your vCPU to someone else

A steal figure that sits above a few percent while players complain of lag means the host is oversold, and no setting inside the VPS will fix it. A plan with dedicated cores, or a different provider, will.

First steps on a fresh VPS#

Before anything to do with Valheim, make the box safe to leave on the internet. On Ubuntu or Debian, as root or a sudo user:

$ sudo apt update && sudo apt full-upgrade -y$ sudo adduser admin && sudo usermod -aG sudo admin# copy your SSH public key to the new user, log in with it, then:$ sudoedit /etc/ssh/sshd_config.d/50-hardening.conf

PasswordAuthentication noPermitRootLogin no

$ sudo sshd -t && sudo systemctl reload ssh

Keep your current session open and test a new login before you close it; a typo in the SSH config locks you out, and on a VPS that means the provider's rescue console. The SSH service is called ssh on Ubuntu and Debian, sshd on most other distributions. SSH keys and hardening covers keys, fail2ban and the rest.

If the plan has 4 GB or less, add a small swap file. It will not make the server faster - a game server that swaps is a game server that stutters - but it gives the kernel somewhere to put idle memory during a SteamCMD update instead of killing the server:

$ sudo fallocate -l 2G /swapfile$ sudo chmod 600 /swapfile$ sudo mkswap /swapfile && sudo swapon /swapfile$ echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

Linux swap and the OOM killer explains what happens when memory does run out, and why the world loses whatever was not saved.

Then install the server itself: SteamCMD, a dedicated valheim user, app 896660 with an anonymous login, and your own copy of the start script. That is a fifteen-minute job, written up step by step in installing a Valheim server on Linux with SteamCMD, so it is not repeated here.

Opening the ports: ufw#

Valheim needs two UDP ports: the game port, 2456 by default, and the port above it, 2457, which answers Steam's server queries. Both are UDP. A rule for TCP does nothing.

On Ubuntu, ufw is the simplest firewall front end. Allow SSH first, or enabling the firewall will cut your own connection:

$ sudo ufw allow OpenSSH$ sudo ufw allow 2456:2457/udp comment 'Valheim'$ sudo ufw default deny incoming$ sudo ufw default allow outgoing$ sudo ufw enable$ sudo ufw status verbose

OpenSSH is an application profile ufw ships on Ubuntu; on a minimal Debian install where it is missing, use sudo ufw allow 22/tcp instead, or the port you moved SSH to. If you run a second world with -port 2458, add 2458:2459/udp as well. Each server uses its game port and the next one up, so servers need to be at least two ports apart. Valheim ports 2456-2458 explained covers why older guides open 2458 for a single server.

The general patterns - default deny, limiting SSH, logging - are in the ufw firewall guide.

Opening the ports: iptables and nftables#

If you do not use ufw, or the distribution does not ship it, write the rules directly. With iptables:

$ sudo iptables -A INPUT -i lo -j ACCEPT$ sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT$ sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT$ sudo iptables -A INPUT -p udp --dport 2456:2457 -j ACCEPT$ sudo iptables -P INPUT DROP

Order matters: the SSH and established-connection rules must be in place before the default policy becomes DROP. Rules set this way vanish at reboot. On Debian and Ubuntu, install iptables-persistent and save them:

$ sudo apt install iptables-persistent$ sudo netfilter-persistent save

On current Debian and Ubuntu the iptables command is usually a compatibility layer over nftables. If you prefer to write nftables directly, the equivalent rule inside an inet filter table's input chain is:

udp dport 2456-2457 accept

Whichever tool you use, use only one. Running ufw and hand-written iptables rules together produces a rule set nobody can reason about. Firewall rules that matter covers the bigger picture.

To check the server is listening:

$ sudo ss -ulpn | grep valheim

You should see UDP sockets on 2456 and 2457. Testing UDP from outside is less tidy than TCP - most port checkers only speak TCP, and a closed UDP port often looks the same as an open one that did not reply. The honest test is a player joining by IP, then checking that the server appears in the community list.

tmux or screen versus a service#

Most quick guides start the server in tmux or screen so it keeps running after you log out:

$ tmux new -s valheim$ ./start_valheim.sh# detach: Ctrl+b then d; come back with: tmux attach -t valheim$ screen -S valheim$ ./start_valheim.sh# detach: Ctrl+a then d; come back with: screen -r valheim

That is fine for an evening of testing. It is not fine for a server you leave running, because of what it does not do:

The row that loses worlds is the fourth. When the VPS reboots for a kernel update, a tmux session is killed with everything else, and the world loses everything since the last timed save - up to thirty minutes with the default -saveinterval. A systemd unit stops the server with SIGINT first, Valheim saves, and only then does the machine go down.

The attachable console, the one thing tmux offers that systemd does not, is worth almost nothing for Valheim: the dedicated server reads no commands from standard input. Admin commands are typed in the game client's F5 console. Running Valheim as a systemd service builds the unit, the restart policy and the timers. If you want tmux plus management tooling, LinuxGSM's vhserver wraps the server in a tmux session with its own update, backup and monitor commands.

Keeping it updated: the OS and the game#

There are two kinds of update on a Valheim VPS, and they want opposite treatment.

The operating system should update itself. Ubuntu enables unattended-upgrades for security updates by default; on Debian, install it and run sudo dpkg-reconfigure -plow unattended-upgrades. Kernel updates only take effect after a reboot, and unattended-upgrades does not reboot unless told to. Let it reboot at a quiet hour:

Unattended-Upgrade::Automatic-Reboot "true";Unattended-Upgrade::Automatic-Reboot-Time "05:00";

That is safe only because the server runs as a systemd service with a clean stop. With the server in tmux, an automatic reboot is an automatic loss of progress. If you would rather reboot by hand, check /var/run/reboot-required every week or so.

The game should update when you decide. When Valheim patches, players' clients update through Steam and the server has to match exactly, or everyone sees Incompatible version. Updating is one SteamCMD line, run as the valheim user with the server stopped:

$ sudo systemctl stop valheim$ sudo -u valheim /usr/games/steamcmd +force_install_dir /home/valheim/server \    +login anonymous +app_update 896660 validate +quit$ sudo systemctl start valheim

On a vanilla server, you can automate this by having the unit run the update before every start, so a restart picks up a patch. On a modded server, do not: patches break BepInEx mods until their authors rebuild them, and an update you did not choose leaves a server that will not start. validate also restores start_server.sh to the shipped version, which is why you start the server from your own copy. Timing for groups and the version-drift problem are in updating a Valheim server and fixing version mismatches.

Backups and day-to-day checks#

A VPS gives you one disk, and Valheim's built-in -backups copies sit on it beside the world. They protect against a bad save, not against a deleted directory, a full disk or a provider incident. Archive the save directory on a schedule, after a clean restart where possible, and copy the archive off the machine - to object storage, or to another computer. Valheim server backups and world corruption covers restoring, and game server backups to S3 shows how to send the archives somewhere else. Provider snapshots are a useful extra, but a snapshot taken while the server is mid-save is a snapshot of a half-written world.

A short routine catches most trouble before players do:

$ systemctl status valheim$ journalctl -u valheim --since today -g "Exception|Error"$ free -h$ df -h /$ uptime

Watch three trends over weeks: memory creeping towards the limit (a weekly restart usually keeps it flat), disk filling with backups or logs, and load average sitting above your vCPU count while people play. The first two are cheap to fix. The third means a bigger plan or a world that has outgrown its terraforming. If you are new to these tools, Linux commands for server admins is a good starting point.

On RE:NODE#

If you want the whole machine, RE:NODE's VDS line is an Intel i9-9900K in Germany, starting from 8 GB of memory and 2 vCPU, set up by hand within 24 hours; everything in this post applies to it. If you only want the Valheim server, the game plans start from 2 GB, arrive within about a minute of payment with crossplay on and both UDP ports already allocated, and replace the firewall, service and update work with a panel: a clean Stop and Restart, a Schedules tab for restarts and backups, and backup slots stored off the machine.

FAQ#

What is the smallest VPS that runs Valheim?

Two vCPUs and 4 GB of memory, on x86-64, for a small group on a fresh world. The game itself runs in about 2 GB at that size; the rest is room for the operating system and for SteamCMD updates. A 2 GB VPS runs it, but with no headroom at all.

Why can nobody connect even though ufw allows the ports?

Check the provider's own network firewall in their web console - it sits in front of the VPS and blocks traffic before ufw sees it. Then confirm the rules are UDP, not TCP, and that ss -ulpn shows the server listening on both ports.

Can I run Valheim on an ARM VPS?

Not natively. The dedicated server is only built for x86-64. Emulation layers exist, but they cost performance and break with updates, so they are not a sound base for a shared world. Choose an x86-64 plan.

Is tmux good enough if I am careful?

It works until the VPS reboots without warning - a provider maintenance window or a kernel update - and the world loses everything since the last save. A systemd unit costs ten lines and removes that risk, and you lose nothing useful, since Valheim has no stdin console.

How often should I update the server?

Whenever Valheim patches, because clients and server must match. Vanilla servers can update on every start. Modded servers should update only once their mods support the new version, so check before you run SteamCMD.