← Blog
DevOps16 min czytania

1Panel — otwarty panel do zarządzania VPS z wbudowanym agentem AI

1Panel to panel administracyjny dla serwerów Linux na licencji GPLv3: kontenery, strony WWW z certyfikatami Let's Encrypt, kopie na S3 i warstwa AI z zarządzaniem modelami oraz serwerami MCP. Pokazujemy instalację, hartowanie dostępu i to, gdzie panel pomaga przy projekcie w Laravelu, a gdzie lepiej zostać przy własnym Compose.

1Panel to otwarty panel administracyjny do serwerów Linux, rozwijany przez FIT2CLOUD i udostępniony na licencji GPLv3. Wersja 2 poszła w stronę, którą producent opisuje jako „lightweight AI management platform”: obok klasycznego zestawu (pliki, kontenery, bazy, strony WWW, kopie zapasowe) w panelu siedzi zarządzanie modelami językowymi, agentami i serwerami MCP. Repozytorium 1Panel-dev/1Panel zebrało ponad 36 tysięcy gwiazdek, a wydanie 2.2.5 wyszło 7 sierpnia 2026, więc projekt ma się dobrze.

Sprawdziliśmy, co realnie daje w codziennej pracy z serwerami klientów, gdzie kończy się wersja darmowa i którędy przebiega granica między wygodą a ryzykiem.

Co 1Panel bierze na siebie

Panel instaluje się na czystym VPS-ie i przejmuje obsługę rzeczy, które w innym wypadku robisz z SSH:

  • Docker — kontenery, obrazy, sieci, wolumeny, rejestry prywatne i osobna zakładka na projekty Compose wraz z szablonami.
  • Strony WWW — OpenResty jako reverse proxy, przypisanie domeny, grupy witryn, certyfikat z Let's Encrypt przez ACME wraz z odnawianiem.
  • Środowiska uruchomieniowe — PHP, Node.js, Java, Golang, Python i .NET, każde jako osobny kontener.
  • Bazy danych — MySQL, PostgreSQL i Redis z podglądem oraz zarządzaniem użytkownikami.
  • App Store — ponad 165 aplikacji open source jednym kliknięciem (m.in. Gitea, Nextcloud, MinIO, Uptime Kuma, Bitwarden, Zabbix, phpMyAdmin).
  • Kopie i snapshoty — zadania cykliczne zrzucające dane na zewnętrzny storage plus migawka całego panelu.
  • System — monitoring zasobów, firewall, Fail2ban, procesy, terminal w przeglądarce, zarządzanie SSH, skaner antywirusowy, FTP, Supervisor.
  • AI — modele przez Ollamę i TensorRT-LLM, agenci, serwery MCP oraz monitoring GPU.

Jedno ograniczenie warto znać od razu, bo bywa rozstrzygające przy pracy zespołowej: 1Panel obsługuje jedno konto użytkownika na host. Nie ma kont per pracownik, ról ani podziału uprawnień. Jeśli panelu ma używać kilka osób, dzielą się jednym loginem, a audyt „kto co zrobił” opiera się wyłącznie na logach systemowych.

Instalacja

Wymagania są skromne: dystrybucja oparta o Debiana albo RedHata, architektura x86_64, aarch64, armv7l, ppc64le, s390x lub riscv64, minimum 1 GB wolnej pamięci i dostęp do internetu. Instalacja to jeden skrypt:

bash -c "$(curl -sSL https://resource.1panel.pro/v2/quick_start.sh)"

Skrypt wykrywa architekturę, pobiera paczkę z resource.1panel.pro, weryfikuje jej sumę SHA-256 wobec pliku checksums.txt i dopiero wtedy uruchamia instalator, który zapyta o port, ścieżkę wejściową, nazwę użytkownika i hasło. Zmienna INSTALL_MODE przełącza między kanałem stable a dev; na produkcji zostaw domyślny. Na końcu w konsoli pojawia się adres:

http://<IP-serwera>:<port>/<security-entrance>

Ten ostatni człon to losowa ścieżka, bez której panel nie odpowiada. Jeśli zgubisz dane logowania, odzyskasz je po SSH:

