Domowy serwer pod Proxmox i Docker: praktyczny poradnik budowy energooszczędnej maszyny dla zaawansowanych

Po co ci domowy serwer? Uporządkuj swoje cele

Jakie realne problemy rozwiązuje domowy serwer Proxmox + Docker

Domowy serwer pod Proxmox i Docker nie jest gadżetem dla samego gadżetu. To narzędzie, które ma rozwiązywać konkretne problemy: rozproszone dane, brak kopii zapasowych, chaos w usługach w chmurze, brak środowiska do nauki i testów. Zanim wydasz pierwszą złotówkę, odpowiedz sobie: co ma zniknąć z twojej głowy jako „problem”, gdy ten serwer będzie już działał?

Typowe scenariusze są dość powtarzalne. Najczęściej chodzi o:

• Kopie zapasowe komputerów, laptopów, telefonów i zdjęć rodzinnych – coś więcej niż dysk USB „podpinam raz w roku”.
• Media i biblioteka filmów/muzyki – Plex/Jellyfin, kolekcje zdjęć, streaming po domu, czasem dostęp z zewnątrz.
• Usługi self-hosted – własny Nextcloud, serwer Git, Home Assistant, serwer gier, VPN, monitoring sieci i urządzeń IoT.
• Homelab – miejsce do nauki Kubernetes, Ansible, CI/CD, nowych dystrybucji, bez ryzyka rozwalenia głównego systemu.

Spójrz na swoją sytuację: czy dane są rozrzucone po kilku chmurach (Google, Microsoft, Dropbox), dyskach USB i laptopach? Czy miałeś kiedyś chwilę grozy, gdy laptop nie chciał wstać, a na nim były jedyne zdjęcia z kilku lat? Jeżeli tak, domowy serwer jest odpowiedzią. Proxmox daje Ci kontrolę nad infrastrukturą, Docker – nad aplikacjami.

Pytanie do ciebie: jaką jedną rzecz chcesz rozwiązać w pierwszej kolejności? Backup? Media? Nauka Dockera? Uporządkuj priorytety, bo od nich zależy architektura, jaką przyjmiesz, a potem – sprzęt, który kupisz.

Co już stoi w domu w roli „serwera” i co z tym zrobić

Rozejrzyj się po mieszkaniu: często domowy „serwer” już istnieje, tylko nikt tak go nie nazywa. Popularne przypadki:

• Router z USB i dyskiem podpiętym jako prosty NAS.
• Raspberry Pi z Home Assistantem, Pihole albo małym serwerem WWW.
• Stary laptop leżący w szafie, który czasem służy za „tymczasowy serwer plików”.
• Gotowy NAS (Synology, QNAP) z kilkoma usługami typu kontenery lub VM.

Zastanów się: czy to ma działać obok nowego serwera, czy chcesz to wszystko zintegrować? Czasem najlepszym ruchem jest:

• zostawić gotowy NAS wyłącznie do przechowywania danych i kopii zapasowych,
• a cały „mózg” (Proxmox, Docker, aplikacje) przenieść na nową, energooszczędną maszynę.

Jeśli masz Raspberry Pi, może dalej służyć jako dodatkowy węzeł: monitoring, zdalny syslog, mały reverse proxy przed serwerem w szafie. Nie trzeba wszystkiego wyrzucać – lepiej nadać tym urządzeniom jasne role. Pytanie kontrolne: czy cokolwiek, co dziś działa, jest krytyczne? Jeśli tak, planuj migrację na spokojnie i etapami.

Fajny projekt vs system działający 24/7

Domowy serwer łatwo potraktować jak hobby: „zrobię to w weekend”. Problem w tym, że gdy zaczniesz trzymać tam dane rodziny, swoje projekty, automatyzację domu, to przestaje być tylko zabawa. Różnica jest zasadnicza:

• w hobbystycznym projekcie możesz sobie pozwolić na częste restarty, zmiany konfiguracji z dnia na dzień, „format co miesiąc”,
• w systemie 24/7 liczy się przewidywalność, kopie zapasowe, sensowny monitoring, aktualizacje robione z głową.

Zastanów się, czy godzisz się na to, że serwer może leżeć przez pół dnia, bo coś wytestujesz i popsujesz? Jeśli nie – to już nie jest tylko „projekt”. Oznacza to dodatkowe wymagania: minimalny poziom redundancji danych, przemyślany backup Proxmoxa i kontenerów, ostrożne podejście do upgrade’ów.

Serwer 24/7 wpływa też na rachunki, hałas, temperaturę w pomieszczeniu. W mieszkaniu różnica między 20 a 50 W mocy ciągłej jest istotna. Proxmox pozwala to dobrze poukładać, ale wymaga świadomych decyzji: co w VM, co w LXC, co w Dockerze i jak to wszystko spiąć, by mieć kontrolę, a nie chaos.

Granica między zabawą a „produkcją” w domowym homelabie

Kiedy zaczyna się „produkcja” w homelabie? Prosty test: czy utrata tych danych lub kilkugodzinny brak usługi będzie bolał ciebie lub kogoś z domowników? Jeśli tak, to dla ciebie jest to system produkcyjny, nawet jeśli stoi na półce w salonie.

Typowe „produkcyjne” elementy w domu to:

• rodzinne zdjęcia i dokumenty,
• automatyzacja domu (światło, ogrzewanie),
• VPN do pracy lub do własnej sieci,
• serwer multimediów, z którego codziennie korzysta rodzina.

Przy tej granicy zmienia się sposób myślenia. Zaczynasz potrzebować czegoś więcej niż tylko „zrobię snapshot raz na jakiś czas”. Powstają pytania: jak odtworzysz Proxmoxa po awarii dysku systemowego? Czy Twoje kontenery Dockera da się szybko postawić na innym sprzęcie? W którym miejscu trzymasz backup konfiguracji? Jeśli chcesz wejść w strefę „półprofesjonalną”, a jednocześnie zadbać o rachunki za prąd i spokój w domu, dobrze zaplanowana maszyna Proxmox z Dockerem jest rozsądnym kompromisem.

Proxmox + Docker – kto jest kim w tym układzie

Proxmox jako hypervisor i platforma zarządzania

Proxmox VE to hypervisor oparty o KVM i LXC, z wygodnym webowym panelem. W praktyce pełni funkcję „systemu nadrzędnego” w twoim homelabie. Na nim definiujesz:

• maszyny wirtualne (VM) – pełne systemy, np. Debian, Ubuntu, Windows,
• kontenery LXC – lekkie środowiska z własnym rootfs, ale współdzielącym kernel z Proxmoxem,
• storage pod dyski wirtualne, backupy i szablony,
• sieć: bridge, VLAN-y, NAT, reguły firewall (opcjonalnie).

Proxmox świetnie nadaje się jako „kręgosłup” domowej infrastruktury. Raz zainstalowany, może działać latami, a wszystko, co „aplikacyjne”, trzymasz wyżej – w VM lub LXC, często zarządzanych przez Dockera. Zastanów się, czy jesteś gotów nauczyć się jednego dodatkowego poziomu abstrakcji (hypervisor + VM/kontenery), czy wolisz maksymalną prostotę „Linux + Docker na goło”?

Docker jako warstwa aplikacyjna nad Proxmoxem

Docker to narzędzie do uruchamiania aplikacji w kontenerach. Nie zastępuje hypervisora. W połączeniu z Proxmoxem typowy układ wygląda tak:

• Proxmox jako główny system,
• jedna lub kilka VM (np. Debian/Ubuntu) pod Dockera,
• w tych VM uruchamiasz kontenery Docker: bazę danych, reverse proxy, aplikacje webowe, media serwer, Home Assistant itd.

Możliwy jest też wariant z Dockerem w LXC, ale to wymaga kilku dodatkowych kroków i świadomego podejścia do bezpieczeństwa. Docker pełni rolę katalogu aplikacji: szybko podnosisz i aktualizujesz usługi, używasz docker-compose, snapshoty VM w Proxmoxie pozwalają przetestować upgrade bez strachu.

Pytanie kontrolne: czy bardziej zależy Ci na elastyczności i izolacji, czy na minimalnej liczbie warstw? Jeżeli masz ambicje homelabowe, uczysz się DevOps/Cloud, Proxmox + Docker da Ci realistyczny model „małej chmury” w domu.

Gdzie uruchamiać Dockera: VM vs LXC vs „goły” Linux

Masz trzy główne opcje, każda z plusami i minusami.

Docker w maszynie wirtualnej (VM)

Najpopularniejszy i najbezpieczniejszy model dla zaawansowanego domowego serwera:

• tworzysz jedną VM z Debiana/Ubuntu,
• instalujesz Docker + docker-compose,
• tam trzymasz pliki konfiguracyjne, wolumeny, stacki.

Zyskujesz:

• izolację od systemu hosta (Proxmoxa) – łatwiej naprawić VM niż całą bazę,
• snapshoty VM przed dużymi zmianami,
• możliwość przeniesienia całej VM na inny serwer Proxmox (migrowanie, backup/restore).

