Cloudron vs CasaOS vs Coolify: porównanie paneli VPS

Co budujesz

Wybierając narzędzie, decydujesz się na konkretny model pracy, a nie tylko na instalację oprogramowania. Trzy panele obiecują przekształcenie czystego VPS w platformę do hostowania aplikacji typu „wskaż i kliknij”: Cloudron, CasaOS oraz Coolify. Niniejszy przewodnik instaluje każde z nich na świeżym systemie Ubuntu 24.04, wdraża pierwszą aplikację, a następnie szczegółowo analizuje aspekty, których nie widać na zrzutach ekranu: TLS, kopie zapasowe, aktualizacje, zużycie pamięci oraz trudność migracji. Po lekturze dowiesz się, które rozwiązanie pasuje do Twoich potrzeb lub czy uczciwą odpowiedzią nie jest „żadne z nich, użyj po prostu Docker Compose”.

Żadne z tych rozwiązań nie jest magią. Pod każdym z nich znajduje się ten sam Docker Engine, którym mógłbyś zarządzać ręcznie. To, co sprzedaje Ci panel w zamian za pieniądze, pamięć RAM lub uzależnienie od dostawcy, to wykonanie czterech zadań: instalacja aplikacji jednym kliknięciem, automatyczne certyfikaty TLS, zaplanowane kopie zapasowe oraz zarządzanie użytkownikami. Jeśli te cztery funkcje są dla Ciebie warte narzutu wydajnościowego, panel spełnia swoje zadanie. Jeśli uruchamiasz jedną lub dwie usługi i wolisz dokładnie wiedzieć, co znajduje się na Twoim serwerze, przeczytaj najpierw sekcję „Pomiń wszystkie trzy” i oszczędź sobie kłopotu.

Wspólne wymagania wstępne i istotne pułapki

Wszystkie trzy rozwiązania wymagają VPS typu KVM, a nie wirtualizacji kontenerowej. Docker wymaga pełnego jądra systemu, a Cloudron odrzuca środowiska OpenVZ oraz LXC. Sprawdź to za pomocą systemd-detect-virt: kvm lub qemu są akceptowalne, natomiast openvz lub lxc nie. W planie KVM polecenie zwraca kvm, a na serwerze dedykowanym none; oba wyniki oznaczają, że można kontynuować.

Poza tym wymagania sprzętowe są różne i to one w pierwszej kolejności determinują wybór.

• RAM. CasaOS działa poprawnie przy 1 GB; system wywodzi się ze sprzętu Raspberry Pi i pozostaje lekki. Coolify wymaga minimum 2 GB pamięci RAM i dwóch rdzeni procesora, przy czym sam Coolify zajmuje około 600 MB. Cloudron wymaga minimum 2 GB, lecz stabilniej pracuje przy 4 GB, ponieważ uruchamia serwer pocztowy i bazę danych jeszcze przed instalacją pierwszej aplikacji.
• Domena i kontrola nad DNS. Cloudron oraz Coolify wymagają posiadania domeny z poprawnie skonfigurowanym DNS. Cloudron najlepiej współpracuje z dostępem API do dostawcy DNS, co pozwala mu na automatyczne tworzenie rekordów i certyfikatów typu wildcard. CasaOS może działać na samym adresie IP, ale wtedy nie uzyskuje się żadnego wsparcia dla TLS.
• Porty. Cloudron i Coolify wymagają otwartych portów 80 oraz 443 dla ruchu HTTP i HTTPS. CasaOS udostępnia panel przez zwykłe HTTP, więc wymaga jedynie portu 80. Coolify dodatkowo udostępnia panel na porcie 8000, wykorzystuje port 6001 do obsługi kanałów czasu rzeczywistego oraz 6002 dla terminala w przeglądarce. Na każdym z tych rozwiązań należy pozostawić otwarty port 22 dla SSH.

Skonfiguruj DNS przed rozpoczęciem instalacji. Panel, który nie potrafi rozwiązać własnej nazwy hosta, nie będzie w stanie wystąpić o certyfikat, co spowoduje, że pierwszą godzinę poświęcisz na debugowanie tego problemu zamiast na konfigurację oprogramowania. Skieruj rekord A na adres IP serwera, a w przypadku Coolify dodaj rekord wildcard (*.apps.example.com), aby każda wdrożona aplikacja otrzymywała własną subdomenę.