1pctl user-info

Hartowanie dostępu, zanim wpuścisz tam kogokolwiek

Panel administracyjny ma pełną władzę nad hostem: terminal, pliki, kontenery, bazy. Traktuj go jak cel ataku, nie jak wygodny dashboard. W sekcji Panel Settings → Security ustaw wszystko, co jest dostępne:

  • Panel Port — nietypowy port zamiast domyślnego; zajętość sprawdzisz przez netstat -tunlp | grep [port].
  • Security Entrance — własna ścieżka wejściowa. Bez niej panel zwraca skonfigurowaną treść zamiast formularza logowania, więc skaner portów nie dowie się, że pod tym adresem cokolwiek stoi.
  • Allowed IPs — biała lista adresów, najlepiej ograniczona do adresu biura albo wyjścia z VPN-a.
  • Listen Address — ograniczenie interfejsu, na którym panel nasłuchuje; 1pctl listen-ip ipv4 przełącza go z powrotem, gdy przesadzisz.
  • Domain Binding — logowanie tylko przez konkretną domenę.
  • Panel SSL — wymuszone HTTPS.
  • MFA — drugi składnik TOTP, opcjonalnie Passkey (wymaga SSL i zaufanej domeny).
  • Password Expiration i Password Complexity — wymuszona rotacja hasła oraz minimum 8 znaków z literami, cyframi i symbolami.
  • Session Timeout — wylogowanie po bezczynności, minimum 300 sekund.

Zaostrzenie reguł potrafi zamknąć drogę do panelu. Furtką awaryjną jest 1pctl po SSH:

1pctl reset entrance   # wyłącza ścieżkę wejściową
1pctl reset ips        # czyści białą listę adresów
1pctl reset domain     # zdejmuje przypięcie domeny
1pctl reset https      # wyłącza wymuszone HTTPS
1pctl reset mfa        # wyłącza drugi składnik

1pctl update port      # zmiana portu panelu
1pctl update password  # zmiana hasła

Aktualizuj bez zwłoki. W 2025 i 2026 roku projekt załatał między innymi obejście weryfikacji certyfikatu w komunikacji core–agent prowadzące do wykonania poleceń (CVE-2025-54424, wersje do 2.0.5) i obejście CAPTCHA w API logowania otwierające drogę do automatycznego zgadywania haseł (CVE-2025-66507, wersje przed 2.0.14). Panel wystawiony do internetu bez białej listy adresów i MFA jest atrakcyjnym celem.

Strona WWW: OpenResty, runtime PHP i certyfikat

Ścieżka „od zera do działającej strony” wygląda tak: instalujesz OpenResty i bazę z App Store, tworzysz środowisko PHP, zakładasz witrynę i wskazujesz jej runtime, na końcu wystawiasz certyfikat.

Środowisko PHP to kontener zbudowany z oficjalnego obrazu php:X.Y-fpm, opakowany przez 1Panel. Warto wiedzieć, co dokładnie dostajesz w środku, bo to zmienia sposób pracy:

  • Composer wgrany globalnie jako /usr/bin/composer, ze zmienną COMPOSER_HOME=/tmp/.composer.
  • Skrypt install-php-extensions, którym panel dokłada rozszerzenia z poziomu interfejsu, bez schodzenia do docker exec.
  • Supervisor jako proces główny kontenera, dzięki czemu obok PHP-FPM da się trzymać dodatkowe procesy rezydentne.
  • www-data przemapowany na UID i GID 1000, co oszczędza typowej wojny o uprawnienia do plików między hostem a kontenerem.
  • Katalog roboczy /www, a na hoście /opt/1panel/runtime/php/<nazwa>.

Obrazy publikowane są jako 1panel/php:<wersja>-fpm dla amd64, arm64 i arm/v7. Repozytorium nadąża za wydaniami PHP: w sierpniu 2026 dostępne są tagi aż do 8.5.9, więc nowoczesnego Laravela odpalisz bez kompromisów. Panel obsługuje też gałęzie 5.x i 7.x, co bywa jedynym ratunkiem przy przejmowaniu starej aplikacji po innym wykonawcy. Alternatywnie wskażesz lokalne php-fpm zainstalowane wprost na hoście, jeśli konteneryzacja z jakiegoś powodu odpada.

