Dedicated Server Hosting

Windrose supports dedicated servers at the April 14, 2026 Early Access launch. The official Discord FAQ says the dedicated server build ships as a free Steam tool, and the official server guide explains both the simple install flow and the manual SteamCMD route. For groups that want a persistent world online even when the usual host is away, dedicated hosting is the intended setup.

Official Status

That split between 8 supported players and 4 recommended players matters. Windrose is officially sold as an up-to-8-player co-op game, but the official server configuration guide is more conservative when it talks about smooth real-world performance.

How You Actually Get the Server Files

1. Install the Windrose dedicated server tool from Steam Tools, or use SteamCMD if you want a manual server box workflow.

2. Copy the server files to a location outside the main game folder if you are using the bundled server files from the client install.

3. Edit the JSON configuration files only while the server is shut down.

4. Keep the dedicated server version matched to the current game client version after every patch or hotfix.

The official guide also documents a SteamCMD install path. The command sequence is: force_install_dir to your chosen folder, login anonymous, app_update 4129620 validate, then quit.

Core Files and Settings

The most important linkage is WorldIslandId in ServerDescription.json. It must match the exact world folder ID you want the server to load.

Hotfix 0.10.0.6 (May 18, 2026) added a SaveWorkflow.md file to the Dedicated Server root folder. The new document describes the server-side save and backup flow, alongside the existing server files in the table above. Administrators troubleshooting save synchronization or planning a manual backup rotation should read it before changing server file handling.

Self-Hosting Versus Renting

The official guide stays focused on self-hosting, and that is the safest source to trust. Provider control panels can be convenient, but the authoritative setup information still comes from Kraken Express.

Networking and Connection Notes

• The official guide says ports are dynamically assigned through NAT punch-through rather than fixed port forwarding rules.

• Your router should support UPnP if you are self-hosting.

• If clients fail to connect, the official troubleshooting notes recommend disabling proxy or VPN software temporarily.

• Version mismatch between the client and server is one of the first things to check after patches.

Platform and Host Notes

What the Official Guide Does Not Offer

Kraken Express has published a real setup guide, but not a real admin-command handbook. Current launch-week coverage of admin commands consistently circles back to the same answer: the live build is a JSON-and-hosting workflow, not a mature console-command server-management workflow. If you are looking for rust-style admin powers, assume they are limited or undocumented until the developers publish otherwise.

Good Habits for Live Worlds

• Back up your world before moving it, renaming folders, or updating the server build.

• Keep one note with your world folder ID, invite code, password, and preset details so you can rebuild quickly after a bad patch or host move.

• Do not rename world folders. The official guide warns that the world database depends on those IDs.

• If performance matters more than maximum population, follow the guide's smoother-play recommendation and keep the world closer to 4 active players.

Launch-Week Connectivity and Known Limitations

The April 14, 2026 Early Access launch stressed Kraken Express's live services, and the pain points around dedicated server hosting are worth calling out separately from the broader multiplayer connectivity story. Self-hosted and rented servers remained technically functional, but two specific issues affected hosts during the launch window.

Access Token Generation Cooldown (Fixed in Hotfix 0.10.0.1.6)

Dedicated server hosts reported that access token generation was gated by a cooldown timer that compounded with the launch-window backend load. When the cooldown expired mid-session or during a restart, servers could temporarily refuse new joins until the next regeneration window.

Hotfix 0.10.0.1.6 disabled the access token generation cooldown for dedicated servers entirely. Hosts who ran into token-related failures in the first three days should no longer see them after updating the dedicated server build to match the patch. If the issue persists, the most common remaining cause is a client/server version mismatch, which the same hotfix also surfaces through an explicit UI error.

Port Forwarding is Not a Standard Option

Hosts coming from other survival games have flagged a setup limitation with the launch build: the current dedicated server path does not offer a standard way to connect clients through a specific forwarded port. The official server settings schema does expose a P2pProxyAddress socket field, but the official guide describes the networking layer as NAT punch-through with dynamically assigned ports rather than a fixed, user-chosen forwarded port.

That design works well for most home-hosted groups with UPnP-capable routers, but it removes a knob that hosts with restrictive firewalls or traffic-shaping policies rely on elsewhere. This was widely flagged in launch-week coverage as a concrete area where Kraken Express has room to expand dedicated-server tooling. The studio has said more connectivity fixes are in testing, but no timeline has been published for opt-in fixed-port hosting.

