How to Set Up a Windrose Dedicated Server

Before you start: what a dedicated server actually gives you

A dedicated server keeps the world running as its own process instead of tying it to one player’s game session. That matters for an always-on crew world: friends can join when the host is not in-game, and the world state is stored in one central place instead of depending on whoever opened the save that night. If this is your first time self-hosting a game server, the practical difference with Windrose is that the server has to live in its own folder and wants a clean start-stop cycle before you edit anything.

Hardware matters more as the world gets busier. The official figures below are a good floor, and they are more useful than guessing from slot count alone. If you want the wider context behind CPU, RAM and storage choices, compare them with general game server hardware requirements.

Look at what changes between the tiers: the CPU line and the 35 GB SSD stay the same, and only the RAM grows with the crew. Kraken Express strongly recommends an SSD, because the world database is read on start-up and written constantly while you play. If you plan to host and play on the same Windows PC, the official guidance is to budget the client’s minimum 16 GB plus another 8 GB for the server, so 24 GB total is the practical target.

Get the server files: three routes, and why folder location matters

There are three sensible ways to get Windrose server files. The right route depends on how you want to run it, not on what looks shortest on paper.

The location matters because the dedicated server will not work correctly from inside the game folder. If you launch it there, the game client can shut it down because the client also spins up its own internal server. In practical terms, that means a dedicated server must have its own folder and its own lifecycle.

force_install_dir "C:\Game_Servers\Windrose_Server"
login anonymous
app_update 4129620 validate
quit

That SteamCMD route is the tidy option for a remote Windows machine because it separates install, update and restart work. It also reduces mistakes after patches, as the same command later updates the server in place.

First launch: create the world, confirm the invite code, then stop cleanly

For the first run, use StartServerForeground.bat. It is the recommended launcher because it keeps a console window open with logs, shows when the world has actually loaded, and lets you shut the server down by closing the window. You can run WindroseServer.exe directly, but that becomes a background process and is harder to inspect or stop cleanly.

When the server finishes loading, it prints an invite code in the console. That code also appears in R5\ServerDescription.json. From the client, friends join through Play -> Connect to Server and paste the code. For this first pass, the point is not to fine-tune anything yet; it is to let the server create both configuration files properly.

Once it has started once, stop it. That first start-stop matters because Windrose auto-creates ServerDescription.json and the world’s WorldDescription.json. Editing before those files exist just wastes time, and editing while the server is still running risks the server overwriting your changes or adjusting fields on its own.

ServerDescription.json: the file that decides how the server behaves

ServerDescription.json lives in the server’s R5 folder and controls identity, joining method and world selection. Only edit it while the server is shut down. The server writes to this file itself and may adjust fields if it detects a problem on start, so a change made while it is running can simply disappear.

The password fields are the one pairing rule to take seriously: if the password is empty, IsPasswordProtected should be false; if a password is present, set it to true. Kraken Express warns that getting this pairing wrong can cause unexpected behaviour, and a broken password check is the last thing you want to debug while the crew waits.

{
  "PersistentServerId": "<leave as generated>",
  "InviteCode": "f1014dc1",
  "IsPasswordProtected": true,
  "Password": "CrewOnly",
  "ServerName": "North Sea Crew",
  "WorldIslandId": "796AE3C6113C451DE5BD791D70E4A52B",
  "MaxPlayerCount": 4,
  "UserSelectedRegion": "EU",
  "P2pProxyAddress": "",
  "UseDirectConnection": false,
  "DirectConnectionServerAddress": "",
  "DirectConnectionServerPort": 7777,
  "DirectConnectionProxyAddress": "0.0.0.0",
  "AutoLoadLatestBackupIfHasBroken": true,
  "CanLaunchMultipleServerInstances": false
}

Choose how players connect: invite code mode or direct connection

This is the choice most quick-start guides gloss over, but it decides how much networking work you do and what can go wrong later. For a general explanation of why geography still matters to responsiveness, see server location and ping; for a UK-hosted Windrose crew using the Connection Service, EU is the safest manual region because it covers both EU and NA.