Minusy: dodatkowa warstwa powoduje trochę większy narzut zasobów niż Docker bezpośrednio na hoście, choć na dzisiejszym sprzęcie to zwykle akceptowalne.

Docker w kontenerze LXC

Ten wariant jest bardziej zaawansowany. Wymaga „poodkręcania” kilku zabezpieczeń w LXC (privileged, nesting), bo Docker sam z siebie potrzebuje funkcji jądra, które LXC domyślnie ogranicza. Zyskujesz:

• nieco mniejszy narzut niż VM,
• łatwiejsze przenoszenie kontenera,
• wygodną integrację z Proxmoxem (backup LXC, konsola w panelu).

Ale płacisz:

• większą złożonością przy konfiguracji,
• czasem problemami z kompatybilnością niektórych obrazów Dockera,
• bardziej złożoną kwestią bezpieczeństwa (privileged LXC + Docker = dużo uprawnień).

Jeżeli jesteś już obyty z Linuksem, cgroups i LXC, ten model działa bardzo dobrze. W innym wypadku rozsądniej zacząć od Dockera w VM.

Tylko Docker na gołym Linuxie – bez Proxmoxa

Ostatni scenariusz: instalujesz na maszynie np. Debian Server, na nim Docker, bez dodatkowego hypervisora. Plusy:

• maksymalna prostota – jedna warstwa mniej,
• minimalny narzut – każda VM to jednak dodatkowe procesy,
• mniej elementów do aktualizowania i pilnowania.

Minusy są strategiczne:

• brak „natywnych” VM – trudniej odseparować środowiska testowe,
• trudniej odtworzyć całość w razie problemów z systemem (tu Proxmox + snapshot VM mocno pomaga),
• mniejsza elastyczność przy rozbudowie homelabu.

Dla części osób „goły Docker” jest idealny i wystarczy, ale jeśli tworzysz homelab dla zaawansowanych zastosowań, chcesz ACS, VLANy, kilka systemów operacyjnych – Proxmox daje lepszą bazę.

Planowanie architektury domowego serwera – zanim kupisz pierwszą część

Topologia: router, serwer, storage – kto za co odpowiada

Zanim zaczniesz wybierać CPU i RAM, narysuj prosty diagram: internet → router → switch (opcjonalnie) → serwer Proxmox → ewentualny NAS / dodatkowe nody. Odpowiedz sobie na pytanie: co ma być centrum ruchu i danych, a co tylko dodatkiem?

Zwykle rozsądnie jest przyjąć:

• router – brama na świat, firewall, ewentualnie VLANy; lepiej, by nie był przeciążany dodatkowymi usługami (Plex, backupy),
• serwer Proxmox – warstwa obliczeniowa: VM, LXC, Docker, automatyzacja, monitoring,
• storage – może być lokalny (w serwerze) lub osobny NAS; ważne, by dane krytyczne były w miejscu, które łatwo skopiować.

Co w VM, co w kontenerach, a co na osobnej maszynie

Dobrze zorganizowany homelab to taki, w którym można coś zepsuć bez rozwalania wszystkiego. Pomaga w tym świadomy podział:

• VM pod „cięższe” systemy lub takie, które mają swoje wymagania (np. Windows Server, pfSense, FreeBSD),
• LXC pod lekkie usługi linuksowe, które nie wymagają pełnej wirtualizacji,
• Docker pod aplikacje, które mają gotowe obrazy, szybko się aktualizują, są „jednofunkcyjne”.

Czasem dobrą praktyką jest izolacja roli:

• jedna VM „docker-host” z Twoimi aplikacjami webowymi, bazami danych,
• osobny LXC pod monitoring (Prometheus, Grafana, Loki),
• osobna VM pod Home Assistant (np. HassOS) albo LXC z HA,
• router „na osobnej maszynie” – sprzętowy (EdgeRouter/MikroTik) lub VM z pfSense/OPNsense, ale pod warunkiem, że masz świadomość ryzyk (jedna skrzynka robi wszystko).

Zadaj sobie przy tym jedno proste pytanie: co musi działać zawsze, a co może się czasem wywalić? Router/gateway i DNS to fundament – lepiej, żeby biegły na osobnym, stabilnym środowisku (sprzętowy router albo osobna, mocno ograniczona VM). Strefa zabawowa – labowe Kubernetesy, eksperymentalne bazy, nowe wersje Home Assistanta – niech żyje w innych VM/LXC, które można bez stresu skasować i odtworzyć z backupu lub szablonu.

Drugie pytanie: jak bardzo chcesz się bawić w administrację, a jak bardzo w aplikacje? Jeśli główny cel to „mieć działające usługi”, trzymaj się prostego podziału: 1–2 VM pod Dockerem, kilka lekkich LXC na narzędzia pomocnicze (VPN, monitoring, syslog) i tyle. Gdy ciągnie Cię w stronę homelabu i nauki, dołóż osobne VM na różne dystrybucje, mini‑klaster testowy, replikację baz – ale z jasnym rozgraniczeniem, co jest produkcją domową, a co piaskownicą.

Warto też od razu określić, gdzie kończy się jeden serwer. Czy wszystko ma biec na jednej maszynie Proxmox, czy planujesz drugi, mały węzeł na backup/DR? Jeżeli budżet pozwala, bardzo wygodny układ to: główny serwer z Proxmoxem i Dockerem (aplikacje), mały energooszczędny box jako węzeł zapasowy (najważniejsze VM + kopie backupów) oraz prosty NAS lub choćby dysk USB tylko na zrzuty. Przy awarii głównego pudła nie tracisz wtedy danych ani kluczowych usług.

Planowanie sieci: VLANy, adresacja, dostęp z zewnątrz

Zanim odpalisz pierwszą VM z Dockerem, spójrz na sieć. Zadaj sobie pytanie: czy twoje usługi mają być dostępne tylko w LAN, czy też z internetu? Od odpowiedzi zależy, jak bardzo komplikujesz topologię.

Na początek ustal prostą, ale spójną adresację:

• jeden zakres dla urządzeń klienckich (laptopy, telefony),
• osobny zakres dla serwerów (VM/LXC i same węzły Proxmoxa),
• opcjonalny zakres „gościnny” lub dla IoT (TV, żarówki, kamerki).

Czy potrzebujesz VLANów? Jeżeli:

• masz router/switch z obsługą VLAN (MikroTik, EdgeRouter, Unifi itp.),
• zamierzasz wystawiać usługi na świat i trzymasz w sieci nieufne IoT,
• planujesz więcej niż kilka VM/serwisów z różnymi rolami,

to segmentacja VLAN jest dobrym krokiem. Przykładowy podział:

• VLAN 10 – „client” (laptopy, telefony),
• VLAN 20 – „server” (Proxmox, VM, LXC),
• VLAN 30 – „iot” (TV, żarówki, kamery IP),
• VLAN 40 – „guest” (goście, sprzęt z nieznanym pochodzeniem).

Zastanów się: które VLANy muszą mieć dostęp do których usług? Np. IoT często ma tylko wychodzić w internet i ewentualnie do kilku serwisów (np. Home Assistant w VLAN server). Reguły firewall na routerze załatwiają to dużo eleganckiej niż kombinowanie reguł na każdym hoście.

Mosty sieciowe Proxmoxa i dostęp VM/LXC do LAN

Proxmox używa mostów sieciowych (bridge), żeby VM i LXC widziały się jak normalne hosty w LAN. Domyślnie instalator tworzy most vmbr0 z podpiętym fizycznym interfejsem, np. eno1. Większości instalacji na start to wystarczy.

Jeżeli planujesz VLANy, sprawa jest trochę ciekawsza. Możesz:

• trzymać tagowanie VLAN wyłącznie na routerze/switchu i używać jednego „płaskiego” mostu w Proxmoxie,
• albo przenieść część logiki do Proxmoxa, robiąc interfejsy typu eno1.20, eno1.30 i mosty vmbr20, vmbr30.

Którą drogą pójść? Jeżeli:

• masz jeden serwer i prosty router ISP – prosty vmbr0 bez VLANów jest najlepszym kompromisem,
• masz świadomie zrobione VLANy na routerze i zarządzalny switch – wygodniej tagować VLANy już „przy serwerze” i dawać VM konkretne mosty.

Praktyczny przykład: tworzysz VM z pfSense jako router domowy. Chcesz, by miała dwa interfejsy – WAN i LAN. W Proxmoxie:

• WAN: podłączasz VM do mostu z fizycznym portem idącym do ONT/modemu,
• LAN: drugi interfejs VM pod most wewnętrzny, którym będą się łączyły pozostałe VM/LXC (serwery), a fizycznie wychodzi na port do switcha w domu.

Zadaj sobie przy tym pytanie: czy na pewno chcesz, żeby Proxmox był twoim głównym routerem? Jeśli tak, zabezpiecz go podwójnie (UPS, backup konfiguracji, plan na wypadek awarii). Jeden błąd w pfSense potrafi odciąć cały dom od sieci.

Reverse proxy, TLS i domeny – wejście do „chmury” w domu

