Vintage Story dedicated server setup, end to end

Nov 4, 20256 min read

Vintage Story dedicated server setup, end to end

The official Vintage Story documentation is correct but scattered. Most people set up a server by stitching together three forum posts and a Discord thread. This article is the consolidated walk-through, written for someone who just bought VS and wants to host for friends.

What you need

  • A Linux or Windows host with at least 4 GB of RAM available.
  • VS server software (free, downloaded from the VS site).
  • The server owner's VS account (you do not need a separate account for the server itself, but players each need their own VS license).
  • Open TCP and UDP on the server port (default 42420).

VS does not require a paid hosting plan. You can run it on a home machine if you want. See the self-hosting article for trade-offs.

The setup at a glance

Download VS server pack

Install .NET 7/8 runtime

First boot - generates default configs

Stop server

Edit serverconfig.json

Edit worldconfig.json BEFORE
first world generation

Whitelist player UIDs

Open TCP + UDP 42420 in firewall

Install as systemd service

Set up backup cron

Add mods, restart

Test with one player

Open to group

Download the server software

From the official VS downloads page, grab the server-only package for your OS. As of 2026, the canonical archive name is vs_server_linux-x64_1.20.x.tar.gz on Linux and vs_server_1.20.x.zip on Windows.

Unpack to a dedicated directory. On Linux:

mkdir -p ~/vs-server
cd ~/vs-server
tar xzf vs_server_linux-x64_1.20.x.tar.gz

You should see VintagestoryServer.dll (Linux) or VintagestoryServer.exe (Windows), plus a launcher script and a data/ folder.

First boot