Pick invite code mode first if the server is on a spare Windows PC behind a normal home router. It avoids manual port mapping, and the server will use dynamic ports through the Connection Service. The downside is that you cannot choose fixed ports in that mode, so troubleshooting focuses on router NAT behaviour, UPnP, and disabling any VPN or proxy temporarily.

Pick direct connection if you need a predictable endpoint. That is usually the better fit on a remote Windows box, inside Docker, or on rented hosting where opening a known port is simpler than relying on consumer router punch-through. Direct mode also makes local LAN joining straightforward because players on the same network can use the server’s local IP and chosen port.

If players are on a different network, direct mode needs a public external IP on the router and a forward for both TCP and UDP. If you only forward one protocol, the server may appear half-alive: visible to some checks, but unable to complete joins reliably.

203.0.113.25:17777 -> 192.168.1.100:7777
Protocol: TCP and UDP

World settings: presets, custom values, and the updater step people miss

The world file is WorldDescription.json, stored per world under R5\Saved\SaveProfiles\Default\RocksDB_v2\<game version>\Worlds\<world id>\WorldDescription.json. Presets are Easy, Medium and Hard. If you hand-edit values away from a preset, the server treats that world as Custom on the next launch.

The easiest way to avoid mistakes is to build the custom preset in the game first and copy the values across. That reduces the chance of leaving out tags or mixing a preset label with values that no longer match it.

These settings mostly change encounter difficulty, not raw server efficiency. For example, lowering enemy health can shorten fights, but it does not remove the AI and replication work of extra players and extra active enemies. The two co-op correction modifiers are about scaling challenge with group size, so they matter most when your crew size varies a lot between sessions.

Kraken Express’s procedure for changing world settings on a dedicated server has four steps: stop the server, edit the world’s WorldDescription.json, run R5WorldDescriptionUpdater.exe from a Command Prompt in the server root with the path to that file, then start the server again. The updater is the step most people skip, and without it you are left guessing whether the change took.

R5WorldDescriptionUpdater.exe R5\Saved\SaveProfiles\Default\RocksDB_v2\0.10.0\Worlds\796AE3C6113C451DE5BD791D70E4A52B\WorldDescription.json

Player count and performance: set the cap for your real crew, not the theoretical maximum

The Steam store page lists co-op for up to 8 players, but Kraken Express recommends parties of up to 4 because of performance, especially in the late game. That advice is not just caution. More players means more combat state, more ship state, more world updates to send over the network, and more work on the server’s main thread to keep simulation timing consistent.

MaxPlayerCount should reflect who actually turns up together. Setting it higher than needed does not buy you anything on a small private crew server, but it increases the odds that one unusually busy session becomes the session that exposes CPU pressure, RAM pressure or save churn.

Saves, backups and moving a single-player world without breaking it

Dedicated server saves live under Windrose Dedicated Server\R5\Saved\SaveProfiles\Default\. The important folders are:

• RocksDB – old saves from before 0.10.0.5.120
• RocksDB_v2 – the live runtime database; do not touch it directly
• RocksDB_v2_Backups – backups used after 0.10.0.5.120

The reason not to meddle with RocksDB_v2 is simple: it is the live database, so half-edited or half-copied files are a straightforward route to corruption. The safer pattern is stop the server, copy full save data, and keep independent backups. If you want the wider principle, this is the same pattern described in how game server backups work.

Set AutoLoadLatestBackupIfHasBroken to true unless you prefer to recover by hand: on launch, the server then tries to restore a broken save from its backups instead of stopping there. Also leave CanLaunchMultipleServerInstances at false. That guard exists to stop two server processes writing to the same database, which is exactly how worlds get damaged.

Move a single-player world to the dedicated server