Rozszerzenia dokładasz i zdejmujesz przyciskiem Extensions na liście środowisk, konfigurację php.ini edytujesz z poziomu panelu, a w Process Daemon dopisujesz procesy, które mają żyć obok FPM-a. Katalog runtime'u da się skopiować na maszynę bez dostępu do internetu i wystartować tam zwykłym docker compose up — to oficjalna ścieżka dla wdrożeń offline.

Certyfikaty załatwia wbudowany klient ACME (projekt utrzymuje własny fork lego). Zakładasz konto ACME, opcjonalnie konto dostawcy DNS przy weryfikacji DNS-01 i certyfikatach wildcard, a odnawianie idzie zadaniem cyklicznym. Panel przyjmie też certyfikat wgrany z zewnątrz albo wystawi self-signed na potrzeby środowiska testowego.

Laravel: co oddać panelowi, a co zostawić sobie

Runtime PHP w wersji FPM obsłuży aplikację, której document root wskazuje na public/. Problem zaczyna się przy tym, co odróżnia projekt Laravela od zwykłej strony: kolejki, scheduler, cache, Reverb. Panel ma na to dwa miejsca — Process Daemon w ustawieniach runtime'u oraz Toolbox → Supervisor — ale konfigurację workerów klikasz wtedy ręcznie, poza repozytorium. Odtworzenie tego na drugim serwerze oznacza powtórzenie tych samych kliknięć z pamięci.

W projektach, które mamy w Sailu i wdrażamy z własnym Dockerfile, sprawdza się inny podział: aplikacja zostaje w swoim Compose, a panel przejmuje warstwę wokół niej. W zakładce Containers → Composes wybierasz opcję wskazania istniejącego pliku i podajesz ścieżkę do docker-compose.yml z repozytorium:

services:
  app:
    build:
      context: .
      dockerfile: docker/Dockerfile
    restart: unless-stopped
    expose:
      - "8000"
    environment:
      APP_ENV: production
      OCTANE_SERVER: frankenphp
    depends_on:
      - pgsql
      - redis

  queue:
    build:
      context: .
      dockerfile: docker/Dockerfile
    restart: unless-stopped
    command: php artisan queue:work --tries=3 --max-time=3600
    depends_on:
      - redis

  scheduler:
    build:
      context: .
      dockerfile: docker/Dockerfile
    restart: unless-stopped
    command: php artisan schedule:work

Potem zakładasz w panelu witrynę typu reverse proxy, kierujesz ją na http://app:8000, podpinasz domenę i certyfikat. Wdrożenia dalej robi CI, wersjonowanie zostaje w gicie, a z 1Panela korzystasz do tego, w czym jest dobry: monitoringu, logów, firewalla, kopii i certyfikatów.

Jest tu jednak haczyk, który łatwo przeoczyć. Panel dzieli projekty Compose na trzy źródła: Apps (zainstalowane z App Store), 1Panel (założone przez panel, także przez wskazanie ścieżki do pliku) i Local (utworzone na serwerze poza panelem, na przykład przez twoje CI po SSH). Edycja oraz start i stop działają tylko dla projektów ze źródła 1Panel. Compose, który twój pipeline wgrał i uruchomił samodzielnie, zobaczysz na liście i podejrzysz jego kontenery, ale nie ruszysz go stamtąd. Jeśli chcesz mieć w panelu przyciski, załóż projekt przez Path Selection i pozwól panelowi go wystartować.

Kliknięte w panelu środowisko żyje poza repozytorium. Im więcej stanu produkcyjnego powstaje w interfejsie, tym trudniej odtworzyć serwer po awarii. Panel jest świetną konsolą operacyjną i kiepskim źródłem prawdy o konfiguracji.

Kopie zapasowe i zadania cykliczne

