Convoy panel – koniec z chaosem w zarządzaniu serwerami Proxmox

Piąta rano, dwudziesty węzeł Proxmox do podpięcia, a panel, którego używasz od trzech lat, właśnie wyrzucił timeout na trzecim kroku provisioningu. Brzmi znajomo? Większość administratorów hostingu traci nawet kilkanaście godzin tygodniowo na mozolne klikanie przez interfejsy, które nie rozmawiają ze sobą przez API. Convoy panel serwerowy Proxmox powstał właśnie po to, żeby ten konkretny ból wyciąć u podstaw i po roku w środowiskach produkcyjnych widać, że nietuzinkowe podejście do warstwy abstrakcji faktycznie zmienia rachunek ekonomiczny małych i średnich providerów.

• Czym właściwie jest Convoy i dlaczego akurat Proxmox, Laravel i Rust
• Dla kogo Convoy ma sens, a komu skradnie czas
• Kluczowe funkcje Convoy, które oszczędzają godziny pracy
• Convoy vs Pterodactyl i Virtualizor uczciwe porównanie
• Instalacja Convoy krok po kroku na własnym nodzie
• Cennik, licencja BSL i kiedy Convoy nie ma sensu
• API i rozszerzenia kiedy trzeba podywagować integracjami
• Roadmapa i społeczność co dalej z Convoy

Czym właściwie jest Convoy i dlaczego akurat Proxmox, Laravel i Rust

Convoy to panel sterowania, który siada na wierzchu klastra Proxmox VE i udostępnia jednolity interfejs do zarządzania maszynami wirtualnymi, kontenerami LXC oraz adresacją IP. Fundament stanowi Proxmox, bo to jeden z niewielu hypervisorów klasy enterprise, który działa w pełni na otwartym kodzie i obsługuje zarówno KVM, jak i LXC bez dodatkowych licencji. Warstwę prezentacji trzyma Laravel, czyli dojrzały framework PHP z wbudowanym ORM, kolejkami i systemem autoryzacji dzięki temu każda operacja na VM przechodzi przez transakcyjną bazę danych zamiast lecieć bezpośrednio do API Proxmoxa.

Backend komunikacji z nodami napisano w Rust, co w tym kontekście nie jest fanaberią. Rust gwarantuje przewidywalne czasy odpowiedzi nawet przy kilkuset równoległych żądaniach REST, a kompilowany binarnie agent nie ciągnie za sobą runtimu ani interpretera mniejsze zużycie RAM na każdym węźle roboczym, mniejsza powierzchnia ataku. Trzy filary (Proxmox + Laravel + React/Rust) układają się więc w dość logiczną triadę: sprawdzony hypervisor, dojrzała warstwa aplikacyjna, bezpieczny i szybki orkiestrator.

Architektura składa się z trzech elementów: panelu (aplikacja web), agenta instalowanego na każdym nodzie Proxmox oraz warstwy IPAM, która pilnuje, żeby żadne dwa VM-y nie wylądowały na tym samym adresie. Panel wysyła żądanie HTTP do agenta, agent tłumaczy je na natywne wywołanie API Proxmoxa (`pvesh`), a wynik wraca w formacie JSON. Dzięki takiemu rozdziału ról można postawić panel na zupełnie innym serwerze niż węzły robocze, co w przypadku awarii pojedynczego hosta pozwala zarządzać pozostałymi bez przestoju.

Convoy powstał w 2020 roku z inicjatywy jednego maintainera i małego zespołu w Performave. Projekt żyje na GitHubie, liczy już ponad 4 tysiące commitów i jest rozwijany w modelu open-core: kod panelu jest publiczny, ale zaawansowane moduły (SSO, audyt, multi-tenant) działają na licencji BSL. To kompromis, który ma zapewnić finansowanie dalszego rozwoju bez zamykania społeczności coś, z czym boryka się choćby Pterodactyl.

Dla kogo Convoy ma sens, a komu skradnie czas

Najlepiej odnajdą się tutaj trzy grupy. Pierwsza: hostingodawcy prowadzący od pięciu do dwustu węzłów Proxmox, którzy potrzebują wspólnego kokpitu dla zespołu wsparcia zamiast konsoli SSH na każdym hoście osobno. Druga: entuzjaści homelab z kilkoma serwerami w szafie rackowej, którzy chcą udostępniać zasoby rodzinie albo znajomym bez pisania skryptów w Bashu. Trzecia: agencje MSP obsługujące infrastrukturę kilkunastu klientów jednocześnie, gdzie ręczne przeliczanie przydziałów CPU i RAM między projektami to codzienność.

