Homelab z pomocą LLM-a: wygoda, pułapki i lekcje z praktycznego eksperymentu

Niedawno opublikowaliśmy raport CERT Orange Polska za rok 2025. Poniższa publikacja autorstwa Grzegorza Zembrowskiego opisuje kulisy budowy domowego homelab. Zapraszamy do lektury artykułu, ale także oczywiście całego raportu.

Czy da się zbudować rozbudowany homelab bez dobrej znajomości linii poleceń Linuxa, opierając się głównie na metodzie „kopiuj-wklej” i podpowiedziach modelu językowego? Postanowiłem to sprawdzić w praktyce. Ten tekst jest zapisem takiego eksperymentu: od pierwszych decyzji sprzętowych, przez kolejne warstwy konfiguracji i zabezpieczeń, aż po najważniejsze pytanie — ile naprawdę zyskujemy, a ile tracimy, powierzając kluczowe elementy domowej infrastruktury LLM-owi.

Inspiracją była dla mnie konferencja OMH 2025 i wystąpienie Grzegorza Wróbla z portalu Adwersarz.pl o idei homelabu, czyli domowej infrastruktury IT. Czasem to serwerownia w garażu, a czasem kilka urządzeń schowanych pod biurkiem. Sam miałem w domu stary, wyłączony NAS z biblioteką multimedialną jeszcze z poprzedniego etapu życia zawodowego. Działał źle, wolno i mało stabilnie. Uznałem więc, że to dobry moment, by spróbować zbudować coś sensowniejszego.

Od początku wiedziałem też, gdzie mam największy brak kompetencyjny. Mimo doświadczenia w cybersecurity i data science nigdy porządnie nie nauczyłem się pracy w linii poleceń Linuxa. Na co dzień korzystam z Windowsa i Ubuntu, czasem z Kali, ale zwykle w GUI. Jeśli muszę wejść zdalnie na serwer, to raczej uruchamiam Midnight Commandera albo korzystam z gotowych komend zapisanych wcześniej w notatkach. Ten eksperyment był więc również testem: czy da się zbudować coś złożonego, nie mając pełnej samodzielności administracyjnej.

Sprzęt: od starego komputera do mini-PC

Na początku chciałem tylko jednego: żeby magazyn danych działał jak należy. Nie z prędkością kilku MB/s, ale jak prawdziwy NAS. Z piwnicy przyniosłem więc starego ASUS-a w obudowie Small Form Factor, kilka dysków HDD i zacząłem sprawdzać możliwości. Internet szybko podpowiedział, że DIY NAS da się zbudować niemal z dowolnego starego komputera.

Problem w tym, że po analizie ograniczeń sprzętowych wyszło, że mój zestaw po prostu się nie nadaje. Dwurdzeniowy procesor, miejsce na jeden HDD, brak złącza M.2 i ograniczenia portów oznaczały, że trudno będzie mówić o wydajności. Model językowy zasugerował więc popularny wśród entuzjastów homelabów mini-PC Lenovo m720q lub m920q. Poszedłem tym tropem i jeszcze tego samego dnia kupiłem taki komputer.

Od początku zależało mi na szybkim transferze danych. Stary NAS THECUS N4310 z jednordzeniowym procesorem i 1 GB RAM kopiował niemal 4 TB danych przez cztery dni. To wystarczyło, by od razu dołożyć adaptery USB–RJ45 2,5 Gbps, switche 2,5 Gbps oraz adapter umożliwiający montaż karty PCIe. Budżet startowy nie był wysoki: około 700 zł za komputer i mniej niż 400 zł za dodatkowe elementy sieciowe. Reszta to kable i zalegające w domu dyski. Jak się później okazało, były to tylko koszty początkowe.

Po kolejnych rozmowach z modelem ustaliliśmy, że najlepiej byłoby podłączyć dwa dyski HDD 6 TB po SATA. Sprzęt jednak tego nie umożliwiał, więc ostatecznie w grę weszła kieszeń USB. Włożyłem do niej dwa dyski 6 TB w RAID0, żeby uzyskać większą wydajność. Pomysł od początku miał słabe strony i późniejsza awaria jednego z dysków szybko to potwierdziła.

