Windrose's dedicated server is Windows-only. Kraken Express hasn't released a Linux build and hasn't announced plans to. That's a problem if you're running a Linux-first home lab or want to host Windrose alongside your Minecraft, Valheim, and Factorio servers on the same Ubuntu box.
The community's answer: run the Windows binary under Wine, inside a Docker container. It works – mostly. Let me walk through what you're actually signing up for.
The Community Docker Image
The de facto community option is indifferentbroccoli/windrose-server-docker on GitHub. It wraps the Windrose server in a Docker container with Wine and SteamCMD pre-configured. You pull the image, mount a persistent data volume, expose UDP 7777/7778, and start it up.
This is unofficial. Not endorsed by Kraken Express, not guaranteed to work after every game update, not a supported path. But the maintainer has been keeping it current through several Windrose patches, and it's the best option going for Linux hosts.
Basic setup looks something like:
services:
windrose:
image: indifferentbroccoli/windrose-server-docker:latest
restart: unless-stopped
ports:
- "7777:7777/udp"
- "7778:7778/udp"
volumes:
- ./data:/server/R5/Saved
Check the repo's README for current config options – things change and I don't want to document something that'll be wrong in two weeks.
The IPv6 Crashloop
Here's the gotcha that's caught enough people that it deserves top billing. If your Linux host was booted with ipv6.disable=1 in its kernel parameters (common on older server builds, some cloud VMs, or if you've followed "harden your Linux box" guides), the Windrose server will crashloop. The error you'll see is something like "data inconsistent" or SetDataInconsistent, and it's maddeningly unhelpful.
The root cause: Windrose embeds a small gRPC-based P2P-proxy that listens on a dual-stack IPv4/IPv6 socket. When IPv6 is completely disabled at the kernel level, the socket creation fails, and the server fails in a way that gets misreported as a data consistency issue. It's a SetDataInconsistent error for the proxy's state database, not for your save data.
The fix: re-enable IPv6, or at least don't fully disable it at kernel boot. Edit /etc/default/grub and remove ipv6.disable=1 from GRUB_CMDLINE_LINUX_DEFAULT, then run sudo update-grub and reboot. You can still disable IPv6 on specific interfaces via sysctl if you want – you just can't nuke it at the kernel level.
This issue is tracked in indifferentbroccoli/windrose-server-docker#3 if you want more detail or want to follow any fixes.
Performance Expectations
Wine adds overhead. How much depends on your host, but for a Windrose server expect roughly 10-20% more CPU usage than running the same thing on bare-metal Windows. RAM usage is similar to native (Wine doesn't really inflate that). If you're sizing for a full 10-player server, give the container at least 14 GB of RAM to leave headroom.
Late-game performance is also slightly worse than native Windows. The UE5 engine doesn't love running in Wine, and certain simulation-heavy moments (big combat, lots of loaded chunks) will show more frame-timing variance. Nothing game-breaking, but noticeable if you're comparing side-by-side.
When This Makes Sense (and When It Doesn't)
Makes sense if you:
- Have a Linux server you want to consolidate game servers onto
- Are running this for a small group of friends who can tolerate some jank
- Are comfortable debugging Docker + Wine issues yourself
- Want to experiment with non-standard hosting setups
Doesn't make sense if you:
- Need production-grade reliability
- Are running a public community server
- Don't want to mess with IPv6 kernel flags, Docker volume permissions, and Wine debugging
- Just want it to work
For the "just want it to work" crowd: our Windrose hosting plans run on actual Windows hardware with all this stuff handled. No Wine, no Docker volume weirdness, no IPv6 surprises.
Updating the Server
SteamCMD updates work through the container. The exact command depends on how the image is configured, but typically you'll either restart the container (it pulls the latest on boot) or exec in and run steamcmd +login anonymous +app_update 3041230 validate +quit manually.
Expect updates to sometimes break the container. When Kraken Express ships a game patch, there's a short window where the existing container image might not work properly until the maintainer pushes an updated version. Check the GitHub issues if something breaks after a game patch.
File Permissions
If you're passing through a host-side directory as /server/R5/Saved, make sure the host-side permissions allow the container's Wine user to read and write. The default on most Docker setups works fine, but if you're running rootless Docker or using unusual filesystems (ZFS datasets with odd permission flags, for example), you might see the server fail to save the world. The symptom is usually "server starts fine but loses world state on restart."
Quick fix if you hit this: chown -R 1000:1000 ./data on the host, then restart the container.
The Reality Check
This is genuinely a bit of a mess. It works, people are running Windrose servers on Linux this way, and the Docker image maintainer is doing good work. But it's unofficial and fragile compared to native Windows hosting. If your goal is reliability over ideological consistency, running Windrose on Windows (self-hosted or via LOW.MS) is meaningfully less painful. If your goal is "make it fit on my Linux rig," this path works.
For other Windrose server issues, the troubleshooting guide covers the common stuff, and the requirements article has more detail on what the server actually needs to run.