Cloudron: dopracowane, autorskie rozwiązanie typu appliance

Czym jest to rozwiązanie. Cloudron to komercyjna platforma, która przekształca cały serwer w zarządzane urządzenie typu appliance. Uruchamia własny reverse proxy, bazę danych oraz stos pocztowy, a także oferuje wyselekcjonowany sklep z gotowymi pakietami aplikacji (Nextcloud, WordPress, Gitea, Mattermost i inne). Rozwiązanie jest skierowane do użytkowników oczekujących pełnego zarządzania aplikacjami, w tym automatycznych aktualizacji, certyfikatów oraz kopii zapasowych, i gotowych za to zapłacić.

Instalacja. Platforma wymaga czystego systemu i przejmuje nad nim pełną kontrolę. Należy uruchomić ją wyłącznie na świeżym serwerze z systemem Ubuntu 24.04 (Noble):

wget https://cloudron.io/cloudron-setup
chmod +x cloudron-setup
sudo ./cloudron-setup

Skrypt instaluje Docker, nginx, bazę danych oraz stos pocztowy, a następnie restartuje serwer. Po ponownym uruchomieniu należy otworzyć https://<your-ip>, zaakceptować tymczasowy certyfikat z podpisem własnym i dokończyć konfigurację w przeglądarce: wskazać domenę, wybrać dostawcę DNS, co pozwoli platformie na zainicjowanie panelu sterowania pod adresem my.example.com.

Dodawanie pierwszej aplikacji. W panelu sterowania należy otworzyć App Store, wybrać aplikację (na przykład Nextcloud), wskazać subdomenę files.example.com i kliknąć Install. Cloudron automatycznie tworzy rekord DNS, występuje o certyfikat Let’s Encrypt, przygotowuje bazę danych, konfiguruje logowanie jednokrotne (SSO) oraz planuje kopię zapasową – wszystko bez konieczności edycji plików konfiguracyjnych. To główna zaleta tego rozwiązania, która w pełni realizuje swoje założenia.

TLS i kopie zapasowe. Najmocniejszy punkt spośród trzech omawianych rozwiązań. Każda subdomena aplikacji otrzymuje automatyczny certyfikat Let’s Encrypt, który jest cyklicznie odnawiany. Kopie zapasowe są wbudowane i zaplanowane, obsługując lokalne katalogi, S3 lub inne zdalne magazyny danych, z możliwością przywracania poszczególnych aplikacji, a nawet ich klonowania do nowej subdomeny jednym kliknięciem.

Koszty i licencjonowanie – przeczytaj przed rozpoczęciem. Cloudron to płatny produkt z ograniczonym planem darmowym: darmowa wersja pozwala na uruchomienie dwóch aplikacji. Instalacja trzeciej aplikacji aktywuje blokadę; płatna subskrypcja (Pro lub Max, rozliczana miesięcznie lub rocznie, obie z nielimitowaną liczbą aplikacji) odblokowuje pełną funkcjonalność. Jest to najważniejsza informacja dotycząca Cloudron. Platforma jest dopracowana właśnie dlatego, że jest produktem komercyjnym, a darmowy plan jest bliższy rozszerzonej wersji próbnej niż środowisku dla rozwijającego się stosu usług.

Tryb awarii: zasada czystego systemu. Próba instalacji Cloudron na serwerze, na którym już działają inne usługi, spowoduje przerwanie procesu przed wprowadzeniem jakichkolwiek zmian:

Error: Some packages like nginx/docker/nodejs are already installed. Cloudron requires
specific versions of these packages and will install them as part of its installation.
Please start with a fresh Ubuntu install and run this script again.

