Windrose: Setting Up a Dedicated Server — Steam, SteamCMD, Docker Installation and Difficulty Settings

Windrose is going through its first real lull. The last patch, version 0.10.0.8, dates back to July 8, 2026 and amounted to three lines: projectiles that were passing through hulls at long range, improved Japanese localization, and a known bug with forward tacks. As for Ashlands, the first major content update, Kraken Express warned as early as April 28 that it would take "at least six months" of work, and the developer diary from July 1 has still not announced any release window.

In other words: between now and the fall, what will keep your playthrough going is your crew. And the most reliable way to keep a group together on a survival game that has sold over two million copies is a dedicated server: a world that runs continuously, where everyone connects whenever they want, without depending on the host's availability. The tool is free, it's already bundled with the game, and since patch 0.10.0.7 on June 25 it also runs on Linux thanks to an official Docker image.

A vocabulary heads-up before we begin: Windrose's client is translated into French (interface and subtitles), but the entire server side remains in English. The configuration file keys, the DedicatedServer.md manual bundled with the tool, and the online documentation have no French version: the field names quoted below must be written exactly as shown.

Getting the server: three routes, and one classic mistake

Windrose's dedicated server is a standalone, free executable that doesn't require owning the game on the host machine. Three ways to get it, all equivalent:

• From the game files: open the installation folder, then R5\Builds. The WindroseServer subfolder (or WindowsServer on Epic Games Store and Stove) is the server.
• From the Steam tool: in your library, switch the category filter to "Tools", search for Windrose Dedicated Server and install it like a game. This is the easiest route to keep updated.
• Via SteamCMD: the recommended method for a machine without a graphical interface, a remote server, or automation.

The mistake everyone makes the first time: launching the server from the game folder. It won't work. The folder present in the installation plays an internal role on the client side, and the client will kill the process as soon as it sees it running. Copy it elsewhere on the disk first, anywhere outside the game's folder tree, and work from that copy.

For SteamCMD, the server's app ID is 4129620 (the game itself is 3041230). The sequence comes down to four commands:

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

Anonymous login is enough: no license is required to install the server. To update it later, simply run app_update 4129620 validate again, which only re-downloads the modified files.

First launch and invite code

Two executables coexist in the folder. StartServerForeground.bat opens a console showing scrolling logs: this is the launch method to prefer, if only to diagnose a crash, and closing the window stops the server. WindroseServer.exe launches the process in the background, with no visual feedback, and you'll need to go through Task Manager to end it.

On first launch, the server generates its own configuration files and displays an eight-character invite code in the console, something like f1014dc1. If the line scrolled by too fast, you'll find it in R5\ServerDescription.json. All that's left is to paste it into the client's server connection screen, then pass it on to your crew.

ServerDescription.json: the fields that really matter

This single file, located at the root of the application, controls the server itself. Absolute rule: only edit it while the server is off, otherwise your values will be overwritten.

Two fields should never be touched: PersistentServerId, the instance's unique identifier, and DirectConnectionServerAddress, reserved for future use.

Direct IP: when and how

By default, Windrose relies on its own connectivity servers and assigns ports dynamically via NAT traversal, which requires a router with UPnP enabled. This route fails in two cases: an ISP that filters the game's services, or self-hosting behind an uncooperative router. Direct IP connection, added in mid-April, serves as a fallback solution. On a local network, it requires neither a public IP nor port forwarding: the host simply shares their local address and port, for example 192.168.1.100:7777.

Over the Internet, you need a public IP — some ISPs charge extra for it — and a TCP and UDP port forward from the router to the host machine, for example 203.0.113.25:17777 to 192.168.1.100:7777. Beware: with direct IP, invite codes no longer work, and a wrong password or a version mismatch will just kick you back to the main menu without any message. If nothing works: check the machine's address with ipconfig, drop port 7777 in favor of a higher, less contested port (17777, 27890, any free port under 65000), temporarily disable firewall and antivirus, and wait for the server to finish starting up before your first attempt.

Linux and Docker: the official route since June 25

Here's a point the online documentation hasn't caught up with yet: last updated on May 18, its FAQ still answers "Windows only" regarding Linux support. Patch 0.10.0.7, released on June 25, 2026, nevertheless added Docker images with support for a Linux server, with instructions provided in the DedicatedServer.md file shipped at the server's root. The public windroseserver/windroseserver image was in fact refreshed on July 8, in step with version 0.10.0.8.

