V Rising dedicated server: the Windows build, its ports and its settings

What the server is, and the Linux question

The game client carries a server of its own that runs in the background when a player hosts a private game. The dedicated server is the separate application for a machine that stays up when nobody is playing on it. Stunlock publishes it free on Steam, in the Tools section of the library, and through SteamCMD as app 1829350. When it runs it identifies as the game itself, app 1604030, which is what the steam_appid.txt shipped with the download sets.

There is no Linux build. The 1.1.x instructions state that only a Windows version of the server is available. The Linux and Docker guides that turn up for this game run the Windows binary under Wine; they are community projects, and Stunlock neither documents nor supports them. Valve's SteamCMD can fetch the Windows files on a Linux host with @sSteamCmdForcePlatformType windows, but that only solves the download. If the server misbehaves under Wine, you are the support desk.

Ports and what to expose

Three ports matter. Stunlock gives each as an example value in ServerHostSettings.json, not as a fixed number, so open whatever you actually configure.

The instructions are specific about the list: to show up there, both the query port and the game port must be open and forwarded; for players who connect directly, the game port alone is enough. ListOnSteam and ListOnEOS choose which list the server registers with; the client looks in the EOS list by default. With HideIPAddress the EOS listing withholds the address and players come in through relay servers. Address binds the game socket to one IP when the machine has several.

The loopback bind for RCON is our suggestion, not Stunlock's: with Rcon → BindAddress set to 127.0.0.1, only a client running on the server itself reaches the console, and the TCP port never has to be opened. Stunlock's own example script points RCON at an internal address instead, which suits a private network you control.

Sizing the machine

Stunlock's instructions publish no CPU, memory or disk figures for the server. They publish the levers that set its load instead, so size from those and measure.

• MaxConnectedUsers: the player cap. The documented technical maximum is 128; the example value is 40.
• MaxConnectedAdmins: extra slots so admins can join a full server.
• ServerFps: the target tick rate, example value 30.
• LowerFPSWhenEmpty with LowerFPSWhenEmptyValue: drops the target while nobody is logged in.
• Several instances on one host are supported, each with its own -persistentDataPath and its own ports; Stunlock's second example script derives game, query and RCON ports from one base number per instance.

Our advice, not Stunlock's: start at the player count you really expect, watch the VRisingServer.exe process in Task Manager or Performance Monitor through a busy evening, and raise the cap only when the numbers show headroom.

Which of our machines fit

Our bare metal game servers are whole machines: processor, memory and drives serve one customer alone, with administrator access. Windows Server images up to 2025 install in one click on the x86 lines that carry them; no ARM machine runs Windows. Windows costs extra: its licence is charged by the core, on top of the machine, every month, and takes no term discount. A box with far more cores than the game uses therefore costs more licence than it needs, so match the core count to the instances you plan to run.

• Delivery: a machine already racked is live about 30 minutes after the order is approved; see the servers ready to deploy. A specification built to order takes 4-24 hours through the build-to-order page.
• Network: every server has an unmetered port, 1 Gbps or 500 Mbps depending on the line, on our own network, AS19624.
• Recovery: rack servers and blades carry an out-of-band controller (HPE iLO, Dell iDRAC or a Supermicro BMC) with a browser console and power control once you add a console login. When a Windows update leaves Remote Desktop unreachable, that console is the way back in.
• Location: New York, Miami, San Francisco, Amsterdam and Bucharest. Ping each city's test IP from where your players are before you order.

Installing with SteamCMD

1. Over Remote Desktop, download Valve's steamcmd.zip, extract it to C:\steamcmd and run steamcmd.exe once; its first start creates the rest of its files.
2. Install the server. Valve recommends setting the install directory before logging in, which is the order Stunlock's own download script uses; validate checks every file.
3. Copy start_server_example.bat from the install folder to a file of your own. Updates can overwrite the example.
4. Point -persistentDataPath at a folder outside the install directory. Settings are read from its Settings subfolder and saves go to Saves.
5. Allow the game port, and the query port if you want a listing, in Windows Defender Firewall. Leave the RCON port closed.
6. Start the server, join, then put your SteamID on its own line in adminlist.txt in the Settings folder. No restart is needed. Enable the console in the game options, open it with ~ and run adminauth.

C:\steamcmd\steamcmd.exe +force_install_dir C:\VRisingServer +login anonymous +app_update 1829350 validate +quit

@echo off
REM my-server.bat, kept next to VRisingServer.exe
set SteamAppId=1604030
cd /d C:\VRisingServer
VRisingServer.exe -persistentDataPath D:\vrising-data -serverName "Night Court" -saveName "world1" -logFile ".\logs\VRisingServer.log" 1> nul

Settings: two files, overridden in place

ServerHostSettings.json holds hosting: name, description, ports, player caps, the join password, save behaviour and RCON. ServerGameSettings.json holds the rules of play. The defaults ship in VRisingServer_Data/StreamingAssets/Settings/; leave them alone, because an update can replace them. The server loads the defaults first, then looks in the Settings folder under your persistent data path, where a file may hold only the keys you change.

Every host setting can also be set by an environment variable such as VR_GAME_PORT or by a command-line flag such as -gamePort. For gameplay, GameSettingsPreset loads a named preset from GameSettingPresets (StandardPvP, StandardPvE and others), and GameDifficultyPreset takes Difficulty_Easy, Difficulty_Normal or Difficulty_Brutal.

{
  "Name": "Night Court",
  "Password": "set-a-join-password-here",
  "MaxConnectedUsers": 40,
  "AutoSaveInterval": 120,
  "Rcon": {
    "Enabled": true,
    "Password": "long-random-string-here",
    "Port": 25575,
    "BindAddress": "127.0.0.1"
  }
}

Both passwords are secrets. The join password gates the server and the RCON password controls it; Stunlock's docs require an RCON password whenever RCON is on.

Our advice, not Stunlock's: flags such as -password and -rconPassword end up in the process command line, which administrators and process-logging tools can read, and in batch files that get copied around; Stunlock's own second example passes -rconPassword that way. Keep both passwords in the override ServerHostSettings.json in the Settings subfolder of the data folder, and limit read access on that folder to the account that runs the server and to administrators.

Restarts, saves and backups

Stunlock recommends a restart every day, at the quietest hour. On Windows a Task Scheduler job does it; before it fires, the RCON command announcerestart warns players in their own language, and shutdown schedules the stop. To update, stop the server and run the SteamCMD line again.

• AutoSaveInterval is in seconds (example 120). AutoSaveCount caps how many autosaves remain.
• AutoSaveSmartKeep keeps saves across time windows, written as minutes:newest:oldest sets separated by commas, so a save from an hour or a day ago survives frequent saving.
• ResetDaysInterval and DayOfReset schedule wipes; the old save is backed up when the reset happens.
• Stunlock calls backups highly recommended: copy the Saves folder before patching and before the first start after a patch, and keep a copy off the machine.

A world started from the game client can move to the server. Find it through Load Game, then Go to Directory, and back up the whole session folder before touching it. Copy the session folder from its v4 folder into Saves\v4\ under the persistent data path and start the server with -saveName set to that folder. For the copied rules to apply, leave GameSettingsPreset empty and keep no ServerGameSettings.json of your own in the override Settings folder (nor an edited default). Once the server copy works, remove the local save from inside the game, so it does not show up twice.

When this is the wrong setup

• You need a native Linux server. None exists; budget for Wine troubleshooting or for the Windows licence.
• Your group plays on PS5. That server has its own instructions; this page does not cover it.
• A few friends, now and then. The client's built-in hosting does that without a machine of your own.