Dobrze poukładana sieć to jedno, ale jak sensownie wystawić usługi? W środku najczęściej nie chcesz pamiętać dziesiątek portów, a na zewnątrz – bawić się w dziwne URL-e. Rolę centralnej bramy HTTP/HTTPS pełni reverse proxy.

Najczęściej spotykane opcje:

• Traefik – bardzo lubiany w środowiskach Docker/K8s, automatyczne reguły z labeli kontenerów, automatyczny Let’s Encrypt,
• Nginx Proxy Manager – GUI do Nginxa, idealny gdy nie chcesz pisać configów,
• „surowy” Nginx lub Caddy – elastyczne, ale wymagają ręcznego podejścia.

Zadaj sobie pytanie: czy chcesz automagii, czy większej kontroli? Jeżeli wolisz konfigurować raz i zapomnieć, Traefik + docker-compose z labelami jest świetny. Gdy wolisz mieć GUI, Nginx Proxy Manager w jednym kontenerze załatwia temat.

Do pełni szczęścia dochodzi kwestia domeny:

• na LAN możesz używać lokalnych nazw typu grafana.local czy ha.mojdom – wymaga to lokalnego DNS (np. Pi-hole, AdGuard Home, Unbound),
• na zewnątrz przydaje się prawdziwa domena, nawet tania (twojadomena.pl) z rekordami A/CNAME na IP zewnętrzne.

Czy planujesz wystawiać cokolwiek na świat? Jeśli tak, odpowiedz sobie: co, dla kogo i z jakim poziomem bezpieczeństwa? Home Assistant dla siebie – ok. Panel admina Proxmoxa – zdecydowanie nie. Reverse proxy pozwala:

• zbierać ruch na jednym porcie 80/443,
• terminować TLS (Let’s Encrypt),
• ustawiać dodatkowe nagłówki bezpieczeństwa, rate limiting, podstawowe auth.

Dobry nawyk: nawet w LAN od razu korzystaj z HTTPS. Jeżeli lokalny reverse proxy rozdaje certyfikaty z własnego CA, zainstaluj to CA na swoich urządzeniach. Trochę pracy na początku, mniej kombinacji później.

Wybór sprzętu: platforma, CPU, RAM, dyski – warianty dla różnych budżetów

Jaki profil obciążenia przewidujesz?

Sprzęt dobiera się do zadań, nie odwrotnie. Zastanów się, co konkretnie chcesz uruchamiać:

• kilka lekkich usług (Home Assistant, Pi-hole, mały serwer plików, monitoring),
• cięższe rzeczy: Plex/Jellyfin z transkodowaniem, kilka baz SQL, Windows Server, może lab z Kubernetesem,
• lab pod naukę: wiele VM z różnymi systemami, testowe klastry, symulacje.

Odpowiedź od razu sugeruje klasę sprzętu:

• lekki serwer usług → mały, energooszczędny box (NUC/miniPC, ewentualnie używany thin client),
• cięższe obciążenia, ale nadal domowe → desktopowa platforma z sensownym CPU i 64+ GB RAM,
• „prawie produkcyjny” lab → workstation / serwer klasy micro-tower z ECC, większą ilością RAM i dysków.

Platforma i CPU: konsumencki, mobilny, czy serwerowy?

Na rynku masz trzy główne kategorie, każda z innym charakterem. Zadaj sobie pytanie: co ważniejsze – pobór mocy, maksymalna wydajność czy funkcje serwerowe (ECC, IPMI)?

MiniPC / NUC – cisza i oszczędność

MiniPC z CPU mobilnymi (Intel NUC, Beelink, MinisForum, seria ProDesk Mini od HP itp.) to dobry wybór, gdy:

• chcesz niskiego zużycia energii (kilka–kilkanaście watów w idle),
• nie potrzebujesz wielu dysków 3,5″,
• wystarczy Ci 32–64 GB RAM.

Zaletą jest rozmiar i kultura pracy. Taki box możesz spokojnie trzymać w salonie. Wady:

Jeśli interesuje Cię bardziej rozbudowana domowa infrastruktura (kilka urządzeń, cicha szafa rack w mieszkaniu), przyda się lektura typu Jak zbudować ciche i wydajne mini‑serwerownię w domu: praktyczne urządzenia i akcesoria dla zaawansowanych, bo mocno pomaga w przemyśleniu kwestii hałasu, przepływu powietrza i rozmieszczenia urządzeń.

• często tylko 1×NIC (choć są modele z 2.5G i więcej portów),
• ograniczona rozbudowa (zwykle 1×NVMe + 1×SATA 2,5″),
• brak ECC i IPMI, jeśli to dla Ciebie istotne.

Dla scenariusza: „1–2 VM z Dockerem, Home Assistant, parę małych baz, brak ciężkiego transkodowania wideo” taki miniPC jest zwykle optymalny.

Desktop: płyta ATX/mATX i CPU konsumencki

Klasyczny desktop ze współczesnym Ryzenem/Intelem sprawdzi się, gdy:

• chcesz więcej RAM (64–128 GB) i dysków,
• masz miejsce na większą obudowę i kilka wentylatorów,
• nie potrzebujesz typowo serwerowych dodatków, ale liczysz na dobrą wydajność per-watt.

Ryzeny z serii non-X i Intel z dopiskiem T/poniżej high-endu potrafią być naprawdę ekonomiczne przy sensownym ustawieniu BIOS/OS. Kluczowe pytanie: czy zależy Ci na ECC? Większość typowych płyt desktopowych ECC nie wspiera albo tylko „udaje” wsparcie. Jeśli planujesz trzymać ważne dane w RAM (cache ZFS, większe bazy) – warto przejrzeć listę płyt z oficjalnym wsparciem ECC dla wybranego CPU.

Sprzęt serwerowy: Xeon/Epyc, IPMI i ECC

Używane serwery (Dell PowerEdge, HP ProLiant, Supermicro) kuszą: dużo RAM, sporo dysków, IPMI, ECC. Jednak:

• potrafią być głośne,
• w idle często zużywają więcej energii niż desktop/NUC pod pełnym obciążeniem,
• część ma ograniczenia co do CPU/RAM i brak współczesnych usprawnień oszczędzania energii.

Lepszym kompromisem są płyty serwerowe/mikroserwerowe (np. Supermicro, ASUS/ASRock Rack) w zwykłej obudowie, z normalnymi wentylatorami. IPMI pozwala:

• włączać/wyłączać serwer zdalnie,
• podłączać „wirtualne” ISO z sieci,
• monitorować temperatury i prędkości wiatraków bez logowania do OS.

Zadaj sobie pytanie: czy naprawdę potrzebujesz IPMI i ECC, czy to ciekawostka do pobawienia się? Jeżeli to ma być domowy lab „do wszystkiego” i lubisz pełną kontrolę, sprzęt z IPMI szybko docenisz. Jeśli to pierwszy projekt, prostszy desktop czy NUC będzie rozsądniejszy.

RAM: ile to „w sam raz” dla Proxmoxa i Dockera?

Proxmox sam w sobie jest lekki, ale VM + kontenery i cache dysków potrafią RAM zjeść zaskakująco szybko. Zadaj sobie pytanie: ile VM chcesz trzymać jednocześnie uruchomionych i czy planujesz dużo baz danych / systemy plików typu ZFS?

Orientacyjne poziomy:

• 16 GB – minimum sensowne na dłużej, starczy na kilka lekkich VM/LXC i Dockera,
• 32 GB – komfort dla większości domowych zastosowań, jedna–dwie VM pod Dockerem, parę dodatkowych VM,
• 64 GB – gdy dochodzi ZFS, cięższe bazy, Windows w VM, lab pod K8s,
• 128 GB i więcej – typowy lab/serwer do testów większych środowisk, wielu VM równolegle.

Jeśli wahasz się między dwoma poziomami, zastanów się: czy w ciągu roku planujesz „dołożyć jeszcze kilka VM”? Jeżeli tak – weź płytę z większą liczbą slotów i od razu moduły tak dobrane, by rozbudowa była możliwa (np. 2×16 zamiast 4×8).

Dyski: system, Docker i storage danych

Dyski to punkt, gdzie łatwo popełnić błąd: upchać wszystko na jednym nośniku, a potem dziwić się, że upgrade Proxmoxa czy awaria SSD zabija wszystkie kontenery. Zadaj sobie pytanie: jakie dane są krytyczne, a jakie odtworzy docker-compose z Git-a w godzinę?

Dysk systemowy Proxmoxa

Najwygodniej jest dać Proxmoxowi osobny SSD/NVMe tylko na system i konfiguracje. Wtedy:

• upgrade Proxmoxa nie tyka danych VM (są na innym storage),
• w razie awarii systemu możesz szybciej postawić go od nowa i tylko podmontować istniejący storage.

Rozsądny rozmiar na start to 120–250 GB, ale jeśli dysk NVMe jest tani – 500 GB daje spory komfort (logi, backupy konfiguracji, dodatkowe kontenery pomocnicze).

Storage na VM/LXC i dane Dockera

Masz kilka opcji:

