Vintage Story dedicated server on Linux, from .NET runtime to backups

What the server asks of the machine

Anego publishes one hardware estimate, on its self-hosting page and on the wiki's dedicated server guide. It is labelled a rough, conservative recommendation for a normal survival world where players like to spread out, and the page adds that tuning can probably lower it.

Applied to the default MaxClients of 16, that formula gives 1 GB + 16 x 300 MB = 5.8 GB of memory; the arithmetic is ours, not Anego's. Two things push past it: mods, and view distance. The config notes that a higher MaxChunkRadius (default 12) needs more RAM, and a higher MaxClients needs more RAM and CPU. On some Linux hosts the server crashes as if out of memory until sudo sysctl -w vm.max_map_count=262144 is set; vintagestory.at lists that fix on its hosting page.

Why a whole machine

The world is an SQLite file that grows as players explore, and the server writes it continuously. On a physical machine of your own, the cores, RAM and drives serve that process alone: nobody else's workload competes for I/O during an autosave, and the load you measure on a busy evening is the load the game really puts on the hardware.

Our game server hosting on bare metal runs on HPE enterprise hardware; you get root and pick the OS image. Every dedicated server includes an unmetered port and one IPv4 address; IPv6 is added at checkout at no charge. Rack servers and blades also carry an out-of-band controller (iLO, iDRAC or a BMC) with a browser console, which is how you recover a box after a bad firewall rule.

Installing on Ubuntu as a non-root user

The wiki is blunt: never run the server as root. Create a dedicated account, install the runtime and the two tools its server.sh script relies on (pgrep from procps, and screen), and enable ufw while nothing is listening yet. The wiki lists dotnet-runtime-10.0 for Ubuntu 24.04 and newer; if apt-cache policy shows no candidate, use Microsoft's install guide that the wiki links. Ubuntu 26.04 is among the images we install.

# Runtime and helpers (1.22.x needs .NET 10)
sudo apt update
apt-cache policy dotnet-runtime-10.0
sudo apt install dotnet-runtime-10.0 procps screen

# Service account with no login shell
sudo useradd -m -s /usr/sbin/nologin vintagestory

# Firewall first; check IPV6=yes so the rules cover IPv6 too
grep '^IPV6=' /etc/default/ufw
sudo ufw allow OpenSSH
sudo ufw allow 42420/tcp
sudo ufw allow 42420/udp
sudo ufw enable
sudo ufw status verbose

# Server archive, unpacked by the service user
VSVER=1.22.7
sudo -u vintagestory bash -c "cd /home/vintagestory && \
  curl -fO https://cdn.vintagestory.at/gamefiles/stable/vs_server_linux-x64_$VSVER.tar.gz && \
  md5sum vs_server_linux-x64_$VSVER.tar.gz && \
  mkdir -p server && tar -C server -xzf vs_server_linux-x64_$VSVER.tar.gz && \
  chmod +x server/server.sh"

Version 1.22.7 was the current stable build on 23 October 2026; take the newest from the downloads page in your game account's client area, and compare the md5 with the linuxserver entry Anego publishes in api.vintagestory.at/stable.json. Our Linux dedicated servers page lists the other distributions we install if you prefer Debian or AlmaLinux; the wiki gives the procps and screen packages for each distribution family and links Microsoft's .NET install guide for the runtime.

First start, whitelist and admin rights

Edit three variables at the top of server.sh so it runs as the right user against a data directory kept outside the install. Then start it, whitelist your own game account name and make yourself admin. /op is an alias for assigning the admin role.

# In server.sh set:
#   USERNAME=vintagestory
#   VSPATH=/home/vintagestory/server
#   DATAPATH=/home/vintagestory/data
sudo -u vintagestory nano /home/vintagestory/server/server.sh

alias vs='sudo -u vintagestory /home/vintagestory/server/server.sh'
vs start
vs command "/whitelist add YourGameName"
vs command "/op YourGameName"
vs status

# Live console; Ctrl+A then D detaches without stopping it
sudo -u vintagestory screen -r vintagestory_server

The default config ships nine roles, from suvisitor (can look and chat, cannot build or break) through suplayer, sumod and their creative counterparts, up to admin. Assign one with /player Name role sumod; no restart is needed. Setting DefaultRoleCode to suvisitor makes every newcomer a spectator until you promote them.

The serverconfig.json keys that matter

The file lives in the data path, /home/vintagestory/data/serverconfig.json. The wiki says to stop the server before editing it (vs stop), and that config changes take effect only after a relaunch. Set the password here, in the file, rather than with vs command "/serverconfig password ...", because a secret passed as a shell argument is recorded in ~/.bash_history and visible to ps while the command runs.

"ServerName": "Riverbend survival",
"Port": 42420,
"MaxClients": 16,
"Password": "a-long-random-passphrase",
"WhitelistMode": 0,
"AdvertiseServer": false,
"VerifyPlayerAuth": true,
"DefaultRoleCode": "suplayer",

• WhitelistMode: 0 is the default (on for dedicated servers, off for a single-player world opened to LAN), 1 is off, 2 is on. OnlyWhitelisted no longer enforces anything since 1.20.
• AdvertiseServer: adds the server to the public list; it is false in the default config, and listing needs a ServerName of 4-80 characters.
• VerifyPlayerAuth: checks on every join that the player is a logged-in, registered buyer of the game. Leave it on.
• Ip: null listens on every interface; set an address to bind one.

Afterwards run sudo -u vintagestory chmod 600 /home/vintagestory/data/serverconfig.json so only the service user can read the password, check the mode again after the next start, then vs start.

Backups and updates

/genbackup puts a complete copy of the running world in the backups folder (with the data path used here, /home/vintagestory/data/Backups; the path is our reading of the wiki's data-folder layout), and the wiki notes it runs without pausing the server. A backup file has the same format as a save: to restore, stop the server and copy it into Saves. Do not copy the live .vcdbs file by hand while the server runs: the server writes it continuously, so a copy taken by hand mid-write can be inconsistent; use /genbackup instead.

• Schedule it from cron with sudo -u vintagestory /home/vintagestory/server/server.sh command "/genbackup", then copy that backups folder to another machine.
• Prune old files: at the default 400 MB floor of free disk the server stops itself.
• Back up Playerdata too: the wiki says it holds each player's privileges, and it also contains the whitelist and ban files (playerswhitelisted.json, playersbanned.json).

For an update, the wiki says to remove the old installation files first or expect unpredictable behaviour, and to keep the data folder. With the layout above that means: run /genbackup, then vs stop, delete /home/vintagestory/server, unpack the new archive there, edit server.sh again, start. A jump across a .NET line (1.21 to 1.22 moved from .NET 8 to 10) needs the new runtime first.

Which of our machines fit, and when not to rent one

Size against Anego's formula plus headroom for mods, and pick a city near the group from New York, Miami, San Francisco, Amsterdam and Bucharest on the data center page. A racked machine is live about 30 minutes after the order is approved; a build to order takes 4-24 hours. Our Project Zomboid server notes cover a similar long-running survival world.

Skip ARM for this: the wiki calls the ARM64 server experimental and says mods that use Harmony patching do not work on it, so choose an x86 line. And for a few friends playing occasionally, the ad-hoc route (Open to LAN, then Open to Internet) or a home machine with port 42420 forwarded costs nothing; rent a machine when the world must stay up while its host is offline.