Notatki operatora

Serwer Valheim: dedykowany serwer krok po kroku

Od SteamCMD do działającego świata: którą aplikację pobrać, które porty otworzyć, jakie parametry naprawdę mają znaczenie, gdzie leżą pliki świata i dlaczego twoja konfiguracja znika po każdej aktualizacji. Bez listy dziesięciu hostingów na końcu.

Opublikowano 8 sierpnia 2026 · ~9 min czytania

Czego właściwie potrzebujesz

Dedykowany serwer Valheim to osobny program, nie tryb w grze. Klient gry i serwer to dwie różne pozycje w Steamie: gra ma swoje ID, a Valheim Dedicated Server ma ID 896660. To rozróżnienie jest ważne, bo większość problemów początkujących sprowadza się do tego, że ktoś próbuje odpalić serwer z katalogu gry.

Sprzętowo Valheim jest łagodny na start i wymagający później. Świat rośnie razem z tym, ile go zwiedziliście, i to on, a nie liczba graczy, zjada pamięć. Na czwórkę znajomych na świeżym świecie wystarczą 2 GB RAM przypisane serwerowi. Po kilkuset godzinach eksploracji, z rozbudowanymi bazami i kilkoma portalami, ten sam świat potrafi potrzebować 4 GB i więcej. Procesor liczy się wydajnością jednego rdzenia: Valheim słabo skaluje się na wiele wątków, więc szybszy zegar da więcej niż dodatkowe rdzenie. Więcej o doborze podzespołów jest w notatkach o sprzęcie pod serwer gry.

Instalacja przez SteamCMD

SteamCMD to konsolowy klient Steama i standardowy sposób pobierania plików serwera. Na Linuksie założ osobnego użytkownika systemowego dla serwera i nigdy nie uruchamiaj go z konta root. Potem pobierasz aplikację 896660 do wybranego katalogu.

Instalacja anonimowa działa, bo pliki serwera Valheim są publiczne: nie musisz podawać danych swojego konta Steam ani mieć gry kupionej na tym koncie. Po pobraniu w katalogu znajdziesz skrypty startowe, start_server.sh na Linuksie albo start_server.bat na Windowsie. Nie edytuj ich w miejscu. Zrób kopię i uruchamiaj kopię, bo każda aktualizacja serwera nadpisuje oryginalne skrypty, a twoja konfiguracja wyparuje razem z nimi.

Parametry uruchomienia, które mają znaczenie

Serwer konfiguruje się argumentami wiersza poleceń, nie plikiem konfiguracyjnym. Cztery są obowiązkowe albo praktycznie obowiązkowe:

• -name: nazwa widoczna na liście serwerów. Nie może zawierać hasła.
• -port: port bazowy, domyślnie 2456.
• -world: nazwa świata. To ona decyduje, który plik świata zostanie wczytany albo utworzony.
• -password: hasło, minimum 5 znaków. Nie może być częścią nazwy serwera ani nazwy świata, a serwer po prostu odmówi startu, jeśli tę zasadę złamiesz.

Do tego dochodzi -crossplay, który włącza dołączanie przez kod zaproszenia i graczy z konsol. Warto wiedzieć, że to nie jest darmowy dodatek: crossplay przepuszcza ruch przez zewnętrzną infrastrukturę relayową, która ma własne awarie. Rozpisałem to osobno w tekście o tym, dlaczego serwer Valheim przestaje działać przy problemach z crossplayem.

Porty i zapora

Valheim używa portu, który podasz, oraz kolejnych nad nim. W praktyce przepuszczasz 2456, 2457 i 2458 na protokole UDP. Port 2456 obsługuje grę, a 2457 zapytania o status, dzięki którym serwer w ogóle pokazuje się na liście. To najczęstsza przyczyna sytuacji, w której serwer chodzi, w logach nie ma błędów, a nikt nie może wejść: ruch nie dochodzi do maszyny. Jeśli stawiasz serwer u siebie w domu, przekierowanie portów na routerze jest obowiązkowe i opisałem je krok po kroku w poradniku o port forwardingu.

