Convoy panel – czy to najlepszy panel KVM dla Twojego hostingu?

Kluczowe funkcje Convoy panel w zarządzaniu maszynami wirtualnymi

Konwencjonalne narzędzia do administracji KVM-ami często przypominają kombajny sprzed dekady: interfejsy przeładowane zakładkami, kosmiczne ceny za licencję i zerowe wsparcie dla Proxmox. Convoy panel idzie pod prąd tej filozofii. Zbudowany jako lekki open-core wrapper na API Proxmox, daje administratorowi hostingowi dokładnie to, czego potrzebuje w codziennej pracy: provisioning w sekundach, billing bez excela i API, które woła się samo.

• Kluczowe funkcje Convoy panel w zarządzaniu maszynami wirtualnymi
• Convoy panel vs płatne rozwiązania enterprise porównanie kosztów
• Jak wdrożyć Convoy panel krok po kroku na Proxmox
• Convoy panel bezpieczeństwo i najlepsze praktyki dla adminów

Dla kogo powstał ten panel? Przede wszystkim dla providerów hostingu, którzy sprzedają maszyny wirtualne w modelu self-service. Sprawdzi się też w homelabach zarządzanych przez jednego admina oraz w firmach MSP obsługujących dziesiątki klientów końcowych na wspólnym klastrze Proxmox. Kluczowe pozostaje, że narzędzie celuje w scenariusze, gdzie liczy się szybkość wdrożenia i przewidywalność kosztów.

Centralnym miejscem panelu pozostaje lista węzłów i VM-ów. Start, stop, reset, reinstalacja systemu operacyjnego z gotowego szablonu wszystko działa spod jednego przycisku. Akcje idą przez kolejkę Laravel, więc nawet przy kilkudziesięciu równoczesnych żądaniach interfejs nie zamiera na kilkanaście sekund. To różnica w porównaniu z rozwiązaniami enterprise, gdzie proste włączenie maszyny potrafi zajmować pół minuty przez warstwę SOAP i webserwisy.

Provisioning zasługuje na osobny akapit. Nowy serwer powstaje w kilka sekund, bo panel korzysta z klonowania szablonu na hypervisorze zamiast klasycznej reinstalacji przez sieć. Administrator definiuje gotowe obrazy (Debian, Ubuntu, Rocky, Alma, Windows), przypisuje im plany taryfowe i gotowe. Klient sam wybiera konfigurację z panelu klienta, a system automatycznie tworzy VM, ustawia sieć i wysyła mail z danymi dostępowymi.

Moduł billingowy zamyka pętlę. Integracja z Blesta, WHMCS lub własnym silnikiem fakturującym odbywa się przez REST API i webhooki. Faktura generuje się w chwili aktywacji usługi, a panel sam wyłącza VM, gdy płatność nie wpłynie w oknie prolongaty. Takie rozwiązanie zdejmuje z administratora obowiązek codziennego przeglądania tabelek w arkuszu kalkulacyjnym i eliminuje błędy wynikające z ręcznego przepisywania danych.

Skoro już o integracji mowa, warto wymienić najważniejsze elementy stacku technologicznego. Rdzeń stanowi PHP 8.2 z frameworkiem Laravel 11, a frontend bazuje na React 18 z Tailwind CSS. Komunikacja z Proxmox realizowana jest przez dedykowany wrapper oparty o Guzzle HTTP. Całość można uruchomić w kontenerze Docker razem z redisem, workerem kolejki i schedulerem, co upraszcza deployment nawet na pojedynczym VPS-ie.

Porównanie kluczowych możliwości

Zwróć uwagę na jedną rzecz: każda z tych funkcji powstała z konkretnego problemu operatora hostingu. Twórcy panelu sami prowadzili infrastruktury na Proxmox i znali ból ręcznego klikania w konsoli webowej hypervisora. Dlatego interfejs prowadzi użytkownika ścieżką „klient zamówił plan → system tworzy VM → billing wystawia fakturę” bez zbędnych ekranów pośrednich.

Convoy panel vs płatne rozwiązania enterprise porównanie kosztów

Temat pieniędzy w hostingu budzi emocje. Licencja klasycznego panelu enterprise potrafi kosztować tyle, co kilka serwerów dedykowanych rocznie. Convoy panel proponuje inny model: rdzeń open source za darmo dla projektów niekomercyjnych, a wariant komercyjny w przedziale 6 dolarów za węzeł miesięcznie. Dla klastra pięciu nodów oznacza to 30 dolarów miesięcznie, czyli mniej niż najtańszy plan konkurencji.