• jeden duży SSD/NVMe na wszystkie VM i kontenery – prostota, dobra wydajność, ale single point of failure,
• RAID1/RAIDZ na 2+ SSD/HDD – więcej bezpieczeństwa, ale kosztem liczby dysków i trochę wyższej złożoności,
• osobny NAS (Synology/TrueNAS) i Proxmox korzystający z iSCSI/NFS – dobry przy większych rozmiarach danych.

Docker sam w sobie nie wymaga RAID; ważniejsze są backupy wolumenów. Krytyczne dane (bazy, konfiguracje aplikacji) trzymaj:

• na storage z redundancją (RAID), jeśli to Twój „primary”,
• albo przynajmniej regularnie eksportuj je na inny nośnik (NAS, dysk USB, chmura).

Zastanów się też, jaką mieszankę nośników przyjmiesz. Częsty, sensowny układ: szybki NVMe pod VM i Dockera + większe HDD w RAID1/RAIDZ na „zimne” dane (backupy, multimedia, archiwa). Taki podział pomaga przy awariach – jeśli padnie dysk z kontenerami, kolekcja filmów czy migawki backupów zwykle przeżyją na drugim wolumenie. Pytanie kontrolne: czy zaakceptujesz kilkugodzinny przestój na odtworzenie wszystkiego z backupu, czy jednak chcesz, aby sprzęt przeżył awarię jednego dysku bez przerwy w pracy?

Przy planowaniu storage zastanów się, które dane są tylko cache’em, a które są źródłem prawdy. Obrazy kontenerów, build cache, pliki tymczasowe – to wszystko można zrzucić na szybszy, ale mniej krytyczny nośnik. Konfiguracje usług, bazy danych, dane użytkowników – trzymaj na wolumenach, które obejmiesz backupem i ewentualnie redundancją. Daje to też komfort przy czyszczeniu miejsca: kasujesz bez litości cache Dockera, wiedząc, że nic istotnego nie ruszasz.

Jeżeli chcesz użyć ZFS pod Proxmoxem, od razu policz RAM i planowane dyski. ZFS bardzo lubi pamięć na cache (ARC) i nie przepada za „dosztukowywanymi” co chwilę dyskami o różnym rozmiarze i wydajności. Zadaj sobie pytanie: czy faktycznie potrzebujesz snapshotów, replikacji i self-healingu ZFS, czy wystarczy prosty RAID1 na poziomie kontrolera/systemu? Dla jednego lub dwóch dysków SSD/HDD prosty układ bywa mniej skomplikowany, a i odzyskiwanie danych po awarii kontrolera jest prostsze, jeśli trzymasz się standardowych narzędzi.

Na koniec storage’u – backup ponad wszystko. Niezależnie od tego, czy postawisz ZFS, mdraid, LVM czy pojedynczy SSD, zrób plan: gdzie trzymasz kopie konfiguracji Proxmoxa, plików VM i wolumenów Dockera, jak często je testujesz i czy potrafisz z pamięci odtworzyć procedurę „awaria głównego dysku – co robię krok po kroku?”. Sprzęt, Proxmox i Docker są tylko narzędziami; bezpieczeństwo Twoich usług zaczyna się od odpowiedzi na pytanie: co się stanie, jeśli ten serwer jutro przestanie wstawać?

Energooszczędność w praktyce: od BIOS-u po ustawienia systemu

Masz już w głowie platformę i dyski. Kolejne pytanie: ile realnie chcesz płacić za prąd za ten serwer? Różnica między „na pałę” postawionym desktopem a sensownie skonfigurowaną maszyną potrafi być dwukrotna przy tym samym obciążeniu.

Konfiguracja BIOS/UEFI pod niski pobór mocy

Zacznij od miejsca, do którego rzadko się wraca: BIOS/UEFI. Tu decydujesz, czy CPU będzie umiał spaść z poborem mocy, czy będzie grzać bez sensu. Zadaj sobie pytanie: czy twój serwer większość czasu będzie się nudził, czy pracował pod stałym obciążeniem?

Przy scenariuszu „większość czasu idle, okresowe skoki” w BIOS sprawdź:

• C-states – włącz głębsze stany uśpienia CPU (C3, C6, C7), jeśli płyta i system działają stabilnie,
• SpeedStep/SpeedShift (Intel) / Cool’n’Quiet (AMD) – pozwalają dynamicznie obniżać taktowanie,
• Tryb oszczędny dla CPU (np. „Power Efficient”, „Energy Saving”) zamiast „Performance” przy stałym 24/7,
• Wyłącz zbędne kontrolery: porty COM, LPT, nieużywane SATA, kontrolery RAID, daca audio na płycie, jeśli niepotrzebne,
• Wake-on-LAN – zostaw włączone tylko na jednym interfejsie, tym który faktycznie wykorzystasz.

Po zmianach zadaj sam sobie kontrolne pytanie: czy zauważasz jakiekolwiek problemy z wybudzaniem, siecią lub dyskami? Jeżeli pojawia się niestabilność, krok po kroku przywracaj energooszczędne funkcje i obserwuj, co jest winne.

Limity mocy CPU i undervolting

Nowoczesne CPU potrafią wbić się na wysokie taktowania i ciągnąć znacznie powyżej TDP, jeśli tylko sekcja zasilania pozwoli. Dla stacji roboczej to plus, dla serwera 24/7 – często minus. Zastanów się: czy naprawdę potrzebujesz maksymalnego boosta przez cały czas?

Praktyczny schemat:

• Na platformie Intel – poszukaj opcji PL1/PL2 i ustaw niższy PL1 (np. okolice TDP) i ogranicz czas PL2. CPU nadal „wyskoczy” w górę, ale nie na długo.
• Na Ryzenach – przejrzyj ustawienia typu PPT/TDC/EDC, możesz zejść z PPT do stabilnej wartości, przy której zużycie spada, ale responsywność jest nadal OK.
• Jeżeli płyta pozwala – delikatny undervolting (obniżenie napięcia) potrafi zbić kilka watów, bez wyraźnej straty wydajności.

Po takich zmianach zadaj sobie pytanie: czy VM z Dockerem działają płynnie przy codziennym użyciu? Jeśli jedynie benchmarki „marudzą”, a w praktyce nie widzisz spowolnień, możesz zostać przy niższych limitach.

Tryby oszczędzania energii w systemie

Proxmox bazuje na Debianie, więc mechanizmy zarządzania energią są te same, co w standardowym Linuksie. Po instalacji sprawdź:

• czy governor CPU jest ustawiony na ondemand / powersave (zależnie od kernela),
• czy moduły power saving (np. intel_pstate, amd_pstate) są aktywne,
• czy dyski NVMe/SATA mają włączone odpowiednie stany oszczędzania (ale bez przesady, żeby nie „usypiać” ich co minutę).

Dobrym krokiem jest instalacja pakietów typu powertop i krótkie „profilowanie” w typowym dniu pracy. Zadaj sobie pytanie uzupełniające: czy Twój serwer działa częściej pod obciążeniem CPU, czy I/O? Od tego zależy, czy bardziej warto optymalizować procesor, czy dyski i sieć.

Usypianie wybranych usług i maszyny jako całości

Nie każdy serwer musi chodzić 24/7. Jeśli masz możliwość – zaplanuj cykl działania. Czy faktycznie potrzebujesz pełnego Proxmoxa z Dockerem w nocy, czy wystarczy kilka kluczowych usług? Odpowiedz sobie: kiedy ktoś realnie korzysta z tych VM/kontenerów?

Masz kilka podejść:

• Planowe wyłączanie VM – za pomocą Scheduled Tasks w Proxmox ustaw zatrzymywanie wybranych maszyn o 1:00 i uruchamianie o 6:00,
• Usypianie hosta (S3/S4) – wymaga sprawdzenia wsparcia BIOS/UEFI i wake-up przez RTC lub WOL,
• Zewnętrzny kontroler zasilania (inteligentne gniazdko, PDU) – w połączeniu z WOL możesz całkiem odcinać zasilanie w porach, gdy serwer jest nikomu niepotrzebny.

Jeśli wiesz, że np. codziennie od 02:00 do 06:00 nikt z domowników nie używa usług, policz sobie: ile watów oszczędzasz przez 4 godziny dziennie w skali roku? To często bardziej wymierne niż drogie „eco” komponenty.

Dobór zasilacza i chłodzenia

Zbyt mocny zasilacz, pracujący na granicy swojej minimalnej sprawności, potrafi marnować kilkanaście watów. Zadaj sobie pytanie: jakie realne TDP będzie miała twoja konfiguracja pod obciążeniem?

Jeśli całość bierze np. 60–120 W pod pełną parą, zasilacz 300–450 W 80+ Gold/Platinum zwykle pozwoli pracować w „słodkim punkcie” sprawności. Przewymiarowanie typu 850 W do lekkiej konfiguracji serwerka domowego rzadko ma sens.

Chłodzenie dobierz tak, by:

• CPU trzymał temperatury bez skoków powyżej 80–85°C przy typowym obciążeniu,
• wentylatory mogły chodzić na niskich obrotach 24/7, zamiast kręcić się szybko w krótkich „piku” temperatury,
• przepływ powietrza obejmował także dyski (szczególnie HDD).