Przyczyną nie jest nadmierna restrykcyjność. Cloudron przypisuje konkretne wersje nginx, Docker oraz Node i integruje je głęboko z systemem, dlatego nie może współistnieć z własnymi instancjami tych narzędzi. Rozwiązaniem jest czysty obraz Ubuntu 24.04 i nic poza tym: brak serwera WWW, brak Docker, a nawet brak ręcznie skonfigurowanego firewalla. Jeśli wybrano niewłaściwy obraz, instalator odrzuci każdą wersję, która nie jest wspieranym wydaniem Ubuntu LTS (22.04, 24.04 lub 26.04) na architekturze x86-64; systemy ARM, LXC oraz OpenVZ nie są wspierane. Od wersji Cloudron 10 (wrzesień 2026), Ubuntu 26.04 jest domyślnym systemem dla nowych instalacji, dlatego jest to właściwy wybór przy rozpoczynaniu pracy od zera.

Drugi tryb awarii: certyfikaty wildcard wymagają API DNS. Wybór opcji "Manual" w konfiguracji DNS zamiast podania tokena API uniemożliwia platformie automatyczne tworzenie rekordów oraz certyfikatów typu wildcard. W takim przypadku każda nowa aplikacja wymaga ręcznego dodania rekordu DNS przed wystawieniem certyfikatu, a panel sterowania pozostaje w stanie oczekiwania na ten rekord. Udostępnienie Cloudron dostępu API do wspieranego dostawcy DNS (Cloudflare, Route 53, DigitalOcean i inni) sprawia, że cały proces sprowadza się do jednego kliknięcia.

CasaOS: darmowy pulpit nawigacyjny dla home-lab

Czym jest to rozwiązanie. CasaOS, produkt firmy IceWhale, to darmowy pulpit nawigacyjny o otwartym kodzie źródłowym, działający w oparciu o Docker. Udostępnia ekran główny, sklep z aplikacjami oraz menedżer plików. Narzędzie wywodzi się ze środowiska serwerów domowych, dlatego jego charakterystyka jest typowa dla home-lab: szybka konfiguracja, przyjazny interfejs i minimalna liczba formalności. Jest skierowane do użytkowników, którzy chcą korzystać z czytelnego interfejsu dla Dockera bez ponoszenia opłat.

Instalacja. Wystarczy jedna linia poleceń; system nie wymaga czystej instalacji:

curl -fsSL https://get.casaos.io | sudo bash

Instalator dodaje zestaw usług systemd (casaos, casaos-gateway, casaos-app-management i powiązane). Przed otwarciem przeglądarki należy potwierdzić, że brama została uruchomiona:

systemctl status casaos-gateway

Po uruchomieniu pulpit nawigacyjny jest dostępny pod adresem http://<your-ip> (zwykły protokół HTTP, port 80). Po utworzeniu konta lokalnego można rozpocząć pracę.

Dodawanie pierwszej aplikacji. Należy otworzyć App Store, wybrać aplikację i kliknąć Install. CasaOS automatycznie tworzy projekt Docker Compose i udostępnia aplikację na porcie hosta, na przykład http://<your-ip>:8080. Sklep zawiera standardowy zestaw oprogramowania dla serwerów domowych, dzięki czemu serwer multimediów Jellyfin na VPS lub własna biblioteka zdjęć Immich są dostępne po kilku kliknięciach. Jeśli wybór serwera zdjęć nie został jeszcze dokonany, warto wcześniej zapoznać się z artykułem wymagania RAM i aplikacje mobilne: różnice między PhotoPrism a Immich, ponieważ w przypadku serwera CasaOS z 1 GB pamięci RAM wybór ten decyduje o tym, czy aplikacja w ogóle zadziała. Możliwy jest również import dowolnego pliku docker-compose.yaml, co stanowi główną zaletę: aplikacje są zwykłymi kontenerami, a nie formatem własnościowym.

TLS i kopie zapasowe – słabe punkty. W tym miejscu uwidaczniają się ograniczenia darmowego rozwiązania. CasaOS domyślnie obsługuje wszystko przez zwykły protokół HTTP, włącznie z własnym pulpitem nawigacyjnym. Brak wbudowanej obsługi Let's Encrypt oraz harmonogramu kopii zapasowych. Dane przechowywane są w wolumenach Docker w lokalizacji /DATA, a za ich kopiowanie odpowiada użytkownik (poprzez zadanie cron z użyciem restic lub tar).

