Jellyfin zamiast Plexa: jak zbudować własny serwis streamingowy na komputerze lub NAS-ie, kiedy potrzebne jest transkodowanie i jak oglądać bibliotekę poza domem

Jellyfin ma sens wtedy, gdy chcesz odzyskać kontrolę nad własną biblioteką filmów, seriali i muzyki, a nie tylko zamienić logo jednej aplikacji na drugie. Serwer działa na twoim komputerze lub NAS-ie, pliki zostają na twoich dyskach, a za samo korzystanie z podstawowych funkcji nie płacisz abonamentu. To istotna różnica względem Plexa, który od 2025 roku stopniowo objął zdalne odtwarzanie prywatnego wideo wymogiem Plex Pass albo Remote Watch Pass na obsługiwanych platformach.

Cena tej niezależności jest inna: Jellyfin wymaga od właściciela serwera większej wiedzy o sieci, kodekach i sprzęcie. Źle dobrany NAS potrafi bez problemu udostępniać pliki, a jednocześnie kompletnie polec przy próbie transkodowania filmu 4K HDR. Z kolei komputer z mocnym procesorem może niepotrzebnie zużywać 50–100 W, gdy tę samą pracę wykona mały układ Intela ze sprzętowym Quick Sync. Trzeba więc zacząć nie od wyboru obudowy czy liczby dysków, lecz od odpowiedzi na pytanie: czy materiały będą odtwarzane bez konwersji, czy serwer będzie musiał je transkodować?

Komputer, mini PC czy NAS: sprzęt dobiera się do sposobu oglądania

Jellyfin Server można uruchomić na Windowsie, Linuksie, macOS-ie, w Dockerze i na wielu NAS-ach. W sierpniu 2026 roku aktualną stabilną linią serwera pozostaje Jellyfin 10.11, a wydanie 10.11.11 ukazało się 6 czerwca 2026 roku. Sam projekt zapowiedział zmianę numeracji — po gałęzi 10.11 następna duża wersja ma otrzymać numer 12.

Do prostego domowego serwera nie potrzeba stacji roboczej. Jeśli telewizor, przystawka lub aplikacja potrafią bezpośrednio odtworzyć plik, Jellyfin wykonuje głównie pracę katalogową i sieciową. Procesor nie dekoduje wtedy filmu klatka po klatce.

To Direct Play i jest to scenariusz, do którego warto dążyć.

Przy bibliotece z filmami H.264 lub HEVC, dźwiękiem AAC, AC-3 albo E-AC-3 oraz klientem takim jak Android TV, Apple TV czy współczesny telewizor, nawet dość słaby serwer może działać znakomicie. Wąskim gardłem staje się częściej sieć albo dysk niż CPU.

Do wyboru są trzy sensowne klasy sprzętu:

• istniejący komputer — najtańszy start, bo koszt zakupu wynosi 0 zł; wadą jest pobór energii i konieczność pozostawiania urządzenia włączonego,
• mini PC z Intelem — zwykle około 600–1200 zł za konstrukcję z procesorem klasy Intel N100/N150 albo używany komputer biznesowy z Core i5 8.–10. generacji; to jeden z najlepszych kompromisów dla Jellyfina,
• NAS — około 1200–2500 zł za sensowną obudowę 2–4-zatokową bez dysków, przy czym modele z procesorami ARM lub słabszymi układami x86 trzeba oceniać szczególnie ostrożnie pod kątem transkodowania.

NAS wygrywa wygodą. Dyski, macierze RAID, monitoring SMART, kopie zapasowe i usługi sieciowe są w jednym urządzeniu. Problem zaczyna się wtedy, gdy ktoś kupuje NAS przede wszystkim na podstawie liczby zatok, a dopiero później odkrywa, że jego procesor nie ma odpowiedniego układu graficznego.

Jeżeli Jellyfin ma tylko podawać pliki do klientów, procesor ARM może wystarczyć. Jeśli ma regularnie transkodować wideo, rozsądniej wybierać sprzęt z obsługiwanym iGPU Intela albo odpowiednim GPU AMD czy NVIDIA.

