Windrose Dedicated Server einrichten: Setup-Guide 2026

Windrose ist am 14. April 2026 in Early Access gestartet — ein Piraten-Zeit-Survival-Sandbox, in dem 2–10 Spieler-Crews bauen, craften, segeln und kämpfen. Joom Capital hat am ersten Tag ein kostenloses, anonym herunterladbares Dedicated-Server-Tool geliefert (Steam-App-ID 4129620). Heißt: du brauchst keine Spiel-Lizenz auf dem Host. Das ist der einfache Teil. Die spannenden Sachen — NAT-Punch-Through, Sizing, Save-Migration — werfen die meisten Erst-Operator aus der Bahn. Hier die Version, die wir einem Freund geben würden.

Der 60-Sekunden-Weg (Managed Hosting)

Wenn du bei einem Pterodactyl-basierten Hoster mietest, ist der Loop kurz:

1. Windrose-Tier und Region wählen.
2. ~2 Minuten warten, bis SteamCMD ~6 GB Files validiert hat.
3. Im Spiel-Server-Browser die IP:Port aus deinem Panel einfügen, beitreten.
4. Crew via In-Game-Invite-Flow einladen (NAT-Punch-Through erledigt das Port-Mapping für sie).

Wenn du bei uns mietest, war das der ganze Flow. Bis hier reicht's, wenn das dein Use-Case ist.

Der Rest des Posts ist für Leute, die selbst auf einem VPS hosten, oder die verstehen wollen, was ihr Managed-Hoster unter der Haube tut.

Self-Host: SteamCMD-Install

Auf einer frischen Debian- oder Ubuntu-LTS-Box mit 16+ GB RAM:

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

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

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

App-ID 4129620 ist die Server-only-SKU. Kostenlos herunterladbar — keine Windrose-Spiel-Lizenz auf dem Host nötig.

Das Linux-SteamCMD zieht die Windows-Server-Binary, weil Joom Capital noch keinen nativen Linux-Build liefert. Zum Ausführen wickelst du sie in Proton:

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

Falls du Proton noch nicht hast: das Container-Image ghcr.io/parkervcp/steamcmd:proton bringt es mit. Genau dieses Image nutzen wir in unserem Pterodactyl-Egg.

Die NAT-Punch-Through-Eigenheit

Windrose handelt Client-Verbindungen via NAT-Punch-Through ab — wenn ein Spieler joinen will, verhandeln Dedicated Server und Client kurz über Joom Capitals Matchmaking-Layer, und dann läuft die Verbindung peer-to-peer mit dem Server. Für Endnutzer großartig (kein Port-Forwarding), aber für Ops hat das Konsequenzen:

Deine Firewall braucht trotzdem den offenen Server-Port. Der Punch-Through-Layer dient der Client-Discovery; der eigentliche Game-Traffic läuft auf dem von dir konfigurierten Server-Port (27015 default). Wenn deine VPS-Firewall UDP 27015 blockt, kann der Dedicated Server die verhandelte Verbindung nicht annehmen. Port in ufw oder beim Provider freigeben.

Erwarte keinen "echten" Public-IP:Port-String, der von außen funktioniert. Wenn dein Freund direkt mit roher IP joinen will, klappt das je nach seinem NAT-Setup mal so, mal so. Der zuverlässige Weg ist der In-Game-Server-Browser, der nutzt den Punch-Through-Layer.

Keine ARP-Discovery im LAN. Wenn du lokal testest, brauchen deine LAN-Clients die echte LAN-IP des Servers, nicht die Public — der Punch-Through-Layer kann lokale Verbindungen verwirren.

Sizing — sei ehrlich beim RAM

Joom Capitals offizielle Empfehlung ist 8 GB Minimum für eine kleine Crew. In der Praxis:

Crew	RAM	Was du darunter spürst
2 Spieler (Duo)	8 GB	Funktioniert, aber Welt-Streaming wirkt hakelig
3–4 Spieler	12 GB	Stutter, wenn jemand weit von den anderen wegsegelt
5–8 Spieler	16 GB	Harte Untergrenze; darunter OOM bei Schiffs-Kampf
8–10 (EA-Cap)	24 GB	Plus Headroom fürs Host-OS