Zanim porównamy tabelkę, wyjaśnijmy kryteria. Bierzemy pod uwagę realny koszt wdrożenia w pierwszym roku: licencję, czas pracy administratora potrzebny na konfigurację, infrastrukturę pomocniczą (load balancer, baza, monitoring) oraz koszty aktualizacji i wsparcia technicznego. Dopiero suma tych składników pokazuje prawdziwy Total Cost of Ownership.

Liczby nie kłamią. W skali dwunastu miesięcy różnica sięga kilku tysięcy dolarów, a przy klastrze 20 węzłów przekracza dziesięć tysięcy. Pieniądze te można przeznaczyć na szybsze łącze, lepszy backup albo po prostu niższą cenę dla klienta końcowego, co w konkurencyjnym rynku hostingu ma realne przełożenie na pozyskiwanie zamówień.

Drugą osią porównania pozostaje czas wdrożenia. Panele enterprise wymagają zazwyczaj kilku dni roboczych na instalację, podpięcie hypervisora, konfigurację sieci VLAN, podpisanie umowy licencyjnej i przeszkolenie personelu. Convoy stawia na kontener Docker, w którym startujesz komendą docker compose up -d. Po kwadransie masz działający panel z domyślnym kontem administratora.

Nie oznacza to, że rozwiązania enterprise nie mają sensu. Jeśli prowadzisz dostawcę hostingu z umową SLA 99,99% i klientami korporacyjnymi wymagającymi wsparcia 24/7, możesz potrzebować rozbudowanego systemu ticketowego, modułów compliance i wieloletniego wsparcia producenta. W takim scenariuszu Convoy panel sprawdzi się jako narzędzie drugiej linii albo środowisko testowe przed migracją.

Kluczowy argument dotyczy vendor lock-in. Panele enterprise przechowują konfigurację w bazach, do których nie masz bezpośredniego dostępu. Migracja na inny system oznacza zazwyczaj ręczne przepisywanie setek planów taryfowych. Convoy trzyma dane w bazie MySQL/MariaDB dostępnej dla administratora. Eksport do SQL, import na nową instancję, koniec tematu.

Jak wdrożyć Convoy panel krok po kroku na Proxmox

Przejdźmy do konkretów. Instalacja panelu dzieli się na cztery etapy: przygotowanie infrastruktury, deploy aplikacji, konfiguracja węzłów Proxmox i podpięcie systemu billingowego. Całość przy odrobinie wprawy zajmuje mniej niż godzinę, a większość czasu pochłania samo czekanie na pobranie obrazów kontenerów.

Wymagania wstępne

Potrzebujesz serwera panelu (VPS lub bare-metal) z minimum 2 rdzeniami CPU, 4 GB RAM i 40 GB dysku SSD. System operacyjny: Debian 12 lub Ubuntu 22.04 LTS. Wymagany jest również dostęp do co najmniej jednego węzła Proxmox VE w wersji 7.4 lub nowszej z włączonym API i utworzonym tokenem o uprawnieniach PVEAdmin. DNS musi wskazywać domenę na adres IP serwera panelu, a certyfikat TLS najlepiej wygenerować przez Let's Encrypt jeszcze przed startem kontenera.

Konfiguracja węzła Proxmox wymaga trzech kroków: utworzenia użytkownika z rolą PVEAdmin (nie root!), wygenerowania tokenu API oraz dodania go do pliku /etc/pve/user.cfg. Mechanizm tokenów działa tak, że każde żądanie REST podpisujesz kluczem, a Proxmox weryfikuje uprawnienia po stronie hypervisora bez potrzeby przechowywania haseł w panelu.

Instalacja przez Docker

Najszybsza ścieżka prowadzi przez repozytorium Git i gotowy plik docker-compose.yml. Po sklonowaniu repozytorium edytujesz plik .env, ustawiając dane dostępowe do bazy MariaDB, klucze API Proxmox oraz adres URL panelu. Komenda docker compose up -d uruchamia kontenery: aplikację PHP-FPM, Nginx, Redis, worker kolejki oraz scheduler. W tle startuje migracja bazy danych i seed domyślnego konta administratora.

Konfiguracja przez Composer pozostaje alternatywą dla zespołów, które wolą klasyczny stack LAMP. Wymaga PHP 8.2 z rozszerzeniami PDO, Redis, BCMath oraz Node.js 20+ do zbudowania frontendu. Po composer install i npm run build uruchamiasz php artisan serve tylko do testów, a produkcję obsługuje Nginx z PHP-FPM.

Podpięcie węzłów Proxmox

W panelu administracyjnym wchodzisz w sekcję Infrastruktura, dodajesz nowy klaster i wpisujesz adres IP, port 8006, identyfikator tokenu oraz sekret. Panel automatycznie weryfikuje połączenie, pobiera listę VM-ów i synchronizuje stan węzła. Pierwsza synchronizacja trwa kilkanaście sekund; kolejne odbywają się w tle co 60 sekund przez mechanizm poll, a zmiany krytyczne (start, stop) przesyłane są natychmiastowo przez webhook z hypervisora.