Konfiguracja krzywych wentylatorów w BIOS/UEFI (lub IPMI) to dosłownie kilkanaście minut, a potem długie miesiące ciszy. Zastanów się: czy wolisz pracę stałą i cichą, czy ciepły, ale „skaczący” serwer?

Instalacja Proxmox krok po kroku z myślą o Dockerze

Skoro sprzęt i energetyka są mniej więcej opanowane, czas przejść do samego Proxmoxa. Zanim włożysz pendrive’a z instalatorem, odpowiedz sobie uczciwie: czy Docker ma żyć w jednej „głównej” VM, czy w kilku wyspecjalizowanych?

Przygotowanie nośnika instalacyjnego i podstawowe decyzje

Obraz ISO Proxmoxa pobierzesz ze strony producenta. Zrób bootowalny pendrive (Rufus, BalenaEtcher, dd pod Linuksem). Tu pojawia się pierwsza decyzja: EFI czy legacy BIOS? Jeśli masz sprzęt dość nowy – wybierz UEFI, ułatwia to później zarządzanie dyskami i bootloaderem.

Przy instalacji zwróć uwagę na:

• Wybór dysku systemowego – trzymaj się wcześniej przyjętej koncepcji: osobny SSD/NVMe tylko dla Proxmoxa,
• System plików – ZFS kusi, ale jeśli planujesz ZFS tylko na storage danych, często lepiej dać Proxmoxowi prosty ext4/xfs i osobny pool ZFS do VM,
• Hostname i domenę – przemyśl od razu proxmox.dom.local czy inny schemat, żeby uniknąć późniejszej zmiany nazwy hosta.

W momencie wyboru systemu plików zadaj sobie pytanie: czy planujesz migawki na poziomie hosta, czy raczej na poziomie storage’u/datastore’u? Jeśli backupy będziesz robić głównie poprzez wbudowane mechanizmy Proxmoxa, prosty layout dysków często ułatwia życie.

W tym miejscu przyda się jeszcze jeden praktyczny punkt odniesienia: Jak zbudować ciche i wydajne mini‑serwerownię w domu: praktyczne urządzenia i akcesoria dla zaawansowanych.

Sieć: mosty, VLAN-y i przygotowanie pod Dockera

Już na etapie końcówki instalacji możesz zarysować układ sieci. Pomyśl: czy Docker ma mieć kontakt tylko z siecią LAN, czy wyodrębnisz osobne sieci na lab, IoT, gości?

Standardowy schemat:

• vmbr0 – bridge na głównym interfejsie fizycznym, adres IP hosta Proxmoxa,
• dodatkowe vmbrX – mosty, do których będziesz podpinał VM/LXC z Dockerem (czasem z tagowaniem VLAN).

Jeżeli na switchu w domu masz już VLAN-y (np. osobny dla IoT), warto spiąć je z Proxmoxem. Przykład:

• vmbr0 – LAN (VLAN 1),
• vmbr10 – VLAN 10 dla labu (do testów),
• vmbr20 – VLAN 20 dla usług dostępnych z internetu (DMZ).

Zadaj sobie pytanie kontrolne: czy chcesz kiedyś wystawiać usługi Dockera bezpośrednio do internetu? Jeśli tak, od razu pomyśl o osobnym segmencie, gdzie potencjalny wyciek z kontenera nie da dostępu do całego LAN.

Podstawowa konfiguracja po instalacji

Po pierwszym logowaniu w webGUI Proxmoxa (domyślnie port 8006, HTTPS) przejdź od razu przez kilka kroków porządkowych:

• zaktualizuj system (apt update && apt full-upgrade),
• skonfiguruj repozytoria (domyślnie Proxmox ustawia enterprise repo – możesz dodać no-subscription),
• ustaw kopie zapasowe konfiguracji Proxmoxa (np. na drugi dysk lub NFS w domu).

Następnie odpowiedz sobie: jak będziesz się logował do hosta na co dzień? Jeśli SSH, to:

• zmień port (opcjonalnie),
• zablokuj logowanie hasłem, zostaw klucze,
• dodaj użytkownika nie-root i używaj sudo.

Tworzenie pierwszego storage’u pod VM i Dockera

Kolejny krok to definicja storage’u. Jeżeli masz osobny dysk/pool pod VM:

• utwórz LVM-Thin lub ZFS pool pod maszyny wirtualne,
• dane Dockera planuj na osobnym volume (LVM/ZFS), ewentualnie katalogu na tym samym dysku, ale z wyraźnym rozdziałem.

Zadaj sobie pytanie: czy chcesz, aby backupy VM i kontenerów szły na ten sam storage, czy na inny? Dla bezpieczeństwa lepiej, by backupy lądowały na innym fizycznym nośniku (np. HDD w RAID1, NAS przez NFS).

W webGUI w sekcji Datacenter → Storage możesz:

• dodać lokalne wolumeny (LVM/ZFS/Directory),
• podpiąć zasoby sieciowe (NFS, CIFS, iSCSI),
• zdefiniować, co gdzie trzymasz (ISO, backupy, dyski VM).

Układając to, odpowiedz sobie na jedno proste pytanie: czy potrafisz na kartce narysować, gdzie przechowywane są obrazy VM, dyski kontenerów Dockera i backupy? Jeśli nie – rozpisz to i uprość layout.

Warstwa wirtualizacji: VM i LXC – jak to poukładać, by Docker nie był potworem

Najczęstszy dylemat: czy Dockera uruchamiać w VM (np. Debian/Ubuntu), czy w kontenerze LXC? Każda opcja ma plusy i minusy. Pytanie pomocnicze: czy bardziej cenisz izolację i elastyczność, czy prostotę i mniejsze zużycie zasobów?

Docker w VM – klasyczny, izolowany wariant

Docker w pełnej maszynie wirtualnej to układ znany z chmur publicznych. VM to Twój „mały serwer w serwerze”, w którym sam zarządzasz systemem, firewall’em, użytkownikami.

Zalety:

• Izolacja – błąd w konfiguracji Dockera nie rozwala hosta Proxmoxa, tylko VM,
• Elastyczność – możesz zmienić dystrybucję (Debian/Ubuntu/Rocky) bez ruszania Proxmoxa,
• Prostsze migracje – przenosi się całą VM z Dockerem jako jedną jednostkę (np. na innego Proxmoxa).

Wady:

• dodatkowa warstwa wirtualizacji (VM + kontenery),
• nieco wyższe zużycie RAM i CPU niż przy LXC,
• konieczność aktualizacji kolejnego systemu (proxmox + OS w VM).

Dobrze się sprawdza scenariusz: jedna VM „infra” z Dockerem na główne usługi: reverse proxy, monitoring, Home Assistant, kilka baz. Możesz też pójść dalej i zrobić kilka VM z Dockerem, każdą pod inny „świat” (np. dom vs. lab).

Docker w LXC – lekko i blisko metalu

Kontener LXC w Proxmoxie jest bliżej hosta niż pełna VM. Dzieli jądro z Proxmoxem, ma mniejszy narzut i startuje w sekundy. Jeśli pytasz siebie: „czy liczy się każdy wat i każdy gigabajt RAM?” – LXC często wygrywa.

Plusy takiego podejścia:

• Niższe zużycie zasobów – brak pełnej wirtualizacji sprzętu, mniej procesów systemowych,
• Szybki start i restart – kontener z Dockerem wstaje niemal natychmiast,
• Łatwe backupy – Proxmox świetnie radzi sobie z migawkami LXC i ich przywracaniem.

Minusem jest to, że LXC nie jest pełną maszyną. Niektóre funkcje jądra czy mechanizmy sieciowe mogą zachowywać się inaczej niż w klasycznym serwerze. Trzeba zadbać o odpowiednie features w konfiguracji kontenera (m.in. keyctl, cgroup2, ewentualne nesting), żeby Docker nie potykał się o ograniczenia. Zadaj sobie pytanie: czy chcesz czasem kombinować z flagami w configu LXC, czy wolisz „standardowy” Linux w VM?

Dobry schemat na start: jeden LXC z Dockerem na usługi, które możesz w razie problemu szybko odtworzyć (np. usługi pomocnicze, małe aplikacje webowe), a rzeczy krytyczne albo bardziej „wymagające” przenieść do VM. Pozwala to sprawdzić, jak czujesz się z tym typem izolacji, bez stawiania wszystkiego na jedną kartę.

Jedna „gruba” instancja Dockera czy kilka mniejszych?

Gdy już wybierzesz, czy Docker ma siedzieć w VM, czy w LXC, pojawia się kolejne pytanie: wszystko w jednym „docker-host”, czy podział na kilka środowisk? Odpowiedz sobie szczerze: jak ogarniasz porządek w stackach, sieciach i docker-compose? Jeśli wiesz, że po pół roku nie będziesz pamiętał, co gdzie działa, lepszy może być podział logiczny.