Dla domowego serwera szczególnie praktyczne są procesory Intela z Quick Sync Video. Jellyfin obsługuje QSV na Windowsie i Linuksie, a na Linuksie również VA-API. Intel ma jeszcze jedną zaletę: w typowym serwerze nie trzeba montować osobnej karty graficznej pobierającej kilkadziesiąt watów.

W Dockerze pojawia się dodatkowy szczegół, który często jest pomijany. Sam fakt, że host widzi iGPU, nie oznacza jeszcze, że widzi je kontener. Na Linuksie trzeba przekazać do kontenera odpowiednie urządzenie, zwykle z /dev/dri, i ustawić prawidłowe uprawnienia. Bez tego w panelu Jellyfina można zaznaczyć sprzętową akcelerację, ale FFmpeg i tak zacznie kodować materiał na CPU.

Przy dyskach nie należy również traktować RAID-u jako kopii zapasowej. RAID1 albo RAID5 chroni przede wszystkim przed awarią pojedynczego dysku, nie przed przypadkowym skasowaniem biblioteki, uszkodzeniem systemu plików czy błędem administratora. Filmy można ponownie zgrać z legalnie posiadanych nośników, lecz konfigurację Jellyfina, metadane, własne napisy i rodzinne nagrania warto kopiować na drugi nośnik.

Transkodowanie nie jest trybem „lepszej jakości” — to koszt, którego najlepiej unikać

Najczęstsze nieporozumienie przy Jellyfinie dotyczy transkodowania. Serwer nie powinien konwertować filmu dlatego, że ma taką możliwość. Najlepszy jakościowo i najmniej obciążający wariant to Direct Play, czyli wysłanie oryginalnego pliku bez zmiany obrazu ani dźwięku.

Transkodowanie pojawia się wtedy, gdy klient nie radzi sobie z którymś elementem materiału albo połączenie jest za wolne.

Typowe powody to:

• brak obsługi kodeka wideo, np. HEVC na starszym urządzeniu,
• nieobsługiwany format dźwięku, np. TrueHD lub DTS-HD,
• format kontenera niedostępny w danym kliencie,
• zbyt wysoki bitrate dla łącza internetowego,
• konieczność zmniejszenia rozdzielczości,
• konwersja HDR do SDR,
• napisy, których klient nie potrafi wyświetlić bez wtopienia ich w obraz.

Ten ostatni przypadek potrafi być wyjątkowo irytujący. Film może działać jako Direct Play, a po włączeniu określonych napisów nagle uruchamia się pełne transkodowanie wideo. Dotyczy to zwłaszcza napisów obrazkowych, takich jak PGS z płyt Blu-ray, albo klientów mających ograniczoną obsługę formatów napisów.

Jeżeli zależy ci na minimalizowaniu transkodowania, napisy tekstowe SRT są zwykle znacznie mniej problematyczne.

Trzeba też odróżnić trzy sytuacje:

Direct Play — obraz, dźwięk i kontener są obsługiwane przez klienta. Serwer praktycznie tylko przesyła dane.

Direct Stream — strumienie audio i wideo pozostają bez rekompresji, ale Jellyfin przepakowuje je do innego kontenera. Obciążenie jest niewielkie.

Transcode — co najmniej jeden strumień jest dekodowany i kodowany ponownie. Tu zaczynają mieć znaczenie GPU, CPU, sterowniki i ustawienia FFmpeg.

Przykład pokazuje skalę różnicy. Film 4K z Blu-ray może mieć bitrate 50–80 Mb/s, a w niektórych fragmentach jeszcze wyższy. W sieci lokalnej Gigabit Ethernet nie stanowi to problemu. Poza domem, przy uploadzie 20 Mb/s, taki materiał trzeba ograniczyć, np. do 10–15 Mb/s. Serwer musi wtedy na bieżąco stworzyć nową wersję strumienia.