1. Back up the client save and the server save first.
2. Shut down both the game client and the dedicated server.
3. From the client save at %localappdata%\R5\Saved\, copy the whole WorldID folder from RocksDB\{GameVersion}\Worlds\{WorldID} or from RocksDB_v2_Backups if you need the _Latest copy.
4. Paste that folder into the server at R5\Saved\SaveProfiles\Default\RocksDB\{GameVersion}\Worlds\.
5. Open ServerDescription.json and set WorldIslandId to that folder’s exact name.
6. Start the server and verify that the correct world loads.

Never rename a world folder. The database relies on the ID, and a “tidier” folder name is a very common way to end up with a fresh world instead of the one you meant to load. If you want to host several worlds over time, keep their folders intact and change WorldIslandId before restart.

Updating after patches, plus Docker, Linux and rented servers

Server and client versions must match. If they do not, you can get connection failures, odd behaviour or players who simply cannot join. That makes updating a dedicated server a routine admin job, not an optional extra.

• SteamCMD install: rerun app_update 4129620 validate. It downloads only changed files.
• Steam Tools install: let Steam update Windrose Dedicated Server, then restart the server.
• Copied-folder server from EGS or Stove: update the game, copy the new WindroseServer folder, move the old R5\Saved into the new server’s R5\Saved, then launch.

Back up before every patch or hotfix. Patch day is when people rush, move folders around and overwrite the wrong copy, and a fresh backup turns that mistake into a two-minute fix.

On Linux, the position is slightly awkward: the dedicated server binary is still described as Windows-only, but there is an official Docker image and rented providers commonly run it through a compatibility layer. The official Docker instructions are short: create a folder for your saves, put a ServerDescription.json in it with “UseDirectConnection”: true and “DirectConnectionServerPort”: 7777, then pull and run the image with port 7777 open for TCP and UDP. Players connect with a direct IP connection, for example 127.0.0.1 and port 7777 on the same machine.

docker pull windroseserver/windroseserver:latest

docker run --user ue_user --name WindroseServer -p 7777:7777/tcp -p 7777:7777/udp -d -v {path_with_save}\Saved:/home/ue_user/app/R5/Saved -v {path_with_save}\ServerDescription.json:/home/ue_user/app/R5/ServerDescription.json windroseserver/windroseserver:latest

Rented servers remove most of the install and update handling. In return, you trade some file-level control for a panel that usually exposes the basics such as invite code, player count, server name and password. Also note that vanilla Windrose does not currently include built-in admin commands for kick, ban or manual save control. Some hosts add RCON through mods or frameworks, but that does not turn vanilla server options into native admin commands.

Symptom, likely cause, first fix

Windrose server FAQ

Is the Windrose dedicated server free?

Yes. On Steam it is a separate free tool, and the SteamCMD install can be fetched anonymously without needing a purchased copy on that machine. EGS and Stove users can also use the server files by copying the WindroseServer folder out of the game install.

How do friends join a Windrose dedicated server?

There are two ways. In the default setup, they use Play -> Connect to Server and paste the invite code shown in the server console or stored in R5\ServerDescription.json. In direct mode, they join by IP and port instead.

Do I need to port forward for a Windrose server?

Not always. Invite code mode uses the Connection Service with NAT punch-through, so it is designed to avoid manual port forwarding. You do need port forwarding for direct connection across different networks, and the forward must allow both TCP and UDP.

How many players can a Windrose dedicated server have?

The co-op cap is up to 8 players, controlled by MaxPlayerCount. The official recommendation is to keep parties to up to 4 for smoother performance, especially later in the game. For a private crew world, size the cap around actual attendance rather than the maximum possible number.

Can I run a Windrose dedicated server on Linux?

The plain dedicated server is still described as Windows-only, but there is an official Docker image and rented hosts often run the server under a compatibility layer. In practice, Linux is most straightforward through that Docker route or through a managed host rather than trying to treat it like a native Linux game server.

More Windrose server help

The host comparison, plus the explainers behind self-hosting, backups and server location.