Popularny podział wygląda tak: jedna instancja Dockera „prod” na usługi domowe (reverse proxy, DNS, Home Assistant, monitoring), druga „lab/test” na eksperymenty, trzeci host (czasem tylko LXC) na rzeczy półpubliczne, wystawione do internetu. Dzięki temu możesz np. zrestartować „lab” bez ryzyka, że cała rodzina straci dostęp do TV i automatyki domu. Zastanów się: które usługi są „święte” i nie mogą znikać w środku dnia?

Jeśli masz mało RAM, lepsza bywa jedna VM/LXC z dobrze uporządkowanymi sieciami Dockera (oddzielne bridge, sieci typu frontend/backend, wydzielona sieć dla baz danych). Gdy zasobów jest więcej – łatwiej utrzymać porządek, mając 2–3 instancje Dockera z jasno opisanymi rolami. Kluczem nie jest „idealna” architektura, tylko taka, którą będziesz w stanie zrozumieć po roku.

Zasady porządkowania: CPU, RAM i dyski pod Dockera

Niezależnie od tego, czy Docker działa w VM czy LXC, przyda się kilka prostych reguł. Po pierwsze: przydziel sensowny limit RAM. Zadaj sobie pytanie: ile realnie potrzebujesz dla systemu i usług, a ile chcesz zostawić Proxmoxowi na inne maszyny i cache dyskowy? Zbyt „gruba” VM z Dockerem potrafi zjeść wszystko i zostawić inne VM z zadyszką.

Po drugie, CPU. Dla większości domowych zastosowań wystarczy kilka vCPU przypisanych do hosta Dockera, z włączonym ballooningiem RAM, jeśli korzystasz z VM. Gdy stawiasz heavy-load (np. transkodowanie wideo, analityka, ElasticSearch) – rozważ osobną VM tylko pod ten typ obciążeń. Pomyśl: które kontenery mają prawo „przydusić” CPU, a które muszą działać płynnie zawsze (np. DNS, reverse proxy)?

Po trzecie, dyski. Zastanów się, gdzie faktycznie trzymasz /var/lib/docker i dane kontenerów: logi, bazy, uploady użytkowników. Dobrą praktyką jest osobne volume na dane aplikacyjne (bind-mounty lub dedykowany katalog/ZFS dataset), tak aby w razie awarii lub wymiany hosta móc szybko podnieść nową instancję Dockera i tylko podpiąć istniejący zestaw wolumenów. Zadaj sobie pytanie: czy potrafisz wyłączyć hosta Dockera, skasować go i odtworzyć z backupu, nie tracąc niczego istotnego poza samą infrastrukturą kontenerów?

Włóż też trochę energii w kontrolę „śmieci”: logi, stare obrazy, nieużywane wolumeny. Ustaw rotację logów (np. przez logging w docker-compose albo logrotate w systemie), zaplanuj okresowe docker system prune i monitoruj wolne miejsce na storage’u. Przydomowy serwer często „umiera” logicznie nie przez awarię dysku, ale przez zapełnienie partycji na 100%. Pytanie pomocnicze: skąd się dowiesz, że przestrzeń się kończy – z alertu monitoringu czy dopiero z błędów w aplikacjach?

Przydzielając zasoby, używaj limitów na poziomie kontenerów: cpus, mem_limit, klasy QoS w Kubernetesie (jeśli tam dojdziesz), a w prostszej wersji – --cpus i -m w docker run. Krytyczne usługi (reverse proxy, DNS, VPN, broker MQTT) powinny mieć niewielkie, ale gwarantowane minimum, a cięższe zadania (media server, narzędzia deweloperskie) mogą dostać limit maksymalny i priorytet „drugiej kategorii”. Zadaj sobie pytanie: który kontener może się „dusić”, a który musi być responsywny nawet przy uruchomieniu backupu lub skanie AV?

Na koniec spójrz na całość jak na projekt, nie jednorazową zabawkę. Masz Proxmoxa jako bazę, nad nim VM lub LXC z Dockerem, pod spodem sensownie zaplanowane storage’e i limity zasobów. Jeśli na każdym etapie potrafisz odpowiedzieć: „dlaczego to tak ustawiłem i jak to odtworzę po awarii?”, to jesteś w dobrym miejscu. Reszta to już tylko cykliczne poprawki, testy backupów i świadome dokładanie nowych klocków do układanki.

Na koniec warto zerknąć również na: EdgeRouter vs MikroTik: pojedynek budżetowych zawodników — to dobre domknięcie tematu.

Sieć pod Proxmoxem i Dockerem – jak nie zrobić spaghetti

Zanim zaczniesz klikać „Add → Linux Bridge” w Proxmoxie, odpowiedz sobie: ile światów chcesz mieć w swojej sieci? Dom, lab, goście, IoT, „publiczne” usługi wystawione z portfowardingu? Jeśli wszystko wrzucisz w jeden worek (jeden bridge, jeden VLAN), szybciej zapełnisz reguły firewall’a niż dysk.

Prosta metoda to narysować warstwy:

• warstwa WAN – router/ONT od dostawcy,
• warstwa LAN – Twój główny router/firewall (np. osobna VM z OPNsense/pfSense lub fizyczne urządzenie),
• segmenty VLAN – osobne podsieci dla „normalnych” urządzeń, IoT, serwera, labu.

Zastanów się: czy chcesz, aby Twój domowy serwer był tylko klientem w sieci, czy też centralnym routerem/firewallem? To kluczowa decyzja.

Prosty wariant: serwer jako zwykły host w istniejącej sieci

Jeśli nie chcesz przerabiać całej infrastruktury, serwer może być po prostu kolejnym urządzeniem w LAN. Wtedy:

• tworzysz w Proxmoxie jeden vmbr0 podpięty do fizycznej karty sieciowej,
• VM/LXC dostają klasyczne adresy z Twojej sieci (DHCP lub statyczne),
• routing, NAT, VPN obsługuje zewnętrzny router (np. od ISP albo własny sprzęt z OpenWRT).

Plus jest taki, że mniej rzeczy może się zepsuć. Minus: trudniej sensownie odseparować lab, IoT i usługi półpubliczne, jeśli router nie wspiera VLAN-ów albo ma słaby firewall. Zadaj sobie pytanie: czy Twój obecny router ogarnia VLAN-y, reguły per podsieć i VPN na tyle dobrze, żeby nie przenosić tych zadań na Proxmoxa?

Bardziej zaawansowany wariant: Proxmox jako „serwer usług” z VLAN-ami

Jeśli switch i router wspierają VLAN-y, możesz trzymać routing na zewnętrznym urządzeniu, a Proxmoxa wykorzystać tylko jako hosta dla serwerów w różnych podsieciach. Układ bywa wtedy taki:

• vmbr0 – trunk VLAN z routera,
• do tego vmbr0.10 (serwery prod), vmbr0.20 (lab), vmbr0.30 (IoT),
• poszczególne VM/LXC podpinasz do odpowiedniego interfejsu VLAN (w konfiguracji sieci w Proxmoxie).

Sieci Dockera możesz dalej porządkować wewnątrz tych podsieci (osobne bridge’e w Dockerze dla frontu, backendu, baz). Dzięki temu:

• kontenery prod nigdy nie lądują w tej samej L2 sieci co eksperymentalny lab,
• IoT ma kontakt tylko z tym, co musi, a nie z całym stackiem Dockera.

Zastanów się: czy wolisz mieć 2–3 sensownie opisane VLAN-y, czy jeden gigantyczny /24 z 50 wpisami w firewallu? Im więcej masz urządzeń i usług, tym bardziej VLAN-y zaczynają wygrywać.

Router/firewall jako VM w Proxmoxie – kuszące, ale czy na pewno?

Popularny pomysł: zrobić w Proxmoxie VM z OPNsense/pfSense i uczynić ją głównym routerem domu. Fajne? Tak. Ale zadaj sobie kilka niewygodnych pytań:

• co się dzieje przy starcie serwera? Proxmox musi wstać, żeby wstał router, żeby reszta sieci miała internet,
• co się dzieje przy aktualizacji Proxmoxa? Cały dom traci sieć na czas rebootu,
• czy masz plan B, jeśli Proxmox nie wystartuje (np. padnie dysk z systemem)?

Jeśli bardzo chcesz router w VM, zadbaj przynajmniej o:

• osobny, możliwie prosty storage dla VM z routerem (np. mały SSD, mirror),
• konfigurację autostart i najwyższy priorytet bootowania tej VM,
• dodatkowy, fizyczny „awaryjny” router w szufladzie (choćby tani router z trybem PPPoE/NAT).

Zapytaj sam siebie: czy internet może zniknąć całemu domowi, jeśli będziesz bawić się w migrację Proxmoxa? Jeśli odpowiedź brzmi „to byłby dramat”, lepiej rozważ zostawienie podstawowego routingu na fizycznym urządzeniu.

Bezpieczeństwo: od Proxmoxa po kontenery Dockera

Domowy serwer jest kuszącym celem – ma stały dostęp do internetu, stoi włączony non stop, często bez regularnych aktualizacji. Kluczowe pytanie: co jest Twoim modelem zagrożeń? Czy boisz się bardziej przypadkowego skasowania danych, czy włamania przez usługę wystawioną na świat?