Programowe transkodowanie 4K HEVC na CPU jest fatalnym sposobem wykorzystania energii i pieniędzy. Nawet stosunkowo szybki procesor może osiągnąć wysokie obciążenie, nagrzewać się i nadal mieć problem z utrzymaniem odpowiedniej liczby klatek.

Sprzętowy enkoder zmienia sytuację. Jellyfin obsługuje między innymi:

• Intel Quick Sync Video,
• NVIDIA NVENC/NVDEC,
• AMD AMF w Windowsie,
• VA-API dla Intela i AMD w Linuksie,
• VideoToolbox na macOS,
• RKMPP na wybranych układach Rockchip.

W praktycznym serwerze domowym Intel jest często najprostszy. Nowsze iGPU obsługują sprzętowe dekodowanie HEVC 10-bit, a modele z odpowiedniej generacji pozwalają także wykonywać sprzętowy tone mapping HDR do SDR. To ważne, gdy na serwerze znajduje się film HDR, a użytkownik ogląda go na ekranie SDR.

Nie oznacza to, że każdy mini PC z napisem „Intel UHD” zagwarantuje identyczną wydajność. Znaczenie mają generacja GPU, kodek wejściowy, kodek wyjściowy, tone mapping, sterowniki i napisy. Typowe transkodowanie kilku strumieni 1080p jest znacznie łatwiejszym zadaniem niż jednoczesna konwersja 4K HDR z wypalaniem napisów.

Dlatego przed kupieniem mocniejszego serwera robię zawsze ten sam test: uruchamiam problematyczny film na docelowym urządzeniu i zaglądam do panelu Jellyfina. Jeśli widzę Direct Play, sprzętu nie trzeba przyspieszać. Jeżeli widzę Transcode, sprawdzam podany przez serwer powód.

To pozwala uniknąć absurdalnej sytuacji, w której ktoś kupuje kartę graficzną za 1500 zł, choć wystarczyłoby zmienić aplikację kliencką albo plik z napisami.

Istotna jest również pamięć masowa przeznaczona na pliki tymczasowe transkodera. Trzymanie katalogu transkodowania na wolnym HDD nie zawsze będzie problemem, ale przy kilku równoległych zadaniach SSD jest bezpieczniejszym wyborem. Nie trzeba kupować dużego nośnika — zazwyczaj wystarcza wydzielenie kilkudziesięciu gigabajtów, o ile Jellyfin prawidłowo usuwa tymczasowe segmenty.

Dostęp poza domem: najpierw upload i CGNAT, dopiero potem domena

Lokalnie Jellyfin działa domyślnie przez TCP 8096 dla HTTP. To nie oznacza, że należy przekierować port 8096 na routerze i wystawić go bezpośrednio do internetu. Da się tak zrobić, ale jest to słaba konfiguracja bezpieczeństwa.

Do zdalnego dostępu są dwie rozsądne drogi.

Pierwsza to VPN typu Tailscale. Jest dobrym wyborem, jeśli z serwera korzystasz sam albo udostępniasz go kilku osobom, którym możesz skonfigurować klienta VPN. Nie trzeba kupować domeny, konfigurować certyfikatów ani otwierać publicznego portu Jellyfina.

Największa wada? Każde urządzenie musi obsługiwać Tailscale lub znajdować się w sieci, do której ruch został odpowiednio routowany. Na telefonie czy laptopie to proste. Na niektórych telewizorach i starszych przystawkach robi się mniej wygodne.

Druga opcja to reverse proxy, najczęściej Caddy, Nginx, Traefik albo Apache, działające przed Jellyfinem. Wtedy użytkownik łączy się np. z https://media.example.pl, reverse proxy obsługuje HTTPS i przekazuje żądania do Jellyfina działającego lokalnie.

Caddy jest szczególnie wygodny, bo automatyzuje znaczną część obsługi certyfikatów TLS. Przy tradycyjnej konfiguracji reverse proxy do routera kieruje się zwykle TCP 80 i 443, przy czym ruch aplikacji powinien ostatecznie odbywać się po HTTPS. Jellyfin zaleca terminowanie HTTPS właśnie na reverse proxy, zamiast bezpośrednio w samym serwerze.