Tryb awarii, brak TLS i brak powiadomień. System nie zgłasza błędów. Po zainstalowaniu aplikacji i otwarciu adresu http://<your-ip>:8080 wszystko działa, jednak połączenie jest niezaszyfrowane, co przeglądarka oznacza jako "Not Secure". Hasła i ciasteczka sesyjne są przesyłane otwartym tekstem. Co gorsza, w pulpicie nawigacyjnym CasaOS wykryto luki umożliwiające zdalne wykonanie kodu (CVE-2023-37265 oraz CVE-2023-37266 – obejście uwierzytelniania prowadzące do pełnego przejęcia hosta), dlatego wystawienie portu HTTP bezpośrednio do Internetu stanowi realne zagrożenie, a nie tylko kwestię estetyczną. Rozwiązaniem jest unikanie bezpośredniego wystawiania CasaOS. Należy zastosować reverse proxy z terminacją TLS, takie jak nginx z certyfikatem Let's Encrypt z Certbot, Caddy lub Cloudflare Tunnel, i przekierowywać ruch do CasaOS wyłącznie w sieci lokalnej. Należy pamiętać, że CasaOS domyślnie zajmuje port 80, więc proxy i CasaOS będą ze sobą kolidować, chyba że wcześniej zmieni się port CasaOS na inny.

Koszt. Rozwiązanie jest całkowicie darmowe, bez limitów aplikacji. Kosztem jest nakład pracy operacyjnej: użytkownik samodzielnie odpowiada za TLS, kopie zapasowe i zabezpieczenie systemu.

Coolify: self-hosted PaaS

Czym jest to rozwiązanie. Coolify to otwartoźródłowa platforma typu PaaS (Platform-as-a-Service) do samodzielnego hostowania, działająca na zasadzie podobnej do Heroku lub Vercel, ale na własnym serwerze. Podstawową jednostką pracy nie jest tu instalacja gotowej paczki, lecz wdrożenie repozytorium Git: po podłączeniu repozytorium Coolify buduje aplikację (za pomocą Nixpacks lub własnego pliku Dockerfile) i wdraża ją, automatycznie aktualizując przy każdym wypchnięciu zmian (push). Platforma oferuje również bazy danych i usługi uruchamiane jednym kliknięciem. Jest skierowana do programistów, którzy wdrażają własny kod i oczekują funkcjonalności push-to-deploy bez konieczności wynajmowania zewnętrznego PaaS.

Instalacja.

curl -fsSL https://cdn.coollabs.io/coolify/install.sh | sudo bash

Skrypt instaluje Docker i uruchamia stos kontenerów Coolify. Przed przejściem dalej należy sprawdzić ich stan:

docker ps --format 'table {{.Names}}\t{{.Status}}'

Wszystkie kontenery coolify, coolify-db, coolify-redis, coolify-realtime oraz coolify-proxy powinny zgłaszać status Up. Panel sterowania dostępny jest pod adresem http://<your-ip>:8000. Należy niezwłocznie utworzyć konto administratora, ponieważ strona rejestracji pozostaje otwarta do momentu utworzenia pierwszego konta – osoba, która uzyska do niej dostęp jako pierwsza, przejmie kontrolę nad serwerem. Następnie należy ustawić domenę instancji i skierować rekord DNS typu wildcard (*.example.com lub *.apps.example.com) na serwer, aby Coolify mogło przypisać każdej wdrożonej aplikacji własną subdomenę.

Dodawanie pierwszej aplikacji. Należy podłączyć źródło Git (GitHub, GitLab lub adres URL repozytorium), wybrać gałąź, ustawić domenę i uruchomić wdrożenie. Wbudowany w Coolify proxy Traefik kieruje ruch do subdomeny i występuje o certyfikat. W przypadku gotowego oprogramowania katalog usług pozwala na wdrożenie aplikacji za pomocą kilku kliknięć: zarówno stos automatyzacji przepływów pracy n8n, który w innym przypadku trzeba by konfigurować ręcznie, jak i Uptime Kuma do monitorowania statusu stron są dostępne jako pojedyncze wpisy.