Until that lands, self-hosted groups behind strict NAT should verify UPnP is enabled on the router, temporarily disable VPN or proxy software when testing connectivity (per the official troubleshooting notes), and keep the dedicated server build matched to the current game client version after every patch.

See Also

• Server Settings - the JSON fields and custom world parameters

• Save File Location - exact world paths for client and dedicated server saves

• Multiplayer - co-op structure, world behavior, and official player-cap wording

• Offline Mode - when a local solo world is the simpler option

Dedicated Server Hardware Requirements

The dedicated server build is significantly lighter than the game client, but it still needs dedicated RAM, CPU time, and a fast disk to stay stable. The table below lists the hardware tiers the developers recommend per player count. CPU is a 2-core, 3.2 GHz baseline (Intel Xeon Scalable class). SSD storage is 35 GB at all tiers.

If you are running the game client and the dedicated server on the same physical machine, budget at least 24 GB of total RAM (16 GB for the client, 8 GB or more for the background server). Anything less leaves both processes fighting for headroom and usually causes stutter on the client side during island streaming.

Do Not Launch From the Client's Server Folder

A WindroseServer folder exists inside the main game install, but it is not a second, equivalent entry point. The game client actively shuts down any server process started from that folder to prevent memory conflicts and corrupted saves. Always run the dedicated server from the separate Steam Tools install (or a SteamCMD install in its own directory), never from the client's bundled copy.

Simple Launch with StartServerForeground

The fastest way to get the server online without touching any config files is the foreground launcher. From the dedicated-server install directory, run StartServerForeground.bat (the double-click entry point). A command-line window opens and prints the live server log, which includes the short invite code the first players need to connect.

• Leave the foreground window open; closing it stops the server.

• If the invite code scrolls past too fast to copy, open the R5 folder in the server install and read InviteCode from ServerDescription.json instead. The field matches the code printed in the log.

• Paste the invite code into the Connect to Server screen in the game client and share it with the group.

Migrating a Local World to a Dedicated Server

The most common hosting transition is moving an existing co-op world off of one player's machine onto a dedicated server so the group stops waiting for a specific host. Shut down both the game and the server before moving any files, and back the world up first. One wrong paste can invalidate the save entirely.

1. Locate the Source World

On the original host's PC, paste this path into the file browser address bar: %USERPROFILE%/AppData/Local/R5/Saved/SaveProfiles/. Inside that directory, open the folder named after the host's Steam ID, then RocksDB, then the current game version folder, then Worlds. The alphanumeric folder inside Worlds is the world itself. Copy the entire folder. See

Save File Location for the full path reference on both client and server.

2. Paste Into the Server

On the dedicated-server machine, navigate to the dedicated-server install directory, then R5/Saved/SaveProfiles/Default/RocksDB/<game version>/Worlds/. Paste the copied world folder there. Keep the folder name exactly as it was on the source machine; do not rename it.

3. Point the Server at the Copied World

Open ServerDescription.json in the server root, set WorldIslandId to the exact folder name you just pasted (no surrounding slashes, no extra spaces), save the file, and launch the server. The copied world loads on the next server boot with all existing progress intact.

After a successful migration, plan to update the dedicated server build alongside every game patch. A version mismatch between client and server is the single most common reason a previously working world stops accepting connections after an update.

EGS and Stove Server Files

Players who installed Windrose through Epic Games Store or Stove do not get the dedicated server as a separate download. The server binary ships bundled inside the main Windrose install, and it cannot run from inside that install folder because the game client will try to shut the server process down to avoid memory conflicts and save corruption. The fix on EGS and Stove is to copy the server folder out of the main install first, then treat the copied folder as the standalone dedicated server install from then on.

• Open the main Windrose game installation folder on the host PC.

• Navigate to R5\Builds. Inside you will see a folder named either WindroseServer or WindowsServer depending on the client build.

• Copy that entire folder to a separate location on the PC, for example C:\Game_Servers\Windrose_Server. Do not try to launch the server in place from inside the main game directory.

• From the copied folder, continue with either the simple launch flow (StartServerForeground.bat) or the advanced config-file flow. Both work identically to the Steam Tools install once the folder has been moved.