Jak wygląda praca z LLM-em przy konfiguracji

W teorii wygląda to bardzo prosto. Wpisuję: „Potrzebuję skonfigurować sieć dla Proxmoxa zainstalowanego na lokalnej maszynie”, a model odpowiada listą poleceń do wykonania. W praktyce po kilku krokach okazuje się zwykle, że brakuje pakietu, nie ma dostępu do zasobu albo konfiguracja nie działa w danym środowisku tak, jak zakładał model. Wtedy zaczyna się debugowanie: kolejne komendy, kolejne wyniki, kolejne poprawki.

Taki tryb pracy często prowadzi do rozwiązania problemu, ale ma dużą wadę: łatwo zgubić główny plan działania. Po kilkuset liniach rozmowy trudno wrócić do pierwotnej listy zadań. Zdarzało się też, że miałem wrażenie kręcenia się w kółko i próbowałem przenosić problem do innego modelu. Jeden lepiej porządkował dokumentację problemu, drugi szybciej proponował rozwiązania, ale za to bardziej „halucynował”. Szybko okazało się, że nie ma tu idealnego narzędzia.

Po wielu próbach wypracowałem metodę, która rzeczywiście działa. Najważniejsza zasada brzmi: zostaw modelowi jak najmniej rzeczy do domyślania się. Każdą większą sesję kończę więc prośbą o przygotowanie raportu opisującego aktualny stan homelabu, sieci, zainstalowanych komponentów i założeń. Taki raport staje się punktem wyjścia do nowej rozmowy.

Drugi ważny element to rozdzielenie planowania od wykonywania. Najpierw proszę model o analizę potrzeb i wariantów rozwiązania. Dopiero potem przechodzę do realizacji, z poleceniem typu: „Ustal kolejność kroków do realizacji celu, a następnie podawaj gotowe komendy pojedynczo. Jeśli pojawi się problem, po jego rozwiązaniu wróć do założonej kolejności”. To prosty zabieg, ale dzięki niemu nawet trudne debugowanie nie rozbija całej sesji.

Co udało się zrobić

Przy takim podejściu udało się skonfigurować całkiem dużo:

• Proxmoxa, dyski i sieć — w dużej części przez terminal.
• Migrację danych ze starego NAS-a — wraz z doborem parametrów polecenia rsync.
• Dostępy do udziałów SMB — dla użytkowników sieci lokalnej.
• Alerty e-mailowe o stanie dysków i S.M.A.R.T.
• Automatyczne zamykanie serwera przy niskim poziomie naładowania UPS-a
• Navidrome — z osobnymi bibliotekami muzycznymi dla różnych użytkowników.
• Tailscale VPN — dzięki czemu dostęp do usług lokalnych stał się możliwy także poza domem.
• AdGuard Home — jako lokalny serwer DNS filtrujący ruch i blokujący reklamy.
• Automatyczne backupy — na stary NAS i dysk USB.

Brzmi dobrze, ale właśnie przy backupach pojawił się dla mnie najważniejszy sygnał ostrzegawczy. Zorientowałem się, że nie jestem w stanie samodzielnie przywrócić kopii ani wprowadzić drobnej zmiany w istniejącym systemie. Nie wiedziałem dokładnie, gdzie są skrypty, co odpowiada za konkretne zadanie i jak to wszystko ze sobą współpracuje. System działał, ale moje zrozumienie jego działania było powierzchowne.

To chyba najważniejsza lekcja z całego eksperymentu: LLM może pomóc coś uruchomić, ale nie gwarantuje, że będziemy umieli tym samodzielnie zarządzać.

GUI kontra terminal

Przy instalacji Jellyfin postanowiłem dla odmiany prosić o wskazówki dotyczące konfiguracji przez GUI. To okazało się trudniejsze, niż sądziłem. Interfejsy graficzne aplikacji zmieniają się często, więc model bywał przekonany, że dany przycisk znajduje się w miejscu, gdzie już go nie ma albo ma inną nazwę.

Z drugiej strony ta metoda miała istotną zaletę: zmuszała mnie do lepszego poznania aplikacji. Konfiguracja przez GUI jest mniej wygodna dla modelu, ale bardziej rozwijająca dla użytkownika. Jeśli celem nie jest wyłącznie „uruchomić”, ale także później samodzielnie administrować usługą, to taka droga może być rozsądniejsza.