Proxmox jako „twierdza” – zamknij drzwi na zewnątrz

Na początek jedna zasada: interfejs web Proxmoxa nie powinien być wystawiony bezpośrednio do internetu. Dostęp do panelu zarządzającego całym serwerem tylko przez:

• VPN do sieci domowej (WireGuard/OpenVPN na osobnej VM lub routerze),
• tunel SSH z port forwardem,
• ewentualnie ZeroTier/Tailscale, jeśli wolisz gotowe rozwiązania SD-WAN.

Zastanów się: jak dziś dostałbyś się do Proxmoxa z zewnątrz? Jeśli pierwsza myśl to „ustawić port forwarding 8006 → świat” – zatrzymaj się. Poszukaj wariantu z VPN.

Na samym Proxmoxie:

• ustaw silne hasło dla root lub – lepiej – konto nie-root + sudo w shellu,
• rozważ logowanie przez SSH key, wyłącz PasswordAuthentication,
• odpal prosty firewall na poziomie hosta (Proxmox Firewall/iptables/nftables) z zasadą „domyślnie blokuj, pozwalaj tylko z zaufanych podsieci”.

VM/LXC – podsieci, firewall, strefy zaufania

Podejdź do tego jak do planowania mieszkania: gdzie są drzwi wewnętrzne, a gdzie zewnętrzne? Możesz zdefiniować:

• strefę „DMZ” – VM/LXC/host Dockera z usługami wystawionymi do internetu (WWW, poczta, VPN),
• strefę „LAN prod” – usługi tylko dla domowników (NAS, Home Assistant, monitoring),
• strefę „lab” – miejsce na eksperymenty, z ograniczonym dostępem do reszty.

Routing między tymi strefami nie powinien być „na pałę”. Odpowiedz sobie: które usługi w DMZ muszą rozmawiać z LAN, a które nie? Reverse proxy może potrzebować dostępu do backendów w LAN, ale kontener z blogiem raczej nie musi zaglądać do sieci IoT.

Firewall stawiaj blisko punktu styku:

• reguły na routerze między podsieciami,
• ewentualnie dodatkowe reguły wewnątrz samego hosta Dockera (np. ufw/iptables),
• ograniczenia na poziomie Dockera (sieci typu internal, brak ekspozycji portów na hosta).

Docker: minimalne uprawnienia zamiast „byle działało”

Domowy Docker często wygląda tak: --privileged, -v /:/host i nadzieja, że nic się nie stanie. Zanim uruchomisz taki kontener, zadaj sobie pytanie: co się stanie, jeśli aplikacja w środku zostanie przejęta? Wariant „ma dostęp do całego hosta” raczej nie jest tym, czego chcesz.

Prosty zestaw zasad:

• unikać --privileged, chyba że naprawdę wiesz, po co to robisz,
• stosować read-only filesystem tam, gdzie się da,
• bind-mounty zawężać do konkretnych katalogów z danymi, zamiast montować cały /,
• uruchamiać kontenery na nie-rootowych użytkownikach (user namespaces, albo przynajmniej user: 1000:1000 w docker-compose),
• ograniczać dostęp sieciowy – osobne sieci Dockera, brak publikowania portów na 0.0.0.0, gdy nie trzeba.

Zastanów się przy każdym kontenerze: jakie minimalne uprawnienia są mu potrzebne, żeby spełnił swoją rolę? To samo pytanie zadawaj, gdy konfigurujesz wolumeny z danymi.

Aktualizacje, backup konfiguracji i test „czy wstanie po wszystkim”

Bezpieczeństwo to nie tylko firewall. To też:

• regularne aktualizacje Proxmoxa (repo pve-no-subscription zamiast kombinowania z mirrorami, jeśli nie masz subskrypcji),
• aktualizacje wewnątrz VM/LXC (cron/Ansible/apt-get upgrade),
• aktualizacje obrazów Dockera (watchtower lub ręczna polityka update’ów).

Jednocześnie warto mieć kopię nie tylko danych, ale i konfiguracji:

• eksport konfiguracji Proxmoxa (/etc/pve – backup przez Proxmox Backup Server lub zwykłe kopie),
• backup plików docker-compose.yml, traefika/caddy/nginx, configów VM,
• zewnętrzne repozytorium Git na definicje infrastruktury (bez haseł wprost w plikach!).

Zadaj sobie proste pytanie kontrolne: czy potrafisz odtworzyć całą konfigurację Dockera i Proxmoxa na czystym serwerze, mając tylko backupy danych i repo z plikami konfiguracyjnymi? Jeśli nie – uporządkuj to, zanim pojawi się pierwsza poważniejsza awaria.

Monitoring i obserwowalność: żeby wiedzieć, kiedy coś zaczyna się psuć

Domowy serwer bez monitoringu to trochę jak auto bez deski rozdzielczej – jedziesz, dopóki nie zobaczysz dymu. Jak chcesz się dowiadywać o problemach: przypadkiem, czy z powiadomień?

Co monitorować na poziomie Proxmoxa

Zacznij od podstaw, bez rozbudowanych platform APM. Przyda się:

• obciążenie CPU, RAM, swapu,
• zapełnienie storage’y (lokalne i sieciowe),
• stan SMART dysków (ilość realokowanych sektorów, temperatury),
• uptime VM/LXC, restart Proxmoxa.

Możesz skorzystać z:

• wbudowanych wykresów Proxmoxa (dobry start, ale bez alertów),
• Prometheus + node_exporter/proxmox-exporter → Grafana,
• prostszych rozwiązań jak Netdata czy Zabbix w lekkiej konfiguracji.

Najważniejsze: ustaw alerty na dyski i RAM. Zanim serwer stanie, lepiej dostać maila/wiadomość na komunikator, że któryś z wolumenów dobija do 90%. Zadaj sobie pytanie: jak najszybciej dowiesz się, że backupy przestały działać albo storage jest pełny?

Monitoring Dockera i usług

Na poziomie Dockera trzy obszary dają największą wartość:

• zdrowie kontenerów (czy działają, czy restartują się w pętli),
• zużycie zasobów per kontener (CPU, RAM, I/O),
• logi aplikacyjne (błędy, time-outy, problemy z bazą).

W praktyce możesz zrobić np. taki stack:

• cAdvisor lub docker metrics eksportowany do Prometheusa,
• Grafana z dashboardami dla hosta Dockera i wybranych kontenerów,
• Stack logów: Loki/Grafana, ELK lub prostszy syslog do pliku + logrotate.

Jeżeli nie masz ochoty na cały Prometheus, netdata w kontenerze potrafi dać szybki pogląd na to, co się dzieje. Kluczowe pytanie: czy w razie zgłoszenia „TV nie działa” potrafisz w 2–3 minuty sprawdzić, czy problemem jest CPU, RAM, sieć czy konkretna usługa?

Alerty: e-mail, komunikatory, a może „dashboard na ścianie”

Sam monitoring bez powiadomień jest tylko „ładnym wykresem”. W domowych warunkach dobrze działają:

• maile z serwera (np. przez SMTP dostawcy poczty),
• integracje Grafany/Zabbixa z Telegramem, Signalem, Matrixem,
• tablet/telefon na ścianie z odpaloną stroną z dashboardem (np. w Home Assistant).

Pomyśl: gdzie najszybciej zauważysz czerwony alert? Jeśli rzadko zaglądasz do poczty, ale zawsze masz pod ręką komunikator – tam kieruj powiadomienia. Jednocześnie nie przesadź: dziesiątki błędnych alertów sprawią, że zaczniesz je ignorować.

Dobrze działa prosty podział: krytyczne alerty (brak miejsca na dysku, niedziałający backup, niedostępny Proxmox) wysyłasz tam, gdzie i tak reagujesz od razu, a resztę zostawiasz jako „cisze” w dashboardach. Zastanów się: które zdarzenia są dla ciebie naprawdę krytyczne, a które mogą poczekać do wieczornego przeglądu? Ustal 2–3 progi ważności i na tej podstawie buduj reguły powiadomień, zamiast oznaczać wszystko jako „PILNE”.

Jeśli lubisz mieć coś namacalnego, możesz zrobić mały „command center”: tablet z Grafaną/Home Assistantem na ścianie, obok którego przechodzisz kilka razy dziennie. Dla wielu osób to skuteczniejsze niż najbardziej wyrafinowane alerty mailowe. Pytanie pomocnicze: gdzie fizycznie najczęściej patrzysz w ciągu dnia – w ekran telefonu, monitor w biurze, a może wspomniany tablet w kuchni?

Z czasem możesz dołożyć proste automatyczne reakcje na część alertów. Przykład: gdy monitoring wykryje, że jedna z usług w Dockerze nie odpowiada przez określony czas, skrypt w kontenerze „watchdog” wykona docker restart i dopiero jeśli to nie pomoże, wyśle powiadomienie. Zastanów się przy każdym alercie: czy potrzebna jest ręczna interwencja, czy da się wykonać pierwszy krok automatycznie, bez twojego udziału.