TLS i kopie zapasowe. Automatyczne certyfikaty Let's Encrypt dla każdej aplikacji są obsługiwane przez dołączony Traefik, dzięki czemu każda wdrożona subdomena otrzymuje certyfikat. Kopie zapasowe dotyczą przede wszystkim baz danych: można zaplanować zrzuty Postgres i MySQL do pamięci zgodnej z S3. Kopia zapasowa całej instancji (konfiguracja Coolify przechowywana w /data/coolify) wymaga działań ręcznych, dlatego należy ją wyeksportować i zabezpieczyć samodzielnie.

Koszty i licencjonowanie. Wersja self-hosted jest w pełni otwartoźródłowa i darmowa, bez limitów liczby aplikacji. Dostępna jest opcjonalna, płatna usługa Coolify Cloud, która hostuje panel sterowania, podczas gdy aplikacje nadal działają na własnych serwerach – jest to rozwiązanie wygodne, lecz niewymagane.

Tryb awaryjny: aplikacja wdraża się, ale jej domena nie ładuje się. Panel sterowania działa poprawnie pod adresem http://<ip>:8000, proces budowania kończy się sukcesem, ale adres URL aplikacji zwraca błąd połączenia lub błąd 404 page not found serwera Traefik. Wskazuje to na problem z proxy lub DNS, a nie z samą aplikacją. Istnieją dwie częste przyczyny. Po pierwsze, porty 80 lub 443 były zajęte w momencie próby uruchomienia proxy, przez co jego kontener zakończył działanie z błędem Docker:

Error response from daemon: driver failed programming external connectivity on endpoint coolify-proxy: Bind for 0.0.0.0:443 failed: port is already allocated

Po drugie, nazwa hosta nie wskazuje na serwer: albo aplikacja korzysta z subdomeny generowanej automatycznie i brakuje rekordu DNS typu wildcard, albo korzysta z domeny własnej, która nie posiada rekordu DNS wskazującego na serwer, przez co Traefik nigdy nie otrzymuje żądania dla tej nazwy hosta. Jeśli natomiast karta serwera w Coolify wyświetla komunikat "Server is not reachable", przyczyną jest inny błąd: Coolify nie może połączyć się z gniazdem Docker serwera, co zazwyczaj wynika z zatrzymanego demona Docker lub uszkodzonego klucza SSH. Przed podjęciem prób naprawy należy sprawdzić rzeczywistą przyczynę w dziennikach:

docker logs coolify-proxy --tail 100

Naprawę należy przeprowadzić z poziomu strony Proxy: należy wybrać Restart Proxy lub przywrócić domyślną konfigurację proxy i uruchomić je ponownie, a następnie odczekać około dwie minuty na ustabilizowanie się usługi. Port 8000 powinien być dostępny wyłącznie z własnego adresu IP (lub otwierany tymczasowo w razie problemów z proxy), zamiast pozostawiać go otwartym dla całego Internetu. Służy on do obsługi panelu przez zwykłe HTTP, a dokumentacja Coolify wskazuje, że porty 8000, 6001 oraz 6002 można zamknąć, gdy panel jest dostępny przez własną domenę.

Narzut zasobów na tym samym VPS

Pomiary wykonano w stanie spoczynku na tej samej maszynie 4GB, przed uruchomieniem jakiegokolwiek rzeczywistego obciążenia. Warto sprawdzić własne wartości za pomocą free -m oraz docker stats --no-stream zamiast polegać na pojedynczej liczbie, ponieważ całkowite zużycie zmienia się wraz z zestawem uruchomionych aplikacji.

• CasaOS jest najlżejszy. Panel składa się z niewielkiego zestawu usług napisanych w Go; należy spodziewać się około 150 do 300 MB narzutu ponad zużycie generowane przez uruchomione kontenery.
• Coolify uruchamia kilka własnych kontenerów pomocniczych (aplikację, Postgres, Redis, usługę czasu rzeczywistego oraz Traefik), więc w stanie spoczynku zużywa od 600 MB do 1 GB przed wdrożeniem jakichkolwiek usług.
• Cloudron jest najcięższy w spoczynku, ponieważ uruchamia własny serwer nginx, bazę danych, stos pocztowy oraz system monitorowania, niezależnie od tego, czy są one używane; należy zarezerwować 1 do 1.5 GB w stanie spoczynku. Dlatego wymaga minimum 2GB pamięci RAM, a przy 4GB działa znacznie stabilniej.