1Panel rozdziela konta backupowe od zadań. Konto to zdefiniowane miejsce docelowe, a lista obsługiwanych jest długa: AWS S3 i storage zgodny z S3, MinIO, WebDAV, SFTP, OneDrive, Google Drive, AliyunDrive, Alibaba OSS, Tencent COS, Qiniu Kodo, UPYUN oraz dysk lokalny. Jeśli trzymasz już własny MinIO, wpinasz go jako endpoint S3 i masz kopie u siebie. OneDrive i Google Drive wymagają przejścia przez własną aplikację OAuth, więc licz się z kwadransem klikania w konsoli dostawcy.

Zadania cykliczne obejmują zrzuty baz, katalogów witryn, aplikacji z App Store i dowolnych katalogów z hosta, z ustawianą retencją. W tej samej zakładce mieszczą się zwykłe crony: skrypty powłoki, wywołania URL-i, czyszczenie logów. Wydanie 2.2.5 dorzuciło do zrzutów MySQL opcję pominięcia informacji GTID, co ratuje przy odtwarzaniu dumpa na instancji z inną topologią replikacji.

Osobno działają snapshoty: migawka całego panelu razem z konfiguracją, aplikacjami i danymi, którą odtwarzasz poleceniem 1pctl restore na nowym hoście. To odpowiedź na scenariusz „serwer padł, potrzebujemy kopii u innego dostawcy w godzinę”. Powiadomienia o nieudanym backupie, anomalii logowania czy przekroczeniu progu zasobów wyślesz e-mailem w wersji darmowej; WeCom, DingTalk, Feishu i SMS są zarezerwowane dla Pro.

Warstwa AI

To część, która odróżnia 1Panel od cPanela i Pleska. Składa się z trzech modułów.

Modele

Instalujesz Ollamę z App Store, a panel dokłada nad nią interfejs: dodawanie modeli pobieranych z oficjalnego repozytorium Ollamy, uruchamianie terminala do rozmowy z modelem bez opuszczania przeglądarki, podgląd danych połączenia dla aplikacji po drugiej stronie, synchronizację listy z serwerem (przydatną, gdy ktoś dociągnął model spoza panelu) i skok do OpenWebUI.

Osobno konfigurujesz reverse proxy dla Ollamy z domeną, HTTPS i białą listą adresów. To nie jest opcjonalny dodatek: wystawione bez zabezpieczenia API modelu to darmowa moc obliczeniowa dla przypadkowych gości, a rachunek za prąd albo GPU zostaje po twojej stronie.

Przy kartach NVIDIA dochodzi zarządzanie TensorRT-LLM. Wymaga wcześniejszej instalacji sterownika i NVIDIA Container Toolkit, po czym panel uruchamia model w kontenerze z oficjalnego obrazu NVIDII. Katalog z modelem podmontowuje pod /models, więc polecenie startowe trtllm-server wskazujesz na tę ścieżkę, a nie na lokalizację z hosta. Zużycie kart podejrzysz w zakładce monitoringu GPU.

Agenci

Zarządzanie agentami sprowadza się do dodania konta modelu, a potem utworzenia agenta z tym kontem. Konto to klucz API do dostawcy publicznego (OpenAI, DeepSeek, Kimi) albo wskazanie modelu lokalnego. W dokumentacji przykładem przewodnim jest OpenClaw wraz z podpięciem kanału Discord, gdzie parametry bota podajesz zmiennymi środowiskowymi lub plikiem konfiguracyjnym. Agent potrzebuje co najmniej 2 GB wolnej pamięci i architektury x86_64 albo aarch64.

Wydanie 2.2.5 dorzuciło do tego zarządzanie wtyczkami agentów oraz obsługę API text-to-image w kontach modeli. Edycja OSS pozwala uruchomić pięciu agentów; zdjęcie limitu wymaga wersji Pro.

Serwery MCP