Domowy serwer pod Proxmoxem i Dockerem potrafi być jednocześnie szybki, cichy i bezproblemowy – pod warunkiem, że wcześniej ustalisz, po co go budujesz, dobrze rozplanujesz warstwę sprzętową i sieć, a później będziesz konsekwentnie trzymać się zasad: minimalne uprawnienia, regularne backupy, proste monitorowanie. Przejdź jeszcze raz po swoich notatkach: czy wiesz już, jaki ma być pierwszy cel tej maszyny, jaki budżet i jaką architekturę wybierasz na start? To jest moment, żeby te decyzje doprecyzować, zanim klikniesz „zamawiam” przy pierwszym podzespole.

Najczęściej zadawane pytania (FAQ)

Czy w domu w ogóle ma sens stawianie serwera na Proxmoxie i Dockerze?

Ma sens wtedy, gdy rozwiązuje realny problem, a nie jest tylko zabawką. Zastanów się: czy cierpisz na chaos w danych (kilka chmur, dyski USB, laptopy), brak porządnych backupów, brak miejsca do nauki Dockera/Kubernetesa, czy chcesz uniezależnić się od zewnętrznych usług?

Jeśli odpowiedziałeś „tak” na przynajmniej jedno z tych pytań, domowy serwer Proxmox + Docker może być dobrym krokiem. Jeżeli natomiast jedynym celem jest „mieć coś w racku, bo fajnie wygląda”, prawdopodobnie wystarczy Ci prosty NAS lub pojedyncza maszyna z Linuxem i Dockerem bez dodatkowego poziomu abstrakcji.

Proxmox czy „goły” Linux z Dockerem – co wybrać do domowego serwera?

Najpierw odpowiedz sobie: jaki masz cel – chcesz prostego środowiska do kilku usług, czy małego homelaba z VM-kami, VLAN-ami i różnymi dystrybucjami? Jeśli zależy Ci głównie na aplikacjach (Plex, Home Assistant, Nextcloud), to „goły” Debian/Ubuntu + Docker będzie najprostszy w utrzymaniu.

Proxmox ma sens, gdy:

• planujesz kilka VM (np. osobno: serwer Dockera, osobno Windows, osobno lab testowy),
• chcesz łatwo robić snapshoty i backup całych maszyn,
• uczyć się bliżej „jak działa chmura”.

To dodatkowa warstwa, ale daje elastyczność. Zadaj sobie pytanie: czy chcesz zarządzać infrastrukturą, czy tylko aplikacjami?

Czy lepiej uruchamiać Dockera w VM, w LXC czy bezpośrednio na Proxmoxie?

Najbezpieczniejszy i najbardziej uniwersalny wariant to Docker w osobnej VM (np. Debian/Ubuntu). Tworzysz jedną mocniejszą VM, instalujesz tam Dockera i docker-compose, a Proxmox służy do snapshotów, backupów i ewentualnej migracji na inny sprzęt. Gdy coś popsujesz, odtwarzasz snapshot VM zamiast ratować cały serwer.

Docker w LXC daje niższy narzut, ale wymaga kombinowania z uprawnieniami (privileged, nesting) i dobrej orientacji w bezpieczeństwie. Docker bezpośrednio na hoście Proxmoxa jest możliwy, lecz mieszasz wtedy warstwę zarządzającą (hypervisor) z warstwą aplikacyjną – naprawa po awarii staje się trudniejsza. Pytanie do Ciebie: bardziej cenisz prostotę hosta czy minimalny overhead?

Jak zaplanować role dla istniejących urządzeń: NAS, Raspberry Pi, stary laptop?

Najpierw spisz, co już masz: NAS, router z USB, Raspberry Pi, może stary laptop w szafie. Następnie zadaj pytanie: czy to ma być jeden centralny serwer, czy kilka urządzeń współpracujących ze sobą? Częsty sensowny układ to:

• NAS – tylko na dane i backupy,
• Proxmox – „mózg” infrastruktury (VM, LXC, sieć, snapshoty),
• Raspberry Pi – funkcje pomocnicze (monitoring, mały reverse proxy, zdalny syslog).

Jeśli coś już jest krytyczne (np. NAS z rodzinnymi zdjęciami), nie migruj tego „na hurra”. Zrób plan: najpierw uruchom Proxmoxa obok, potestuj Dockera, a dopiero potem stopniowo przenoś usługi. Zadaj sobie pytanie: co może przestać działać na 1–2 dni bez dramatu, a co absolutnie nie?

Kiedy domowy homelab staje się „systemem produkcyjnym” i co wtedy zmieniać?

Produkcja zaczyna się w momencie, gdy awaria serwera wywoła realne konsekwencje: rodzina nie ma dostępu do zdjęć, nie działa światło i ogrzewanie, nie możesz wejść przez VPN do sieci domowej czy pracy. Krótko: jeśli czyjeś nerwy albo praca zależą od tego serwera, to jest to produkcja, nawet jeśli stoi pod biurkiem.

W takiej sytuacji musisz:

• zaplanować backup Proxmoxa i konfiguracji Dockera (nie tylko samych danych),
• mieć pomysł na odtworzenie po awarii dysku systemowego,
• przestać robić rewolucyjne upgrady „w piątek wieczorem”.

Zastanów się: czy zaakceptujesz kilka godzin przerwy, czy celem jest maksymalne ograniczenie przestojów? Od tego zależy, ile inwestujesz w redundancję i testy.

Jak ustalić priorytety przy budowie domowego serwera Proxmox + Docker?

Najpierw odpowiedz na jedno kluczowe pytanie: jaka pierwsza rzecz ma „przestać boleć”, gdy serwer zacznie działać? Backup laptopów? Bezpieczne trzymanie zdjęć? Media w całym domu? A może środowisko do nauki Dockera i CI/CD? Od tej pierwszej odpowiedzi zależą:

• architektura (ile VM, gdzie trzymasz dane),
• dobór dysków (więcej pojemności vs wydajność),
• budżet energetyczny (ile Wat możesz „oddać” na stałe 24/7).

Nie próbuj rozwiązać wszystkiego jednocześnie. Zacznij od jednego priorytetu, działającego end‑to‑end (np. porządny backup wszystkich domowych sprzętów), potem dokładamy media, a na końcu homelab do eksperymentów. Zadaj sobie pytanie: co mnie naprawdę będzie wkurzać, jeśli dalej nie będzie ogarnięte za miesiąc?

Jak pogodzić energooszczędność z serwerem działającym 24/7?

Najpierw policz w głowie, czy 20 W czy 50 W ciągłego poboru ma dla Twojego budżetu znaczenie. Jeśli tak, celuj w sprzęt energooszczędny (małe platformy x86, iGPU zamiast dedykowanej grafiki, dyski 2,5″ lub SSD tam, gdzie nie potrzebujesz talerzowych magazynów). Zapytaj siebie: jakie usługi rzeczywiście muszą być 24/7, a co może startować na żądanie?

Od strony Proxmoxa i Dockera możesz:

• usypiać lub wyłączać część VM, które nie muszą chodzić non stop (np. lab testowy),
• pilnować, by kontenery nie mieliły CPU w tle bez potrzeby (monitoring, logi),
• unikać nadmiernie rozbudowanego klastra, jeśli stoisz w mieszkaniu, a nie w serwerowni.

Dbaj o to, by serwer był cichy i chłodny – jeżeli stoi w salonie lub sypialni, komfort domowników bywa ważniejszy niż dodatkowe 10% wydajności.

Kluczowe Wnioski

• Domowy serwer z Proxmox i Dockerem ma rozwiązać konkretne problemy (backup, media, self‑hosting, homelab), a nie być „gadżetem” – najpierw zadaj sobie pytanie, jaki dokładnie ból ma zniknąć.
• Priorytety (backup, multimedia, nauka, automatyzacja) decydują o architekturze i sprzęcie – zanim kupisz cokolwiek, ustal, co ma działać jako pierwsze i jak krytyczne są dla ciebie te usługi.
• Często już masz zalążek serwera w domu (router z USB, Raspberry Pi, stary laptop, gotowy NAS) – zamiast wszystko wyrzucać, określ jasne role: co będzie magazynem danych, a co „mózgiem” z Proxmoxem i Dockerem.
• Różnica między „fajnym projektem na weekend” a systemem 24/7 jest ogromna – jeśli rodzina będzie tam trzymać zdjęcia i korzystać z usług codziennie, potrzebujesz stabilności, sensownego backupu i planu aktualizacji.
• Granica „to już produkcja” pojawia się wtedy, gdy awaria boli (np. brak światła z powodu Home Assistanta lub utrata zdjęć) – wtedy trzeba myśleć o odtwarzaniu Proxmoxa, konfiguracji Dockera i kopiach ustawień, nie tylko o samych danych.
• Zużycie energii, hałas i ciepło z serwera 24/7 realnie wpływają na komfort w mieszkaniu – sprawdź, czy stać cię na 50 W non stop i czy nie wystarczy ci sprytna, energooszczędna maszyna zamiast „potwora” pod biurkiem.