Jeżeli używasz reverse proxy, w Jellyfinie trzeba poprawnie ustawić Known Proxies. W przeciwnym razie serwer może widzieć adres proxy zamiast rzeczywistego adresu klienta. Trzeba również zapewnić obsługę WebSocketów.

Jest jeszcze jeden problem szczególnie częsty przy domowych łączach: CGNAT. Operator nie przydziela wtedy twojemu routerowi publicznego adresu IPv4. Przekierowanie portu w panelu routera niczego nie zmieni, bo po drodze znajduje się jeszcze NAT operatora.

Łatwo to sprawdzić:

1. odczytaj adres WAN w panelu routera,
2. porównaj go z publicznym adresem IPv4 widzianym z internetu,
3. jeśli adresy się różnią albo WAN znajduje się w zakresie 100.64.0.0/10, najprawdopodobniej jesteś za CGNAT-em.

W Polsce problem często dotyczy internetu mobilnego LTE/5G, ale może występować również na innych typach łączy. Rozwiązaniem jest wykupienie publicznego adresu od operatora, użycie IPv6, Tailscale albo pośredniego VPS-a/tunelu.

Nie wolno przy tym ignorować prędkości wysyłania. Łącze reklamowane jako 600 Mb/s może mieć np. 600 Mb/s pobierania i tylko 50–100 Mb/s wysyłania. Dla Jellyfina poza domem liczy się przede wszystkim upload serwera.

Przy jednym użytkowniku orientacyjne założenia wyglądają rozsądnie tak:

• 1080p po transkodowaniu: około 5–12 Mb/s,
• wysokiej jakości 1080p Direct Play: często 10–30 Mb/s,
• 4K z mocną kompresją: około 15–30 Mb/s,
• 4K Remux: często 50–100 Mb/s lub więcej.

Nie ustawiałbym maksymalnego bitrate’u zdalnego na poziomie równym całemu uploadowi. Przy łączu 50 Mb/s limit jednego strumienia na poziomie 40–45 Mb/s zostawia zbyt mały margines na wahania sieci, inne urządzenia i narzut protokołów. Jeżeli Jellyfin ma obsługiwać dwie osoby jednocześnie, budżet pasma trzeba dzielić między użytkowników.

To właśnie tutaj Jellyfin pokazuje zarówno największą zaletę, jak i największą niedogodność względem Plexa. Nie płacisz Jellyfinowi za zdalne odtwarzanie własnych plików, ale sam odpowiadasz za HTTPS, adresację, firewall, aktualizacje i bezpieczeństwo serwera. W Plexie część tej warstwy jest wygodniejsza, lecz zdalne odtwarzanie prywatnego wideo na objętych zmianami platformach wymaga obecnie Plex Pass albo Remote Watch Pass. Standardowa cena Remote Watch Pass wynosi 2,99 USD miesięcznie lub 29,99 USD rocznie, natomiast Plex Pass kosztuje według aktualnego cennika 6,99 USD miesięcznie, 69,99 USD rocznie albo 749,99 USD jednorazowo za licencję Lifetime. Przy Jellyfinie koszt oprogramowania serwerowego pozostaje zerowy — płacisz za sprzęt, dyski, energię, ewentualną domenę, publiczny adres IP albo VPS.

Jeżeli serwer ma być dostępny z internetu, aktualizacje nie są dodatkiem. W 2026 roku w gałęzi 10.11 Jellyfina ukazywały się również poprawki bezpieczeństwa, dlatego urządzenia wystawionego publicznie nie warto zostawiać na starej wersji przez wiele miesięcy.

FAQ: najczęstsze pytania o domowy serwer Jellyfin

Czy Jellyfin jest naprawdę darmowy?
Tak. Serwer Jellyfin jest projektem open source i nie wymaga abonamentu za sprzętowe transkodowanie ani za zdalny dostęp. Kosztem pozostaje własny sprzęt, pamięć masowa, energia elektryczna i ewentualna infrastruktura sieciowa.