Na małym VPS z 2GB pamięci RAM, CasaOS pozostawia najwięcej miejsca na rzeczywiste aplikacje, a Cloudron najmniej. Jeśli planujesz użyć 2GB i chcesz korzystać z Cloudron wraz z uruchomionym serwerem pocztowym, zaplanuj zwiększenie zasobów serwera.

Aktualizacje, kopie zapasowe i zjawisko lock-in – porównanie

Aktualizacje. Cloudron aktualizuje platformę oraz każdą aplikację zgodnie z przetestowanym harmonogramem: wymaga to najmniej wysiłku i zapewnia największe wsparcie. Coolify aktualizuje się samodzielnie z poziomu własnego panelu za pomocą jednego przycisku. CasaOS aktualizuje panel poprzez skrypt instalacyjny lub apt, jednak za pobieranie obrazów i restartowanie zainstalowanych aplikacji odpowiada użytkownik.

Lock-in, czyli problem ujawniający się w drugim roku. CasaOS wykazuje najmniejszy stopień uzależnienia od dostawcy: aplikacje są zwykłymi projektami Compose, więc można skopiować docker-compose.yaml oraz wolumeny z /DATA na dowolny inny host i kontynuować pracę. Coolify znajduje się pośrodku: wdrożenia opierają się na własnych plikach Dockerfile i repozytoriach, jednak ich konfiguracja przechowywana jest w bazie danych Coolify, co oznacza, że przeniesienie na inny host wymaga ponownego utworzenia projektów. Cloudron wykazuje największy stopień uzależnienia: aplikacje są pakowane w formacie Cloudron i choć dane można łatwo wyeksportować dzięki doskonałemu systemowi kopii zapasowych, sam sposób pakowania nie jest przenośny, co wymusza ponowne wdrożenie na platformie docelowej. Dane są przenośne, ale infrastruktura nie.

Które rozwiązanie wybrać

Wersja skrócona oraz wskazówka końcowa. Wybierz Cloudron, jeśli oczekujesz najmniejszego zaangażowania w zarządzanie serwerem spośród trzech wymienionych opcji, planujesz uruchomić kilka gotowych aplikacji i akceptujesz roczną opłatę za zarządzanie TLS, kopiami zapasowymi oraz aktualizacjami. Wybierz CasaOS, jeśli jest to laboratorium domowe działające wewnątrz własnej sieci lub za reverse proxy, oczekujesz przyjaznego interfejsu dla Docker i nie chcesz ponosić żadnych kosztów. Wybierz Coolify, jeśli wdrażasz własny kod z Git i potrzebujesz mechanizmu push-to-deploy z automatycznym TLS, bez kosztów typowych dla hostowanych platform PaaS. Jeśli żadna z tych opcji nie opisuje Twoich potrzeb, kolejna sekcja zawiera szczerą odpowiedź.

Pomiń wszystkie trzy, jeśli...

Należy zachować uczciwość w kwestii skali. Jeśli uruchamiasz tylko jedną lub dwie aplikacje albo chcesz dokładnie rozumieć i kontrolować zawartość serwera, zrezygnuj z paneli zarządzania. Narzut oraz uzależnienie od dostawcy (vendor lock-in) nie są opłacalne w przypadku małego, stabilnego stosu technologicznego. Ścieżka DIY polega na zastosowaniu reverse proxy przed własnymi plikami Compose: Traefik z automatycznym TLS przed kilkoma aplikacjami Docker Compose zapewnia HTTPS o funkcjonalności zbliżonej do rozwiązań typu „jedno kliknięcie”, bez obciążenia typowego dla paneli, a kopie zapasowe wykonuje się za pomocą zadania cron restic, którego działanie jest w pełni zrozumiałe.

services:
  whoami:
    image: traefik/whoami
    labels:
      - traefik.enable=true
      - traefik.http.routers.whoami.rule=Host(`whoami.example.com`)
      - traefik.http.routers.whoami.tls.certresolver=le
    networks: [web]