Tworzenie szablonów systemu operacyjnych odbywa się w sekcji Szablony. Wgrywasz obraz ISO lub korzystasz z gotowych szablonów cloud-init dostępnych w repozytorium Proxmox. Definiujesz minimalną i maksymalną liczbę rdzeni, zakres RAM, rozmiar dysku oraz sieć (bridge, VLAN, IPv4, IPv6). Szablon zapisujesz pod unikalną nazwą, np. debian-12-minimal, i przypisujesz do planów taryfowych widocznych dla klienta końcowego.

Integracja z systemem billingowym

Blesta jako partner domyślny integruje się przez natywny moduł dostępny w katalogu Convoy. Po wgraniu modułu podajesz URL panelu i klucz API, a Blesta zaczyna pobierać listę planów, tworzyć usługi przy zamówieniu i wysyłać żądania wstrzymania po upływie terminu płatności. Konfiguracja trwa kilkanaście minut, a cała komunikacja idzie przez REST + webhooki z podpisem HMAC SHA-256.

Dla środowisk korzystających z WHMCS przygotowano osobny moduł z porównywalną funkcjonalnością. Jeśli budujesz własny system fakturowania, wystarczy zaimplementować trzy webhooki: utworzenie usługi, wstrzymanie i wznowienie. Pełna dokumentacja API w formacie OpenAPI 3.1 pozwala wygenerować klienta w języku Python, Go lub Node bez ręcznego czytania specyfikacji.

Provisioning w praktyce

Klient loguje się do panelu klienta, wybiera plan (np. 2 vCPU, 4 GB RAM, 50 GB SSD, Debian 12), klika Zamów. Panel wysyła żądanie do API Proxmox z komendą klonowania szablonu, ustawia parametry maszyny, konfiguruje sieć przez cloud-init i wysyła mail z danymi dostępowymi w czasie 8-12 sekund. Tak szybki czas wynika z tego, że klonowanie szablonu to operacja kopiowania bloków na poziomie systemu plików ZFS lub Ceph, a nie reinstalacja systemu przez sieć.

Convoy panel bezpieczeństwo i najlepsze praktyki dla adminów

Bezpieczeństwo w panelu hostingu to temat rzeka. Każdy nieaktualizowany komponent, każdy otwarty port to potencjalny wektor ataku. Convoy panel daje administratorowi konkretne narzędzia, ale wymaga świadomej konfiguracji. Poniższa checklista powstała z doświadczeń zespołów wdrażających panel w środowiskach produkcyjnych o różnej skali.

Uwierzytelnianie i kontrola dostępu

Dwuskładnikowe uwierzytelnianie (2FA) przez TOTP powinno być obowiązkowe dla każdego konta administratora. Panel obsługuje standard RFC 6238, więc dowolna aplikacja typu Google Authenticator, Authy czy 1Password zadziała bez problemu. Mechanizm polega na tym, że po podaniu hasła serwer wymaga jednorazowego kodu ważnego przez 30 sekund, generowanego na podstawie sekretu i czasu.

Klucze SSH dla maszyn wirtualnych najlepiej generować po stronie panelu przy pierwszym logowaniu i przechowywać w formie zaszyfrowanej w bazie. Domyślne hasło ustawiane przez cloud-init powinno być jednorazowe, wymuszające zmianę przy pierwszym kontakcie przez SSH. Takie podejście eliminuje scenariusz, w którym nowa maszyna wisi w sieci przez kilka minut z domyślnym hasłem znanym atakującemu.

Hardening serwera panelu

Serwer panelu powinien pracować na czystym Debianie bez zbędnych pakietów. Wyłącz logowanie roota przez SSH, wymuś klucze, zmień port SSH z 22 na niestandardowy. Fail2ban z regułą dla nginx i panelu loguje powtarzające się nieudane próby logowania i blokuje adres IP na 15 minut. Po stronie firewalla otwierasz wyłącznie porty 443 (HTTPS) i SSH (niestandardowy), wszystko inne pozostaje domknięte.

Kontenery panelu warto uruchamiać w sieci Docker z izolacją od sieci hosta. Komunikacja z bazą MariaDB odbywa się po wewnętrznym interfejsie, a Redis nasłuchuje tylko na localhost. Pliki wrażliwe (klucze API, certyfikaty) montujesz jako sekrety Docker zamiast zmiennych środowiskowych, co utrudnia ich wyciek przez logi czy zrzuty pamięci.

Izolacja sieciowa klientów