Z drugiej strony istnieją scenariusze, w których Convoy nie pomoże. Przy klastrach liczących ponad tysiąc aktywnych VM-ów lepiej spisze się natywny interfejs Proxmox lub rozwiązania typu OpenStack. W środowiskach, gdzie kluczowe są certyfikowane stosy pod regulacje (HIPAA, PCI DSS Level 1), warto poczekać na większą bazę referencyjną panel jest stosunkowo młody. Jeśli nie korzystasz z Proxmox VE 7.4+, lepiej zostać przy obecnym stacku: Convoy świadomie nie wspiera starszych wersji ze względu na zmiany w API.

Kluczowe funkcje Convoy, które oszczędzają godziny pracy

Dashboard w czasie rzeczywistym zbiera metryki CPU, RAM, dysków i ruchu sieciowego ze wszystkich nodów w jednym widoku. Dane lecą przez agenta Rust co pięć sekund, więc opóźnienie między akcją a wyświetleniem jest minimalne. To ważne przy diagnostyce przeciążonego węzła nie musisz logować się osobno, żeby sprawdzić, czy problem siedzi w dysku czy w procesorze.

Wbudowany terminal webowy działa jako odwrotny tunel SSH przez agenta, więc nawet za NAT-em dostajesz pełną konsolę do VM-a bez otwierania portu 22 na zewnątrz. Każde połączenie logowane jest z timestampem i nazwą użytkownika, co przy późniejszym audycie oszczędza godziny żmudnego przeszukiwania journalctl.

IPAM (zarządzanie adresacją IP) trzyma pulę adresów, przypisuje je do VM-ów i pilnuje, żeby żaden duplikat nie wylądował w dwóch miejscach jednocześnie. Mechanizm opiera się na blokadach w bazie MySQL: gdy system rezerwuje adres, równoległe żądanie czeka na zwolnienie transakcji. W praktyce eliminuje to klasyczny błąd, kiedy dwóch techników ręcznie wpisuje te same końcówki IP.

Wsparcie multi-node oznacza, że z jednego panelu sterujesz dziesiątkami fizycznych serwerów rozsianych po różnych lokalizacjach. Convoy traktuje każdy node jako autonomiczną jednostkę z własnymi limitami, ale udostępnia wspólne konto użytkownika, wspólną bazę VM-ów i wspólne API. Przydaje się to szczególnie w edge computingu, gdzie serwery stoją w różnych datacenter.

REST API pokrywa praktycznie każdą akcję dostępną z GUI: tworzenie, restart, migrację na żywo, snapshot, kasowanie. Autoryzacja idzie przez tokeny Bearer, a każde żądanie można opcjonalnie podpisać webhookiem zwrotnym. Dzięki temu łatwo podpiąć Convoy pod skrypty provisioningowe albo panel klienta końcowego.

SSO przez OAuth2/OIDC działa z Keycloak, Authentik, Google Workspace i Microsoft Entra. Jednorazowa konfiguracja w panelu administracyjnym i każdy kolejny pracownik loguje się firmowym kontem bez osobnego hasła w Convoy. Moduł SSO jest częścią edycji komercyjnej; w wersji open-source znajdziesz jedynie lokalne konta.

Convoy vs Pterodactyl i Virtualizor uczciwe porównanie

Pterodactyl Panel od lat króluje w segmencie hostingu gier i prostych aplikacji webowych. Napisany w Node.js, świetnie radzi sobie z kontenerami Docker, ale zupełnie nie obsługuje prawdziwego KVM ani LXC. Jeśli Twoi klienci potrzebują pełnych maszyn wirtualnych z własnym kernelem, Pterodactyl odpadnie na starcie. Convoy natomiast wchodzi w pełne KVM i LXC przez API Proxmoxa, więc dla dostawców VPS to zupełnie inna liga.

Virtualizor to rozwiązanie komercyjne z licencją od 9,95 USD miesięcznie za serwer, bez wersji open-source. Ma solidne wsparcie wielu hypervisorów (KVM, Xen, OpenVZ), ale kosztem elastyczności: kernel panelu jest zamknięty, a API w niektórych endpointach wymaga osobnej zgody vendor. Convoy w modelu open-core daje kod panelu do wglądu, a API jest w pełni publiczne i stabilne wersjonowane.