Na maszynie w chmurze pamiętaj o dwóch warstwach zapory: tej w systemie i tej po stronie dostawcy. Otwarcie portu tylko w jednej z nich to klasyk, który kosztuje godzinę szukania.

Gdzie są pliki świata

To pytanie wraca zawsze, kiedy trzeba zrobić kopię albo przenieść świat na inną maszynę. Na Linuksie dane serwera leżą w katalogu domowym użytkownika, który go uruchamia, pod .config/unity3d/IronGate/Valheim/. Świat to para plików: .db z zawartością świata i .fwl z metadanymi oraz ziarnem generacji. Kopiujesz zawsze oba, bo sam .db bez .fwl jest bezużyteczny. Zajrzyj do podkatalogów ze światami, bo zależnie od wersji i sposobu uruchomienia serwer trzyma je w worlds_local albo worlds.

W tym samym katalogu znajdziesz pliki uprawnień: adminlist.txt, bannedlist.txt i permittedlist.txt. Wpisujesz do nich Steam ID gracza, jeden na linię. Zmiany działają bez restartu, ale gracz musi się przelogować, żeby serwer zauważył nowe uprawnienia.

Kopie zapasowe, zanim będą potrzebne

Serwer Valheim sam robi kopie świata, ale trzyma je obok oryginału. To zabezpiecza przed uszkodzonym zapisem, nie przed awarią dysku i nie przed pomyłką administratora. Reguła jest prosta: kopia, która leży na tej samej maszynie co świat, nie jest kopią zapasową.

Osobno ważny moment: przed każdą aktualizacją gry. Valheim aktualizuje klientów przez Steama w ciągu minut, a serwery dopiero wtedy, kiedy ich operator się tym zajmie. W tej luce nikt się nie połączy, a jeśli aktualizacja zmienia format świata, powrót na starszą wersję bez kopii nie jest możliwy. Przed 9 września 2026, kiedy wychodzi Valheim 1.0, ten punkt jest szczególnie istotny i rozpisałem go w notatkach o przygotowaniu serwera na 1.0 i Deep North.

Własna maszyna czy hosting

Własny sprzęt ma sens, jeśli masz komputer, który i tak chodzi całą dobę, i nie przeszkadza ci patchowanie go w dniu aktualizacji. Wychodzi taniej i masz pełną kontrolę nad plikami.

Hosting kupujesz wtedy, gdy nie chcesz być osobą, do której cała drużyna pisze w dniu patcha, i gdy zależy ci, żeby świat trwał, kiedy wszyscy są offline. Różnice po kolei rozpisałem w tekście o własnym hostingu kontra usłudze zarządzanej. Jeśli szukasz gotowego serwera Valheim z panelem, aktualizacjami i kopiami zapasowymi, znajdziesz go w ofercie Supercraft.

Najczęstsze błędy na start

1. Serwer nie pokazuje się na liście. Świeżo uruchomiony serwer potrzebuje kilku minut, zanim pojawi się w przeglądarce serwerów. Jeśli po kwadransie go nie ma, sprawdź port 2457 i zaporę, nie logi.
2. Hasło odrzucone przy starcie. Krótsze niż 5 znaków albo zawarte w nazwie serwera lub świata. Serwer nie wystartuje i napisze to w logu.
3. Niezgodna wersja. Klient zaktualizował się sam, serwer nie. Trzeba pobrać aplikację 896660 ponownie.
4. Skrypt startowy wrócił do domyślnych wartości. Edytowałeś oryginalny start_server.sh, a aktualizacja go nadpisała. Uruchamiaj kopię.
5. Uruchamianie z konta root. Działa, ale zostawia pliki świata z właścicielem root i później nie da się ich odczytać ze zwykłego konta. Założ osobnego użytkownika od razu.