Windrose dedicated server setup guide (2026)

Windrose dropped into Early Access on April 14, 2026 — a pirate-age survival sandbox where 2–10 player crews build, craft, sail and fight. Joom Capital shipped a free, anonymous-downloadable dedicated server tool on day one (Steam app id 4129620), which means you don't need a game licence on the host machine. That's the easy part. The interesting bits — NAT punch-through, sizing, save migration — trip up most first-time operators. Here's the version we'd hand a friend.

The 60-second setup (managed hosting)

If you rent from a Pterodactyl-based host, the loop is short:

1. Pick a Windrose tier and a region.
2. Wait ~2 minutes for the SteamCMD install to validate ~6 GB of files.
3. Open the in-game server browser, paste the IP:Port your panel shows, join.
4. Invite your crew via the in-game invite flow (NAT punch-through handles port mapping for them).

If you rent from us, that's literally the whole flow. Stop reading here if that covers you.

The rest of this post is for people who self-host on a VPS or who want to understand what their managed host is doing under the hood.

Self-host: SteamCMD install

On a fresh Debian or Ubuntu LTS box with 16+ GB RAM:

# Install SteamCMD dependencies
sudo apt update
sudo apt install -y curl tar lib32gcc-s1 lib32stdc++6

# Pull SteamCMD
mkdir -p ~/steamcmd && cd ~/steamcmd
curl -sqL "https://steamcdn-a.akamaihd.net/client/installer/steamcmd_linux.tar.gz" | tar zxf -

# Install Windrose dedicated server (anonymous login)
./steamcmd.sh +force_install_dir ~/windrose-server \
  +login anonymous \
  +app_update 4129620 validate \
  +quit

App id 4129620 is the server-only SKU. It's free to download — no Windrose game licence required on the host.

The Linux SteamCMD pulls the Windows server binary because Joom Capital hasn't shipped a native Linux build yet. To run it, you wrap with Proton:

cd ~/windrose-server
proton run ./WindroseServer.exe \
  -name "Your crew name" \
  -maxplayers 8 \
  -port 27015

If you don't have Proton already, the ghcr.io/parkervcp/steamcmd:proton container image bundles it. That's the same image we use in our Pterodactyl egg.

The NAT punch-through quirk

Windrose handles client connections via NAT punch-through — when a player tries to join, the dedicated server and the client briefly negotiate through Joom Capital's matchmaking layer, and then the connection becomes peer-to-peer with the server. This is great for end users (no port forwarding) but it has consequences for ops:

Your firewall still needs the server port open. The punch-through layer is for client discovery; the actual game traffic flows on the server port you configured (27015 by default). If your VPS firewall blocks UDP 27015, the dedicated server can't accept the negotiated connection. Open the port in ufw or your provider's firewall.

Don't expect a "real" public IP:Port string to work from outside. If your friend tries to direct-connect via raw IP, they may or may not get through depending on their NAT setup. The reliable path is the in-game server browser, which uses the punch-through layer.

No ARP-style discovery on LAN. If you're testing locally, your LAN clients need the server's actual LAN IP, not the public one — the punch-through layer can confuse local connections.

Sizing — be honest about RAM

Joom Capital's official guidance is 8 GB minimum for a small crew. In practice:

Crew size	RAM	What you'll feel below this
2 players (duo)	8 GB	Workable, but world streaming feels chunky
3–4 players	12 GB	Stutters when one player sails far from the others
5–8 players	16 GB	Hard limit; below this you'll OOM during ship combat
8–10 (EA cap)	24 GB	Same plus headroom for the host OS

Why so much for a small player count? Two things drive RAM use in Windrose. First, the world is large and persistently streamed in tiles — even with a small crew, sailing means new tiles loading constantly. Second, ship physics (sails, masts, cannon, damage states) run a non-trivial body simulation per ship. A 4-player crew with two boats sails through more memory than a 4-player crew in any other survival game we host.

Migrating a save from another host

Windrose stores world state as files in the server directory — same pattern as most survival games. The migration is:

1. On the old host: stop the server. Find the save directory (usually ~/windrose-server/Saves/<world-name>/).
2. Pull via FTP/SFTP. Drag the whole save folder to your local machine. Pack it as .zip for upload speed.
3. On the new host: stop the new server. Upload to the same path via SFTP (your panel will show the right location).
4. Restart. The server boots into your existing world.

If the new host runs a newer Windrose build, the server validates and migrates the save schema on boot. EA migrations are usually clean, but back up before the first boot just in case.

Common pitfalls

SteamCMD validates 6 GB of files on every restart. That's intentional — +app_update ... validate is what catches corrupted files after a Steam-side patch. But on a small VPS it can feel slow. If you're confident the install is clean, you can swap validate for nocheck in your install script. We don't recommend this for production — the 30-second validate is cheap insurance against a half-patched server segfaulting on boot.

Setting -maxplayers higher than 10. Even if the binary accepts the flag, Joom Capital hasn't tested past 10 in EA. Ship physics and the punch-through layer start misbehaving. Stay at 10 or lower until they raise the official cap.

Running the server alongside a graphical desktop. If you self-host on your gaming PC and Windrose-the-game-client is running, the dedicated server contests for ports and you'll see binding errors. Either use a dedicated VPS, or shut the client before launching the server.

Forgetting daily backups. Windrose ship state is fragile. A bad-luck server crash mid-sail can put your crew's flagship into an inconsistent state. Schedule daily snapshots — every panel we know about (Pterodactyl included) supports cron-driven save backups. Set it to run once a day at low-activity hours.

When to upgrade

Three signals.

• Sustained 80%+ memory use in your panel's resource graph. Your crew has outgrown the tier.
• Stutter when multiple ships are simulated nearby. Usually CPU-bound rather than RAM-bound, but on a 12-GB tier with 4 players it can be either. Upgrade RAM first, then complain to your host if it doesn't help.
• Restart-time validation runs slower than 60 seconds. Disk pressure, fragmentation, or your host running you on a noisy neighbour's NVMe. Time to move providers if your current one is suspect.

That's the realistic version. Windrose is a great EA survival game; treat its server like you would any other AAA-survival dedicated, give it the RAM it actually needs, and back up.