Jeśli prowadzisz wyłącznie hosting kontenerowy dla aplikacji webowych i gier, Pterodactyl wciąż będzie tańszy i szybszy do opanowania. Jeśli natomiast Twoja działka to klasyczny VPS z pełnym rootem, własnymi kernelami i migracją na żywo między węzłami Convoy wygrywa stosunkiem ceny do funkcji.

Instalacja Convoy krok po kroku na własnym nodzie

Convoy działa jako zestaw kontenerów Docker, więc na maszynie z panelem potrzebujesz minimum 2 vCPU, 4 GB RAM i 40 GB dysku SSD. Na każdym węźle roboczym Proxmox wymaga Proxmox VE 7.4 lub nowszego, 2 GB RAM zarezerwowane dla agenta oraz otwartego portu 8443 w kierunku panelu.

Uwaga: Convoy nie obsługuje Proxmox VE 6.x i starszych. Powód? W starszych wersjach API `pvesh` zwraca dane w formacie, który łamie kontrakt JSON narzucony przez agenta Rust. Aktualizacja Proxmoxa przed instalacją Convoy nie jest opcjonalna.

Krok pierwszy to pobranie pliku `.env` z repozytorium i uzupełnienie kluczowych zmiennych: `APP_URL`, `DB_PASSWORD`, `PANEL_PORT`. Krok drugi to uruchomienie `docker compose up -d`, co postawi kontenery panelu, kolejki Redis i bazy MySQL w tle. Krok trzeci: wygenerowanie pierwszego konta administratora przez `php artisan convoy:admin` komenda poprosi o e-mail i hasło, a następnie utworzy token API.

Czwarty krok to dodanie pierwszego noda. W panelu administracyjnym wchodzisz w sekcję Nodes, klikasz Add Node, wpisujesz adres IP, nazwę użytkownika Proxmox i token API. Panel wysyła żądanie HTTPS do agenta na porcie 8443, agent je weryfikuje i zwraca listę VM-ów oraz LXC już istniejących na tym hoście. Od tego momentu widzisz je w jednym dashboardzie razem z kolejnymi nodami.

Piąty krok to deploy pierwszego serwera. Wybierasz node, klikasz Create VM, podajesz nazwę, ilość RAM, liczbę rdzeni, rozmiar dysku i obraz ISO albo gotowy template Cloud-Init. Agent przez API Proxmoxa tworzy maszynę wirtualną, przypisuje jej adres z puli IPAM i zwraca identyfikator. Całość zajmuje od 30 sekund do dwóch minut, w zależności od szablonu.

Szósty krok to weryfikacja przez terminal webowy. Klikasz w nowo utworzony VM, otwierasz Console, logujesz się po SSH i sprawdzasz, czy adres IP zgadza się z tym, co zarezerwował IPAM. Jeśli tak masz działający provisioning. Jeśli nie najczęściej chodzi o konflikt mostka sieciowego w Proxmox, który rozwiążesz edycją pliku `/etc/network/interfaces` na węźle.

Protip: Przed wejściem na produkcję ustaw automatyczne backupy przez wbudowany moduł Snapshot. Convoy robi migawkę dysku co 24 godziny, trzyma siedem ostatnich kopii i synchronizuje je z wybraną lokalizacją przez rsync albo S3.

Cennik, licencja BSL i kiedy Convoy nie ma sensu

Model cenowy Convoy jest prosty: 6 USD miesięcznie za każdy zarządzany węzeł Proxmox w edycji komercyjnej. Przy pięciu nodach daje to 30 USD miesięcznie, czyli mniej niż jedna dniówka technika. Organizacje non-profit, szkoły i instytucje badawcze mogą ubiegać się o darmową licencję na podstawie prostego formularza, który weryfikuje status prawny.

Licencja BSL (Business Source License) działa jak bufor czasowy: przez pierwsze trzy lata od wydania wersji kod jest dostępny do wglądu i modyfikacji, ale nie można go wykorzystywać komercyjnie bez opłaty. Po trzech latach licencja automatycznie przekształca się w Apache 2.0, co oznacza pełną otwartość. Ten model pozwala twórcom żyć z pieniędzy od komercyjnych użytkowników, jednocześnie gwarantując społeczności, że kod prędzej czy później wróci do domeny publicznej.