Natywne zarządzanie serwerami MCP pojawiło się w 1Panel 1.10.29 LTS i przeszło do wersji 2. Panel uruchamia serwer w kontenerze — przez npx albo jako podmontowany plik binarny — i publikuje tryb stdio jako SSE, czyli w formie, którą klient MCP odbierze przez sieć. Dla każdej instancji generuje gotową konfigurację z portem, adresem i ścieżką SSE, więc nie musisz ręcznie zgadywać zmiennych środowiskowych.

Praktyczny szczegół, który robi różnicę przy większej liczbie serwerów: wiele instancji MCP da się podpiąć pod jedną domenę, rozróżniane wyłącznie ścieżką SSE. Zamiast otwierać osobny port na każdy serwer, wystawiasz jeden i dokładasz do witryny białą listę adresów oraz certyfikat. Przy kilkunastu serwerach MCP w firmowej sieci to różnica między utrzymywalną konfiguracją a listą wyjątków w firewallu, której nikt już nie rozumie.

Panel jako narzędzie dla asystenta

Zależność działa też w drugą stronę. Projekt utrzymuje mcp-1panel, czyli serwer MCP wystawiający sam panel jako zestaw narzędzi dla asystenta:

  • get_dashboard_info i get_system_info — stan pulpitu oraz informacje o systemie.
  • list_websites i create_website — lista witryn i zakładanie nowej.
  • list_ssls i create_ssl — przegląd i wystawianie certyfikatów.
  • list_installed_apps, install_openresty, install_mysql — zainstalowane aplikacje i instalacja dwóch podstawowych.
  • list_databases i create_database — bazy danych.

Serwer rozprowadzany jest jako gotowy plik binarny, przez go install (wymaga Go 1.23+) albo jako obraz Dockera dla amd64, arm64, arm/v7, s390x i ppc64le. Konfiguracja w kliencie MCP wygląda tak:

{
  "mcpServers": {
    "mcp-1panel": {
      "command": "mcp-1panel",
      "env": {
        "PANEL_ACCESS_TOKEN": "<token dostępowy 1Panel>",
        "PANEL_HOST": "http://localhost:8080"
      }
    }
  }
}

Serwer działa też w trybie SSE i jako obraz Dockera:

mcp-1panel -host http://localhost:8080 -token <token> -transport sse -addr http://localhost:8000

Token panelu daje asystentowi możliwość zakładania witryn i baz na produkcji. Jeśli w ogóle to podpinasz, rób to przeciwko serwerowi testowemu, z tokenem o krótkim czasie życia i białą listą adresów po stronie panelu. Wygoda nie jest tu warta pomyłki modelu w środowisku klienta.

Aktualizacje i migracja z wersji 1

Panel aktualizuje się z poziomu interfejsu, a 1pctl obsługuje pozostałe czynności serwisowe: status, start, stop, restart, version, uninstall i restore. W architekturze v2 usługa rozpada się na core i agent, więc komendy przyjmują argument wskazujący, którego komponentu dotyczą.

Przejście z jedynki nie jest aktualizacją na miejscu. Projekt wydaje osobne narzędzie 1panel-migrator, a dokumentacja opisuje krok po kroku, co przygotować przed migracją. Jeśli utrzymujesz jeszcze serwery na v1, zaplanuj to jako osobne zadanie z oknem serwisowym, nie jako pozycję przy okazji.

OSS kontra Pro

Producent dzieli produkt na trzy edycje i warto znać granicę, zanim oprzesz proces na funkcji zza płatnej ściany.

  • OSS — bezpłatna, obejmuje kontenery, witryny, certyfikaty, bazy, App Store, kopie, firewall, Fail2ban, MCP, modele i pięciu agentów. Powiadomienia wyłącznie e-mailem.
  • Pro — od 80 USD rocznie: WAF z regułami per witryna i podglądem blokad, ochrona przed podmianą plików, zarządzanie wieloma węzłami, monitoring dostępności, audyt logów, powiadomienia przez WeCom, DingTalk, Feishu i SMS, proxy dla środowisk odciętych od internetu.
  • Enterprise — dokłada interfejs KVM, bramkę AI i priorytetowe wsparcie.