Since VS 1.18, the server runs on .NET (no longer Mono). Install the .NET 7 or 8 runtime first (apt install dotnet-runtime-8.0 on recent Debian / Ubuntu, or follow Microsoft's official .NET install guide). On Windows, the server is a native .exe.

Linux:

dotnet VintagestoryServer.dll

Windows:

VintagestoryServer.exe

This generates the default config files in data/ and starts listening on the default port.

Stop it (Ctrl+C) so we can configure properly.

Configure serverconfig.json

The main config lives at data/serverconfig.json. The important keys for first-time admins:

{
  "ServerName": "MyFriendsServer",
  "ServerDescription": "Vintage Story friends",
  "ServerUrl": "",
  "MaxClients": 8,
  "Password": "",
  "Port": 42420,
  "Ip": "0.0.0.0",
  "AdvertiseServer": false,
  "WhitelistMode": false,
  "Whitelist": [],
  "Bans": [],
  "DefaultRoleCode": "suplayer",
  "Roles": [...]
}

For a small private server:

  • Set ServerName and ServerDescription to something memorable.
  • Set MaxClients to your real max + 2 (room for crashes / reconnects).
  • Leave Password blank if you use whitelist; set it if you want a shared password.
  • Set WhitelistMode to true for friend groups (highly recommended).
  • Set AdvertiseServer to false if not listing publicly.

Configure worldconfig.json

VS world generation has many knobs. Most defaults are fine. The ones worth setting at world creation:

{
  "Worldname": "MyWorld",
  "Seed": "[your-seed-or-random]",
  "PlayStyle": "surviveandbuild",
  "WorldClimate": "realistic",
  "WorldType": "standard"
}

Critical: set these BEFORE the world generates. Once VS generates the world, many of these become hard or impossible to change.

If you want a multi-year survival server, also consider:

  • PlayerLivesEnabled (off if you want unlimited lives).
  • TemporalStability (essential mechanic, leave on unless you know why you'd disable).
  • RandomTickSpeed (defaults are tuned; don't change unless you understand the ramifications).

Whitelist your friends

After first boot, add players to the whitelist via console:

/whitelist add steve_player_id

Player IDs (UIDs) come from their Vintage Story account. Easiest way to get a player's UID: have them join once (with whitelist temporarily off), note the UID from the console log, then re-enable whitelist.

Open the network port

VS uses both TCP and UDP on its server port (default 42420). Open both.

Linux (ufw):

sudo ufw allow 42420/tcp
sudo ufw allow 42420/udp

On a paid host, this is typically already open or configurable in the panel.

Run as a service (Linux)

For 24/7 operation, run the server under systemd. Create /etc/systemd/system/vs-server.service:

[Unit]
Description=Vintage Story Server
After=network.target

[Service]
Type=simple
User=vs
WorkingDirectory=/home/vs/vs-server
ExecStart=/usr/bin/dotnet /home/vs/vs-server/VintagestoryServer.dll --dataPath /home/vs/.config/VintagestoryData
Restart=on-failure
RestartSec=10

[Install]
WantedBy=multi-user.target

Then:

sudo systemctl daemon-reload
sudo systemctl enable vs-server
sudo systemctl start vs-server

The server now starts at boot and restarts on crash. Logs go to systemd journal: journalctl -u vs-server -f.

Mods

VS mods go in Mods/ inside your server data directory (on Linux, usually ~/.config/VintagestoryData/Mods/).

Get mods from the VS mod database. Server-only or server-and-client; check each.

Every client must have the same mod versions as the server. If you install a content mod on the server, all players need it too. Communicate the mod list to your group.

After adding mods, restart the server. Watch the log for mod load errors.

Backups

VS world saves are in ~/.config/VintagestoryData/Saves/. Each save is a .vcdbs file. Back this file up.

Recommended:

  • Hourly: copy .vcdbs to a backup folder.
  • Daily: compressed snapshot off-host.
  • Weekly: long-term archive.

.vcdbs files are SQLite-style. Don't copy while the server is writing. Either stop the server briefly or use a snapshot mechanism.

A simple cron pattern (Linux):

#!/bin/bash
SAVE="/home/vs/.config/VintagestoryData/Saves/MyWorld.vcdbs"
BACKUP_DIR="/backups/vs"
DATE=$(date +%Y-%m-%d_%H-%M)

# VS has no Minecraft-style RCON. To force a save before copying, send /autosavenow
# to the server's stdin (e.g., a tmux session you can write into), or rely on the
# normal autosave interval and copy soon after it fires.

# Copy the save file (do this when the server isn't actively writing)
cp "$SAVE" "$BACKUP_DIR/MyWorld-$DATE.vcdbs"

# Prune to keep 30 daily
ls -1t "$BACKUP_DIR"/MyWorld-*.vcdbs | tail -n +31 | xargs -r rm

A safer pattern: use /genbackup from the in-game console (creates a clean snapshot inside BackupSave/), or stop the server briefly for the copy.

Common first-time problems

Symptom Most likely cause
Server starts, players can't connect Firewall. Check BOTH TCP and UDP 42420
"Connection refused" after 30 seconds Public IP / NAT mismatch with what VS thinks
Server crashes on world load Corrupted save or incompatible mods. Try with no mods first
Performance is awful with 3 players Single-thread CPU bottleneck. See VS performance article
Players disconnect every few minutes UDP packet loss. ISP / host network issue

Updating the server

When a new VS version drops:

  1. Stop the server.
  2. Back up the entire data/ directory and the save folder.
  3. Replace server binaries with the new version (unpack new download over old).
  4. Boot. Watch for migration messages in the log.
  5. Test with one player before announcing.

Mod compatibility is the most fragile area. After a major version, expect to wait days or weeks for mods to catch up.

A clean starter checklist

[ ] Server downloaded and unpacked
[ ] First boot generated config files
[ ] serverconfig.json edited (name, max clients, whitelist on)
[ ] worldconfig.json reviewed before world generation
[ ] Whitelist populated with player UIDs
[ ] UDP port open on firewall
[ ] systemd service installed (Linux)
[ ] Backups scripted and tested
[ ] Mod folder populated and clients informed
[ ] Test with one player before opening to group

Conclusion

VS server setup is fundamentally simple but has its own quirks (UDP, .NET on Linux, the data/ location, the mod sync requirement). Follow this checklist once and you'll have a stable server. Most VS server problems trace to skipping one of the steps above.


Hosting your game server with AndroHost means we handle most of what's in this post for you automatically: tier sizing, SRV records, off-site backups, DDoS protection.

Browse plans·More posts·Discord