Convoy nie ma sensu w trzech sytuacjach. Pierwsza: prowadzisz jeden serwer Proxmox na domowym labie i nie potrzebujesz centralnego panelu wystarczy natywny interfejs webowy Proxmox. Druga: skala powyżej pięciuset nodów wymaga już rozwiązań klasy OpenStack albo komercyjnych platform typu Nutanix. Trzecia: potrzebujesz certyfikowanego stosu pod audyt SOC 2 Convoy wciąż nie ma gotowych pakietów compliance, choć roadmap wspomina o module audytu w przyszłej edycji.

API i rozszerzenia kiedy trzeba podywagować integracjami

REST API Convoy działa na schemacie autoryzacji Bearer token i zwraca JSON w standardowej konwencji REST. Endpointy obejmują `/api/nodes`, `/api/servers`, `/api/users`, `/api/ipam/pools` i kilkadziesiąt innych. Każde żądanie można dodatkowo podpisać webhookiem zwrotnym, żeby system zewnętrzny (np. własny panel klienta) reagował na zdarzenia typu server.created albo node.offline.

Minimalny przykład tworzenia VM-a przez API wygląda tak:

curl -X POST https://panel.example.com/api/servers 
  -H "Authorization: Bearer TWÓJ_TOKEN" 
  -H "Content-Type: application/json" 
  -d '{
    "node_id": 2,
    "hostname": "klient-01",
    "ram_mb": 2048,
    "cpu_cores": 2,
    "disk_gb": 40,
    "template": "ubuntu-22-04-cloud"
  }'

W odpowiedzi dostajesz identyfikator serwera, jego aktualny status (provisioning, running, offline) oraz zarezerwowany adres IP. Ten sam endpoint przez webhook może odpalić dalszą automatyzację np. skrypt Ansible, który dokończy konfigurację aplikacji po postawieniu VM-a.

Webhooki konfigurujesz w panelu administracyjnym, w sekcji Webhooks. Podajesz URL, listę zdarzeń, które chcesz otrzymywać, oraz opcjonalny sekret HMAC do podpisu payloadu. Convoy wysyła żądanie POST z nagłówkiem `X-Convoy-Signature`, w którym znajdziesz sumę kontrolną SHA-256. Weryfikacja tego podpisu po stronie odbierającej chroni przed podszywaniem się pod panel.

Roadmapa i społeczność co dalej z Convoy

W publicznej roadmapie na najbliższe kwartały znalazły się trzy duże elementy. Pierwszy to natywna integracja z Ceph jako storage backend dzięki temu Convoy przejmie obsługę replikacji trzykrotnej bezpośrednio z poziomu GUI, bez konieczności konfigurowania RBD po stronie Proxmoxa. Drugi to moduł audytu zgodny z wymaganiami ISO 27001, z eksportem logów do SIEM. Trzeci to refaktor agenta Rust na architekturę multi-thread z workerami, co skróci czas provisioningu dużych flot VM-ów o połowę.

Społeczność Convoy kręci się wokół serwera Discord (około trzech tysięcy aktywnych użytkowników), forum dyskusyjnego oraz cotygodniowych spotkań online w strefie UTC. Maintainer aktywnie odpowiada na issues na GitHubie i publikuje release notes z dokładnym opisem zmian. To projekt, który rośnie organicznie, bez agresywnego marketingu kolejna różnica wobec rozwiązań czysto komercyjnych.

Jeśli prowadzisz mały lub średni hosting oparty o Proxmox i chcesz przestać tracić czas na ręczne klikanie w konsolę SSH, Convoy stanowi dziś jedną z najbardziej sensownych opcji w segmencie open-core. Dla entuzjastów homelab największą barierą może być potrzeba posiadania choćby dwóch nodów, żeby w pełni wykorzystać multi-node ale nawet przy jednym węźle zyskujesz spójne API i porządny IPAM. Sprawdź repozytorium, przeklikaj demo na stronie projektu albo dołącz do Discorda resztę dopowiesz sobie sam w trakcie pierwszej godziny z dokumentacją.

Źródła danych i dokumentacja:

• Dokumentacja Convoy (oficjalna strona projektu, convoy.io)
• Repozytorium kodu źródłowego (github.com/ConvoyPanel)
• Dokumentacja Proxmox VE 7.4 i 8.x (pve.proxmox.com/pve-docs)
• Specyfikacja licencji BSL (mariadb.com/bsl11)
• Forum społeczności Convoy na Discordzie (discord.gg/convoy)