Funkcje oznaczone w dokumentacji jako xpack to zamknięty dodatek komercyjny, nie część kodu na GPLv3. Producent udostępnia 30-dniowy okres próbny, więc weryfikacja WAF-a czy multi-node na własnym ruchu nie wymaga decyzji w ciemno.

Licencja

Kod 1Panel jest udostępniony na GNU GPLv3. Dla firmy takiej jak nasza konsekwencje są łagodniejsze niż przy AGPL, którym objęty jest na przykład MinIO: obowiązki licencyjne uruchamia dystrybucja oprogramowania, a nie samo jego używanie. Instalacja panelu na własnych serwerach i na serwerach klientów, także w projekcie komercyjnym, nie zmusza cię do publikowania czegokolwiek. Nie ma tu pułapki „udostępniasz usługę przez sieć, więc musisz oddać kod”, którą AGPL zastawia na hostujących.

Granica biegnie gdzie indziej. Jeśli zmodyfikujesz 1Panel i przekażesz tak zmienioną wersję dalej — jako produkt, obraz przekazany klientowi albo urządzenie z preinstalowanym panelem — musisz udostępnić kod modyfikacji na tej samej licencji. Jeśli chcesz zbudować własne, zamknięte narzędzie na fragmentach tego kodu, GPLv3 tego nie pozwoli. Warstwa Pro i Enterprise jest zamknięta i płatna, więc traktuj ją jak zwykłe oprogramowanie komercyjne z osobną umową.

Za projektem stoi chińskie FIT2CLOUD, a komercyjne wsparcie na rynkach globalnych prowadzi LXware (Lingxia Hong Kong). Serwis 1panel.pro obsługuje wersję międzynarodową, 1panel.cn chińską, a paczki instalacyjne idą z resource.1panel.pro. Część materiałów społecznościowych i zgłoszeń w repozytorium jest po chińsku, choć dokumentacja i interfejs mają pełną wersję angielską. Przy wdrożeniach objętych wymogami dotyczącymi dostawców spoza UE warto mieć ten fakt w zestawieniu, razem z tym, że panel odpytuje serwery producenta o aktualizacje.

Podsumowanie

1Panel wart jest uwagi w dwóch sytuacjach: kiedy potrzebujesz szybko postawić i utrzymać kilkanaście mniejszych serwisów bez budowania własnego pipeline'u, oraz kiedy chcesz mieć jedno miejsce do zarządzania modelami i serwerami MCP w firmowej sieci. Do wdrażania aplikacji z powtarzalnym, wersjonowanym środowiskiem lepszy jest własny Compose plus CI, a panel zostawiasz jako konsolę operacyjną.

Główne korzyści:

  • instalacja jednym skryptem i pełny zestaw narzędzi operacyjnych w przeglądarce,
  • środowiska PHP nadążające za wydaniami języka, z Composerem i Supervisorem w obrazie,
  • certyfikaty Let's Encrypt z automatycznym odnawianiem, także wildcard przez DNS-01,
  • kopie na kilkanaście rodzajów storage'u plus snapshot całego panelu do odtworzenia u innego dostawcy,
  • zarządzanie serwerami MCP z jedną domeną, białą listą adresów i HTTPS,
  • brak opłat licencyjnych w wersji OSS i czytelna granica funkcji płatnych.

Na co uważać:

  • panel to konto root z interfejsem webowym — biała lista adresów, MFA i regularne aktualizacje nie są opcjonalne, a historia CVE z ostatnich dwóch lat pokazuje, czym kończy się ich brak,
  • jedno konto na host, bez ról i podziału uprawnień, więc przy większym zespole audyt działań opiera się na logach systemowych,
  • konfiguracja klikana w interfejsie nie trafia do repozytorium i trzeba ją odtwarzać ręcznie,
  • projekty Compose utworzone poza panelem są tam tylko do odczytu,
  • migracja z wersji 1 wymaga osobnego narzędzia i okna serwisowego.

Licencja GPLv3 przy zwykłym użyciu i wdrożeniach dla klientów nie nakłada obowiązków publikacyjnych — te pojawiają się dopiero przy dystrybucji zmodyfikowanej wersji.

← Wszystkie artykuły