Steam users do not need this step. On Steam the dedicated server is a separate free entry under the Tools filter in the Steam Library, and right-clicking it and choosing Manage then Browse Local Files opens a standalone server folder that already lives outside the main game install.

WorldDescription.json Fields

Each world folder on a dedicated server includes its own WorldDescription.json file. The path is R5/Saved/SaveProfiles/Default/RocksDB/<game version>/Worlds/<world id>/WorldDescription.json, and the <world id> portion of the path must match the IslandId field inside the file as well as the WorldIslandId set in ServerDescription.json. A server can host multiple worlds by creating multiple folders under Worlds, each with its own WorldDescription.json, and pointing the active WorldIslandId at whichever world the server should load on its next boot.

Edit WorldDescription.json only while the server is fully shut down. The server creates a default version of the file on first launch, and startup issues can cause manually edited fields to be reset or overwritten. Do not rename a world folder to change its ID: the server database relies on the generated folder name, and renaming can prevent the world from loading.

Updating the Dedicated Server After a Game Patch

A dedicated server that falls behind the client build will stop accepting joins after a patch. Hotfix 0.10.0.1.6 and later surface an explicit version-mismatch error in the client UI, but the underlying fix is the same: bring the dedicated server up to the current client build. The procedure depends on how the server was originally installed.

Steam or SteamCMD Installs

Steam Tools handles dedicated server updates automatically the next time the Steam client runs. For SteamCMD installs, rerun the same commands that were used for the initial install: force_install_dir to the existing server directory, login anonymous, then app_update 4129620 validate. Only changed files are downloaded, and the existing R5\Saved folder is left intact.

EGS and Stove Installs

Because the dedicated server files ship inside the main game install on EGS and Stove, the server does not update on its own when those storefronts patch the game client. The running dedicated server keeps serving the old build until the host manually copies the new files out. The update procedure is:

• Install the latest game client update through EGS or Stove as normal.

• Open the updated main Windrose game directory and go to R5\Builds. Copy the new WindroseServer or WindowsServer folder to a new location (for example a new sibling folder next to the old server install).

• Copy the old dedicated server's entire R5\Saved folder into the new server install. This is the world data and ServerDescription.json settings. Without this step the new server boots as a blank install with no worlds.

• Retire the old server folder (rename, archive, or leave it in place untouched as a rollback option).

• Launch the new server normally. The server version now matches the client version, and existing worlds, invite codes, and settings carry over intact.

Back up the R5\Saved folder to a separate drive before starting any update. A failed copy during an update is one of the few ways to lose world progress, and the save folder is small enough that keeping a snapshot per patch is cheap.

Startup and Crash Troubleshooting Checklist

If the dedicated server refuses to launch or crashes immediately after StartServerForeground.bat opens a console window, the problem is usually in the host environment rather than in the server files themselves. Work through the list below in order before assuming the server build is broken.

• Verify Steam server files: for Steam Tools installs, right-click Windrose Dedicated Server in the Steam Library, open Properties, switch to Installed Files, and choose Verify integrity of server files. A bad download or an interrupted update can leave the server folder with missing or corrupt binaries.

• Update GPU and system drivers: the dedicated server does not render frames, but the Windrose server build still links against core graphics and system libraries on Windows. Driver installs have fixed a number of early launch failures.

• Install pending Windows updates: Visual C++ runtime and kernel patches delivered through Windows Update are required for the server build to start cleanly.

• Add a firewall or antivirus exception for WindroseServer.exe: aggressive heuristic scanning sometimes quarantines the server executable or the process it spawns on first launch, which looks like an instant crash from the user's side.

• Restart the host PC and router: a full restart clears stale network sockets from the previous launch, refreshes UPnP leases, and resets any driver state that picked up the earlier updates.

If the server starts but clients cannot see it, the issue is almost always networking rather than startup. Check UPnP on the router, disable VPN or proxy software temporarily, and confirm the client build matches the server build exactly before troubleshooting further.

RAM Scaling by Lobby Size

The Windrose dedicated server scales memory usage with active player count. The studio's own hosting documentation treats lobby size as the primary knob when sizing the host machine:

Storage, CPU, and OS: 35 GB of free space on an SSD or NVMe SSD is the recommended disk setup regardless of player count. The CPU baseline is a modern 64-bit quad-core with strong single-thread performance. Supported operating systems are Windows 10, Windows 11, and any Windows Server edition released alongside them, all 64-bit. The latest Visual C++ Redistributables are a prerequisite that is not bundled with the server app, so install them separately before the first launch.

Server Files Reference

Networking: the server uses dynamic networking via NAT punch-through and UPnP, so routers that support UPnP configure themselves without manual port forwarding. If home routers block UPnP (common on business or enterprise gateways), port-forward the Windrose server port explicitly or enable UPnP in router settings before launching. Editing ServerDescription.json or WorldDescription.json while the server is running is not supported and usually results in a crash at next save; always stop the server first before touching those files.

Practical Player Cap

The server technically scales to ten players, but the current launch-window performance profile makes four-player lobbies the recommended sweet spot. Pushing past four players sees a noticeable increase in memory pressure and rubber-banding, and ten-player lobbies have been reported to crash when all players are active in different biomes simultaneously. Treat four as the production-ready cap and ten as the edge case until a later patch stabilizes the higher counts.

WorldSettings Custom Parameters Reference

When WorldPresetType is set to anything other than Easy, Medium, or Hard, the server reads the WorldSettings block in WorldDescription.json for per-parameter custom values. Touching any single field inside WorldSettings flips the preset to Custom on the next launch even if you intended to nudge a single multiplier; this is the launch behaviour the server build documents and is not a bug. The full list of fields and their accepted ranges is below. Decimal multipliers accept floats, the difficulty tag accepts only the three named strings, and the coop modifier fields take a multiplier rather than a flat addition.

Default-vs-zero asymmetry on the coop ship modifier. The default value for Coop_ShipStatsCorrectionModifier is 0.0 rather than 1.0, which makes it the only WorldSettings field where the in-game default is the lowest end of the accepted range rather than the centre. Leaving the field at its default keeps enemy ship health unchanged regardless of player count; raising it scales enemy ship hulls upward as more players join. Most groups leave it untouched on launch and only adjust if four-player ship combat starts feeling trivial.

Editing safety. Stop the server fully before editing WorldSettings (or any other WorldDescription.json or ServerDescription.json field). The server creates the file on first boot and rewrites several values during shutdown, so an edit applied while the process is running will either be discarded on the next save or, in worse cases, corrupt the world state. Back the world folder up before any custom-difficulty experiment so a bad combination can be rolled back without re-running migration steps.

Difficulty as a separate axis from the multipliers. CombatDifficulty controls boss aggression and general enemy aggression independently of the numeric multipliers. Setting Mob and Ship multipliers low while leaving CombatDifficulty on Hard produces noticeably different play feel from doing the inverse: the first scenario keeps fights short but punishing, while the second drags out fights against more cautious enemies. Most groups treat CombatDifficulty as the "feel" knob and the multipliers as the "scale" knobs.

Renting a Server From a Hosting Provider

Self-hosting is not the only option. Several commercial game-server providers rent Windrose dedicated servers as a monthly service, which trades a recurring cost for managed uptime, automatic backups, and a control panel instead of hand-edited JSON files. Renting is the fastest path to a persistent world for friend groups who do not want to keep a home PC running, but the same Early Access quirks still apply, and a provider advertised slot count should never be treated as a higher official limit than the up-to-8 cap on the store page or the four-player smooth-performance recommendation in the official guide.

Factors to Consider

1. Location: Server geographical location affects latency. Pick a region close to where most of your group plays.

2. Scalability: As a group grows it may need more player slots or resources. Confirm the provider lets you upgrade without rebuilding the world.

3. Support: Responsive support matters most for anyone new to server management, especially during the patch-heavy Early Access window.

4. Price: Providers usually bill per player slot per month. The cheapest plan is not always the most stable; balance cost against performance and uptime.

5. Backup and security: Regular automated backups and solid account security protect world data. A provider that snapshots the world before each patch saves a lot of grief after a bad update.

Providers that rent Windrose servers include vendors such as Nitrado, among others. Prices and supported regions change frequently, so confirm the current player-slot pricing and the nearest server region directly with the provider before committing. Whichever route you take, the authoritative setup and troubleshooting information still comes from Kraken Express rather than from any host control panel.