networks:
  web:
    external: true

W przypadku pojedynczej, kluczowej aplikacji sprawa jest jeszcze bardziej oczywista: instalacja Nextcloud na Dockerze z TLS i własną procedurą backupu to jeden plik Compose i jeden certyfikat. Uruchamianie całego panelu zarządzającego tylko dla tej usługi generuje koszty bez żadnych korzyści. Jeśli nadal decydujesz, co uruchomić, zanim ustalisz jak, lepszym punktem wyjścia będzie przewodnik po tym, co warto hostować samodzielnie w 2026 roku.

FAQ

Czy panel do self-hostingu jest w ogóle potrzebny?

Tylko jeśli cenisz cztery funkcje, które panel automatyzuje dla wielu aplikacji: instalację jednym kliknięciem, automatyczne certyfikaty TLS, harmonogram kopii zapasowych oraz zarządzanie użytkownikami. W przypadku jednej lub dwóch usług, zwykły Docker Compose za Traefik wykonuje to samo zadanie w zakresie TLS przy znacznie mniejszym narzucie i braku uzależnienia od konkretnego dostawcy. Panele stają się opłacalne, gdy uruchamiasz wiele aplikacji, a Twój czas jest cenniejszy niż pamięć RAM, którą one zużywają.

Który panel jest najlepszy dla początkującego?

W przypadku domowego laboratorium, w którym usługi nie są wystawione na bezpośrednie działanie Internetu, CasaOS stanowi najłagodniejszy start: jedno polecenie i przyjazny interfejs użytkownika bez opłat. Należy jednak umieścić przed nim reverse proxy z terminacją TLS, zanim cokolwiek zostanie wystawione na zewnątrz, ponieważ domyślnie korzysta on z czystego HTTP. Jeśli oczekujesz zarządzanego TLS i automatycznych kopii zapasowych oraz akceptujesz opłaty, Cloudron oferuje największe wsparcie w ramach darmowego limitu dwóch aplikacji.

Czy Cloudron jest darmowy?

Częściowo. Darmowy plan pozwala na uruchomienie dwóch aplikacji, co wystarcza do przetestowania rozwiązania lub w przypadku bardzo małej konfiguracji. Powyżej tego limitu Cloudron wymaga płatnej subskrypcji, rozliczanej miesięcznie lub rocznie, oferując nieograniczoną liczbę aplikacji w płatnych planach. Jest to produkt komercyjny z ograniczonym darmowym planem, a nie oprogramowanie darmowe, więc uwzględnij koszty, jeśli Twój stos technologiczny będzie się rozrastał.

Czy mogę uruchomić te panele obok istniejących aplikacji?

Cloudron: nie. Wymaga czystej instalacji Ubuntu i przerywa działanie, jeśli nginx, Docker lub Node są już zainstalowane, ponieważ przejmuje zarządzanie całym systemem. CasaOS i Coolify są bardziej elastyczne, ponieważ instalują własny stos Docker i w teorii mogą współdzielić maszynę, jednak CasaOS wymaga portu 80 dla swojego panelu, a proxy Coolify wymaga portów 80 oraz 443, więc oba wchodzą w konflikt z każdym serwerem WWW lub proxy, które już zajmuje te porty. Na maszynie, która już obsługuje inne usługi, panel zazwyczaj nie jest właściwym narzędziem; lepiej wybrać Traefik i Compose.

Jak później zrezygnować z panelu?

Zaplanuj wyjście, zanim będzie ono potrzebne. W przypadku CasaOS skopiuj docker-compose.yaml aplikacji oraz jej wolumeny /DATA na nowy host i uruchom je ponownie. W przypadku Coolify wyeksportuj konfigurację każdego projektu i wskaż te same repozytoria na docelowej maszynie. W przypadku Cloudron przywróć dane z kopii zapasowych do świeżo zainstalowanych aplikacji na nowej platformie, ponieważ sposób pakowania aplikacji przez Cloudron nie jest przenośny, przenoszone są tylko dane. W każdym przypadku przetestuj przywracanie na tymczasowej maszynie przed wyłączeniem starej.