Każdy klient powinien pracować w osobnym VLAN-ie albo VXLAN-ie. Proxmox wspiera oba rozwiązania, a panel przy tworzeniu VM automatycznie przypisuje VLAN na podstawie wybranego planu. Dzięki temu klient A nie wypinguje klienta B nawet w ramach tego samego węzła. Mechanizm sieciowy w Proxmox działa na poziomie mostu linuxowego, gdzie ramki są filtrowane przez reguły ebtables zanim trafią do interfejsu klienta.

Firewall na poziomie hypervisora (reguły iptables lub nftables ładowane przez API) blokuje ruch wychodzący na port 25 dla maszyn wirtualnych bez opcji „mail relay”. Ogranicza to przypadki, w których zhakowany VM kliencki rozsyła spam, co mogłoby skutkować wpisaniem adresu IP węzła na publiczne blacklisty i problemami z dostarczalnością poczty dla pozostałych klientów.

Backupy i odtwarzanie

Convoy panel integruje się z Proxmox Backup Server przez dedykowany moduł. Definiujesz politykę: backup co 24 godziny, retencja 7 dni dla przyrostowych i 4 tygodnie dla pełnych, kopia poza serwerownię (np. do S3 lub Backblaze B2). Odtwarzanie pojedynczej maszyny sprowadza się do wyboru punktu w czasie i kliknięcia Przywróć. Mechanizm działa tak, że PBS przesyła jedynie bloki zmienione od ostatniej kopii, co na łączu 1 Gbps pozwala zbackupować klaster 10 TB w około 90 minut.

Nie zapomnij o backupie samej bazy panelu. MariaDB replikowana asynchronicznie na osobny host lub zrzucana raz na godzinę przez mysqldump to absolutne minimum. Bez tego odtworzenie konfiguracji klientów, planów taryfowych i kluczy API po awarii zajmie tygodnie.

Monitoring i alerty

Prometheus + Grafana pozostaje standardem w środowiskach Proxmox. Convoy panel udostępnia endpoint metryk w formacie Prometheus, więc zbierasz dane o liczbie VM-ów, obciążeniu kolejki, opóźnieniach API i czasie provisioningu. Alertmanager powiadamia o sytuacjach krytycznych: pula wolnych adresów IPv4 spadła poniżej 5%, jeden z węzłów nie odpowiada dłużej niż 3 minuty, dysk panelu przekroczył 80% pojemności.

Logi zbierasz w Loki albo Elasticstack. Każda akcja administracyjna pozostawia ślad z identyfikatorem użytkownika, adresem IP, znacznikiem czasu i typem operacji. Takie audytowanie bywa nieocenione przy analizie incydentów albo podczas audytu zgodności z RODO, gdzie musisz wykazać, kto i kiedy uzyskał dostęp do danych konkretnego klienta.

Lista kontrolna hardeningu

• 2FA włączone dla wszystkich administratorów panelu
• Klucze SSH zamiast haseł dla każdej nowej maszyny wirtualnej
• Fail2ban z regułami dla nginx i aplikacji panelu
• Firewall z domyślną polityką DROP, otwarte wyłącznie 443 i SSH
• Izolacja VLAN/VXLAN między klientami na każdym węźle
• Blokada portu 25 dla VM bez autoryzowanego relay
• Backup incrementalny co 24h, retencja 7+28 dni, kopia offsite
• Monitoring Prometheus z alertami Telegram/Email/SMS
• Aktualizacje panelu i hypervisora w cyklu miesięcznym
• Raz na kwartał audyt uprawnień użytkowników i tokenów API

Zastosowanie pełnej checklisty nie wyklucza incydentów, ale radykalnie zmniejsza prawdopodobieństwo scenariusza, w którym pojedynczy kompromitowany panel kliencki staje się przepustką do całej infrastruktury. Bezpieczeństwo to proces, nie jednorazowa konfiguracja, więc powyższe punkty warto traktować jako punkt wyjścia, nie metę.

Jeśli prowadzisz hosting na Proxmox i szukasz narzędzia, które skróci dystans między zamówieniem klienta a działającą maszyną, Convoy panel zasługuje na przynajmniej godzinę testów. Środowisko developerskie stawiasz w kontenerze Docker na darmowym VPS, podpinasz jeden węzeł Proxmox w wersji evaluation i przechodzisz przez pełny provisioning. Jedna godzina wystarczy, żeby ocenić, czy panel pasuje do Twojego stosu.

Źródła danych i dokumentacji: oficjalne repozytorium projektu (github.com/ConvoyPanel), dokumentacja Proxmox VE API (pve.proxmox.com/pve-docs/), specyfikacja OpenAPI 3.1 dla endpointów panelu, dokumentacja frameworku Laravel 11 (laravel.com/docs), RFC 6238 dla standardu TOTP, oraz materiały Proxmox Backup Server dostępne na stronie producenta.