Warum so viel für kleine Spielerzahlen? Zwei Treiber. Erstens: Die Welt ist groß und wird persistent in Tiles gestreamt — auch bei kleiner Crew heißt Segeln ständig neue Tiles laden. Zweitens: Schiffs-Physik (Segel, Masten, Kanonen, Schadens-States) ist eine nicht-triviale Body-Simulation pro Schiff. Eine 4er-Crew mit zwei Booten segelt durch mehr Speicher als jede andere Survival-Crew, die wir hosten.

Save von einem anderen Hoster migrieren

Windrose speichert Welt-State als Files im Server-Verzeichnis — gleiches Muster wie die meisten Survival-Games. Migration so:

1. Beim alten Hoster: Server stoppen. Save-Verzeichnis finden (üblich ~/windrose-server/Saves/<welt-name>/).
2. Via FTP/SFTP ziehen. Den ganzen Save-Ordner auf den lokalen Rechner ziehen. Als .zip packen für Upload-Speed.
3. Beim neuen Hoster: Neuen Server stoppen. Über SFTP an dieselbe Stelle uploaden (dein Panel zeigt den richtigen Pfad).
4. Restart. Server bootet in deine bestehende Welt.

Wenn der neue Hoster einen neueren Windrose-Build fährt, validiert und migriert der Server beim Boot das Save-Schema. EA-Migrationen sind meist sauber, aber vor dem ersten Boot Backup ziehen — schadet nie.

Häufige Stolperfallen

SteamCMD validiert bei jedem Restart 6 GB Files. Absicht — +app_update ... validate fängt korrupte Files nach einem Steam-seitigen Patch. Auf einer kleinen VPS fühlt sich das aber zäh an. Wenn du sicher bist, dass der Install sauber ist, kannst du validate durch nocheck im Install-Script ersetzen. Empfehlen wir für Production nicht — die 30 Sekunden Validate sind billige Versicherung gegen einen halb-gepatchten Server, der beim Boot segfaultet.

-maxplayers höher als 10. Auch wenn die Binary den Flag akzeptiert: Joom Capital hat in EA nicht über 10 getestet. Schiffs-Physik und Punch-Through-Layer fangen an zu spinnen. Bleib bei 10 oder darunter, bis sie den offiziellen Cap erhöhen.

Server parallel zu einer grafischen Desktop-Session. Wenn du auf deinem Gaming-PC self-hostest und Windrose-the-Client gleichzeitig läuft, beißen sich Client und Server um Ports — Binding-Errors. Entweder dedizierter VPS, oder Client schließen, bevor du den Server startest.

Daily Backups vergessen. Windrose-Schiffs-State ist fragil. Ein Unglücks-Crash mitten im Segeln kann das Flaggschiff deiner Crew in einen inkonsistenten Zustand bringen. Daily Snapshots scheduln — jedes Panel, das wir kennen (Pterodactyl inkl.), kann cron-getriebene Save-Backups. Einmal am Tag zur Low-Activity-Stunde laufen lassen.

Wann upgraden

Drei Signale.

• Anhaltend 80%+ Memory-Use im Resource-Graph deines Panels. Deine Crew ist aus dem Tier rausgewachsen.
• Stutter, wenn mehrere Schiffe nahe beieinander simuliert werden. Meist CPU-bound, nicht RAM-bound, aber auf einer 12-GB-Stufe mit 4 Spielern kann's auch RAM sein. Erst RAM hoch, dann beim Hoster meckern wenn's nicht hilft.
• Restart-Time-Validation läuft langsamer als 60 Sekunden. Disk-Pressure, Fragmentierung, oder ein lauter Nachbar auf deinem NVMe. Wenn der aktuelle Hoster verdächtig wirkt, ist es Zeit für einen Wechsel.

Das ist die realistische Version. Windrose ist ein gutes EA-Survival-Game; behandle den Server wie jeden AAA-Survival-Dedicated, gib ihm das RAM, das er tatsächlich braucht, und mach Backups.