The principle: pull the image with docker pull windroseserver/windroseserver:latest, create a folder on the host intended for save files, place a prepared ServerDescription.json in it, then launch the container under the ue_user user with port 7777 exposed over both TCP and UDP, and the Saved folder and configuration file mounted as volumes. Two values are mandatory in the file: UseDirectConnection set to true and DirectConnectionServerPort set to 7777. The container is therefore joined not via an invite code but by direct IP, using the address assigned to the container (127.0.0.1:7777 for a local test). If your save folder's path contains spaces, enclose it in quotes in the command.

As for sizing, the publisher provides modest recommendations: 8 GB of RAM and 35 GB of SSD storage for two players, 12 GB for four, 16 GB for ten, on two cores at 3.2 GHz. If you're hosting and playing on the same machine, count on 24 GB total—16 for the client plus 8 more for the server.

Adjusting difficulty: the real numbers behind the three presets

This is the most underrated benefit of the dedicated server. Each world has its own WorldDescription.json, stored in R5/Saved/SaveProfiles/Default/RocksDB_v2/<version>/Worlds/<world ID>/, and this file spells out exactly what the presets offered when creating a game actually cover.

Two takeaways here. First, the gap between Medium and Hard is asymmetrical: enemies take 50% more punishment but only hit 25% harder. Switching to Hard therefore mostly lengthens fights rather than making them more punishing. If you're after tension rather than attrition, raise MobDamageMultiplier to 1.5 or 1.75 while leaving health at 1.0—the allowed range for these two multipliers runs from 0.2 to 5.0. Second, BoardingDifficultyMultiplier affects neither damage nor health: it sets the number of enemy sailors you need to take down to win a boarding action. This is the lever to lower if your boardings feel long without feeling difficult.

The two most interesting parameters are those governing co-op scaling. Coop.StatsCorrectionModifier, set to 1.0 by default, adjusts enemy health and the rate at which they lose posture based on the number of connected players. But Coop.ShipStatsCorrectionModifier, meanwhile, is set to 0.0 by default: enemy ships get absolutely no reinforcement as your crew grows. This is the mechanical explanation for the feeling that naval combat falls apart with three or four players, while fights on foot remain manageable. Raising it to between 0.5 and 1.0 rebalances the sea without touching dry land.

One last setting worth knowing: EasyExplore. Its name is misleading, a holdover from older versions. Set to true, it disables the map markers that flag points of interest, making exploration more demanding. The game displays this under the name immersive exploration.

Editing this file isn't enough on its own: the changes then need to be validated. With the server shut down, open a command prompt at the server's root directory and run R5WorldDescriptionUpdater.exe, passing it the full path to the relevant WorldDescription.json. Without this step, your values won't take effect on restart.

Migrating a solo save to the server

There's no need to start from scratch. With everything shut down and backed up beforehand, the transfer comes down to four steps.

• Locate your world in %localappdata%\R5\Saved\SaveProfiles\<your profile>\. Depending on whether the format migration has taken place, it will be in RocksDB (old format, prior to version 0.10.0.5.120) or in RocksDB_v2_Backups. The RocksDB_v2 folder, meanwhile, is used for runtime operation: leave it untouched.
• Copy the entire folder bearing the world's identifier.
• Paste it into the server's Worlds folder, under R5\Saved\SaveProfiles\Default\, in the subfolder matching the game's version.
• Enter WorldIslandId in ServerDescription.json with the exact name of the copied folder.

Never rename a world folder: the database relies on these identifiers. And if Steam offers you a choice between the local save and the cloud save, always choose the local one — Steam's cloud has caused several waves of corrupted saves since launch, to the point where the studio had to add an automatic backup copy system.

Pitfall number one: version mismatch

Kraken Express stresses this point more than any other, and rightly so: the server version must match the client version exactly. A mismatch doesn't always result in an outright connection refusal; it can also produce vague bugs that are hard to trace back to their cause. The habit to adopt after every patch, no matter how minor, is to rerun app_update 4129620 validate or to retrieve the server folder from the new installation, then move the contents of the old R5\Saved into the new one.

With patch releases having slowed to a crawl — only three between May 18 and July 8 — maintenance stays light. That's even the decisive argument in favor of a dedicated server right now: set up properly once, it will hold steady until Ashlands, and a shared world that runs continuously remains the best reason to reopen Windrose during the months of waiting. Take the opportunity to ramp up the difficulty and fix the naval imbalance in co-op: that's fresh content without waiting for a single line of patch notes.