Bezpieczeństwo: temat, którego model sam nie podnosi

Najbardziej zaskoczyło mnie to, że kwestie bezpieczeństwa prawie nie pojawiały się w rozmowach z modelem samoczynnie. Dopóki pytałem głównie o funkcjonalność, odpowiedzi skupiały się na tym, jak coś uruchomić, a nie jak zrobić to bezpiecznie.

Dopiero gdy sam zacząłem dopytywać o segmentację, dostęp administracyjny i ograniczanie zasięgu usług, pojawiły się konkretne rekomendacje. W moim przypadku chodziło o oddzielenie strefy administracyjnej od strefy użytkowników i danych. Sprzętowo dało się to zrealizować dość prosto, wykorzystując stary router i istniejącą infrastrukturę, ale wykonanie konfiguracji było już znacznie trudniejsze.

To ważny wniosek także szerzej: przy budowie własnych usług sieciowych największe ryzyko często nie wynika z samego narzędzia, ale z błędnej konfiguracji, nadmiernych uprawnień, zbyt szerokiej ekspozycji usług i braku segmentacji. Jeśli korzystamy z pomocy AI, te pytania trzeba zadawać świadomie. Model nie zawsze zrobi to za nas.

Zalety i minusy

Największa zaleta jest oczywista: model językowy bardzo obniża próg wejścia. Pozwala przejść od pomysłu do działającego rozwiązania znacznie szybciej, niż byłoby to możliwe wyłącznie na podstawie dokumentacji i wyszukiwarki. Dla osoby mniej technicznej może być realnym wsparciem w planowaniu, analizie wariantów i rozwiązywaniu problemów.

Ale lista minusów też jest długa.

1. Czas

To wszystko po prostu trwa. Jedna konfiguracja potrafi oznaczać setki linii poleceń i kilka wielogodzinnych sesji. Do tego długie rozmowy stają się coraz mniej wygodne: model odpowiada wolniej, a sama przeglądarka zaczyna odczuwać ciężar rozbudowanej historii.

2. Chaos dokumentacyjny

Bez porządnej bazy wiedzy łatwo zgubić zależności między elementami systemu. Naprawa jednego fragmentu może zepsuć inny. Sam zacząłem już budować własną wiki dla homelabu, bo bez tego dalszy rozwój robi się ryzykowny.

3. Rosnące koszty

Homelab rzadko kończy się na pierwszym zakupie. Pojawiają się kolejne potrzeby: dyski, UPS, adaptery, karty sieciowe, kable, przejściówki, nośniki cache. Początkowo wygląda to niewinnie, ale z czasem suma robi się zauważalna.

4. Zależność od modelu

To dla mnie najpoważniejszy problem. Jeśli przestaje działać jakaś usługa, często nie wiem, od czego zacząć diagnozę bez wsparcia modelu. Taka zależność jest wygodna, dopóki wszystko działa. W dłuższej perspektywie może jednak oznaczać, że budujemy system, którego sami nie rozumiemy.

Wniosek: da się, ale to nie jest droga na skróty

Czy da się zbudować homelab niemal bez znajomości linii poleceń Linuxa i głównie metodą „kopiuj-wklej” z LLM-a? Tak — i to zaskakująco dużo da się w ten sposób osiągnąć. Można uruchomić usługi, poprawić wydajność, zbudować sensowne środowisko do backupu, multimediów czy zdalnego dostępu.

Ale nie jest to droga na skróty. Raczej nowy model pracy, w którym szybkość i wygoda są okupione ryzykiem powierzchownego zrozumienia, chaosem dokumentacyjnym i zależnością od zewnętrznego narzędzia.

Jeśli miałbym wyciągnąć z tego eksperymentu jedną praktyczną radę, brzmiałaby tak: używaj LLM-a do przyspieszania pracy, ale nie oddawaj mu pełnej kontroli nad systemem, którego później sam nie potrafisz utrzymać. W przeciwnym razie zbudujesz nie homelab, lecz bardzo sprawnie działającą czarną skrzynkę.