Czy do Jellyfina potrzebuję NAS-a?
Nie. Na początek wystarczy zwykły komputer, mini PC albo laptop. NAS ma sens przede wszystkim wtedy, gdy zależy ci na uporządkowanej pamięci masowej, kilku dyskach i pracy 24/7. Kupowanie NAS-a tylko po to, aby „mieć Jellyfina”, zwykle nie jest najbardziej ekonomiczną drogą.

Czy Intel N100 wystarczy do Jellyfina?
Do biblioteki domowej jest bardzo sensownym punktem startowym, szczególnie gdy większość materiałów działa przez Direct Play, a transkodowanie korzysta z Quick Sync. Nie traktowałbym go jednak jako gwarancji dowolnej liczby konwersji 4K HDR z wypalaniem napisów. To znacznie cięższe zadanie niż zwykłe transkodowanie 1080p.

Czy potrzebuję karty NVIDIA?
Zwykle nie. Jeśli procesor Intela ma odpowiednie iGPU z Quick Sync, dokładanie osobnej karty tylko dla typowego domowego Jellyfina często zwiększa koszt i pobór energii bez realnej korzyści. NVIDIA zaczyna mieć więcej sensu przy większej liczbie wymagających transkodowań albo gdy serwer i tak wykorzystuje GPU do innych zadań.

Dlaczego film działa płynnie bez napisów, a po ich włączeniu zaczyna się zacinać?
Najczęściej klient nie potrafi bezpośrednio wyrenderować danego formatu napisów i Jellyfin musi wtopić je w obraz. To uruchamia transkodowanie wideo. Szczególnie problematyczne bywają napisy PGS. Jeśli masz możliwość wyboru, sprawdź wersję SRT.

Czy można bezpiecznie przekierować port 8096 na routerze?
Technicznie tak, ale bezpośrednie wystawianie portu Jellyfina do publicznego internetu nie jest zalecaną konfiguracją. Lepszym rozwiązaniem jest VPN albo reverse proxy z HTTPS.

Co wybrać do zdalnego dostępu: Tailscale czy reverse proxy?
Dla jednej osoby lub kilku technicznych użytkowników wybrałbym Tailscale — konfiguracja jest prostsza i nie trzeba publicznie wystawiać Jellyfina. Reverse proxy ma więcej sensu wtedy, gdy dostęp ma działać jak zwykły serwis internetowy na telewizorach, telefonach i innych urządzeniach bez dodatkowego klienta VPN.

Czy łącze 1 Gb/s gwarantuje płynne oglądanie 4K poza domem?
Nie. Trzeba sprawdzić prędkość wysyłania, a nie pobierania. Światłowód 1 Gb/s może mieć upload 300 Mb/s, ale inne oferty są mocno asymetryczne. 4K Remux może potrzebować 50–100 Mb/s lub więcej i jest wrażliwy na chwilowe spadki przepustowości.

Czy Jellyfin działa za CGNAT-em?
Tak, ale klasyczne przekierowanie portów nie zadziała. Najprościej użyć Tailscale albo innego rozwiązania VPN/tunelowego. Alternatywą jest publiczny IPv4 od operatora, poprawnie skonfigurowane IPv6 lub serwer VPS pośredniczący w ruchu.

Od czego zacząć budowę serwera?
Nie od zakupu NAS-a. Najpierw zainstaluj Jellyfina na komputerze, który już masz, dodaj kilka najbardziej wymagających plików — 4K HEVC HDR, materiał z TrueHD/DTS oraz film z napisami PGS — i sprawdź w panelu odtwarzania, co faktycznie trafia w Direct Play, a co uruchamia Transcode. Dopiero ten test mówi, jakiego sprzętu potrzebujesz. Jeśli pierwszym problemem okaże się brak obsługi kodeka albo napisów po stronie telewizora, popraw klienta. Jeśli problemem jest transkodowanie, dopiero wtedy dobieraj procesor z Quick Sync lub inne GPU. To najtańszy błąd do usunięcia przed wydaniem pieniędzy na serwer.