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ą dopuszczalne, natomiast openvz lub lxc nie. Na planie KVM polecenie wyświetli 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 RAM i dwóch rdzeni procesora, z czego około 600 MB zajmuje sam Coolify. Cloudron potrzebuje minimum 2 GB, ale stabilniej pracuje przy 4 GB, ponieważ uruchamia serwer pocztowy i bazę danych jeszcze przed instalacją jakiejkolwiek aplikacji.
• Domena i kontrola nad DNS. Cloudron oraz Coolify wymagają posiadania własnej domeny z poprawnie skonfigurowanym DNS. Cloudron najlepiej współpracuje z dostępem API do dostawcy DNS, co pozwala mu na samodzielne tworzenie rekordów i certyfikatów typu wildcard. CasaOS zadziała na samym adresie IP, ale w takim przypadku nie uzyskasz obsługi TLS.
• Porty. Wszystkie trzy rozwiązania wymagają otwartych portów 80 oraz 443 dla ruchu HTTP i HTTPS. Coolify dodatkowo udostępnia swój panel pod portem 8000, wykorzystuje port 6001 dla kanałów czasu rzeczywistego oraz 6002 dla terminala w przeglądarce. Na każdym z nich należy pozostawić otwarty port 22 dla SSH.

Przed rozpoczęciem konfiguracji skieruj rekordy DNS na serwer. 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ę spędzisz na debugowaniu tego problemu zamiast na pracy z oprogramowaniem. Skieruj rekord A na adres IP serwera, a w przypadku Coolify dodaj rekord typu wildcard (*.apps.example.com), aby każda wdrożona aplikacja otrzymała własną subdomenę.

Cloudron: dopracowane, autorskie urządzenie typu appliance

Czym to jest. 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 osób, które oczekują zarządzania aplikacjami, automatycznych aktualizacji, certyfikatów oraz kopii zapasowych i są gotowe 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 wykonuje restart. Po ponownym uruchomieniu serwera 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 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 nacisnąć Install. Cloudron automatycznie utworzy rekord DNS, wystąpi o certyfikat Let's Encrypt, przygotuje bazę danych, skonfiguruje logowanie jednokrotne (SSO) oraz zaplanuje 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. Najsilniejszy 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. Dostępne jest przywracanie poszczególnych aplikacji, a nawet klonowanie aplikacji do nowej subdomeny za pomocą jednego kliknięcia.

Koszt i licencjonowanie – przeczytaj przed podjęciem decyzji. Cloudron to produkt płatny z ograniczonym planem darmowym: darmowa wersja pozwala na uruchomienie dwóch aplikacji. Instalacja trzeciej aplikacji powoduje napotkanie blokady płatności; płatna subskrypcja (Pro lub Max, rozliczana miesięcznie lub rocznie, obie z nielimitowaną liczbą aplikacji) odblokowuje pełną funkcjonalność. Jest to najważniejszy fakt dotyczący Cloudron. Platforma jest dopracowana właśnie dlatego, że jest przedsięwzięciem 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 it's installation.
Please start with a fresh Ubuntu install and run this script again.

Przyczyną nie jest nadmiarowa drobiazgowość. Cloudron przypisuje konkretne wersje nginx, Docker oraz Node i integruje je głęboko z systemem, przez co nie może współistnieć z własnymi instancjami tych narzędzi. Rozwiązaniem jest świeży obraz Ubuntu 24.04 i nic poza tym: brak serwera WWW, brak Docker, a nawet brak ręcznie skonfigurowanego firewalla. W przypadku uruchomienia na niewłaściwym obrazie, instalator odrzuci wszystko, co nie jest wspieranym systemem Ubuntu LTS (22.04 lub 24.04) na architekturze x86-64; systemy ARM, LXC oraz OpenVZ nie są wspierane.

Drugi tryb awarii – certyfikaty typu wildcard wymagają API DNS. Wybór opcji "Manual" w konfiguracji DNS zamiast podania tokena API sprawia, że Cloudron nie może automatycznie tworzyć rekordów ani certyfikatów typu wildcard. Każda nowa aplikacja będzie wymagała ręcznego dodania rekordu DNS przed wystawieniem certyfikatu, a panel sterowania będzie oczekiwał na wykonanie tej czynności. Udostępnienie Cloudron dostępu API do wspieranego dostawcy DNS (Cloudflare, Route 53, DigitalOcean i inni) sprawia, że cały proces odbywa się za pomocą 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 to jest. Coolify to otwartoźródłowa platforma typu PaaS (Platform-as-a-Service) do samodzielnego hostowania, działająca na zasadzie Heroku lub Vercel na własnym serwerze. Podstawową jednostką pracy nie jest „instalacja gotowej aplikacji”, lecz „wdrożenie repozytorium Git”: po podłączeniu repozytorium Coolify buduje je (za pomocą Nixpacks lub własnego pliku Dockerfile) i wdraża, automatycznie aktualizując przy każdym wypchnięciu kodu (push). Platforma oferuje również bazy danych i usługi uruchamiane jednym kliknięciem. Rozwiązanie jest skierowane 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ć, czy działają poprawnie:

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

Wszystkie kontenery coolify, coolify-db, coolify-redis, coolify-realtime oraz coolify-proxy powinny zgłaszać stan Up. Panel sterowania jest dostępny pod adresem http://<your-ip>:8000. Należy niezwłocznie utworzyć konto administratora, ponieważ strona rejestracji pozostaje otwarta do momentu utworzenia pierwszego konta, co oznacza, że każda osoba z dostępem do strony może przejąć 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 wdrożyć aplikację. 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ęć: ten sam stos automatyzacji przepływów pracy n8n, który w innym przypadku trzeba by konfigurować ręcznie, jest dostępny jako jeden wpis, podobnie jak Uptime Kuma do monitorowania statusu stron.

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 koncentrują się na bazach danych: można zaplanować zrzuty Postgres i MySQL do pamięci zgodnej z S3. Kopia zapasowa całej instancji (konfiguracja Coolify, która znajduje się w /data/coolify) wymaga działań ręcznych, dlatego należy ją wyeksportować i przechowywać samodzielnie.

Koszt i licencjonowanie. Edycja 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 płaszczyznę sterowania (control plane), podczas gdy aplikacje nadal działają na własnych serwerach użytkownika; 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ę powodzeniem, ale adres URL aplikacji zwraca błąd połączenia lub błąd Traefik 404 page not found. 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 uruchamiania 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, brakuje rekordu DNS typu wildcard, przez co Traefik nie otrzymuje żądania dla danej 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 nawiązać połączenia 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

Problem można naprawić z poziomu strony Proxy: należy wybrać Restart Proxy lub zresetować konfigurację proxy do ustawień domyślnych i uruchomić je ponownie, a następnie odczekać około dwóch minut na ustabilizowanie się usługi. Port 8000 powinien być dostępny wyłącznie z adresu IP administratora (lub tymczasowo otwierany w przypadku problemów z proxy), zamiast pozostawiać go otwartym dla całego Internetu; służy on do obsługi panelu przez zwykły HTTP, a dokumentacja Coolify wskazuje, że porty 8000, 6001 i 6002 można zamknąć, gdy panel jest obsługiwany 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 w ogóle potrzebuję panelu do self-hostingu?

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 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 żadna usługa nie jest wystawiona na bezpośrednie działanie wrogiego Internetu, CasaOS stanowi najłagodniejszy start: jedno polecenie i przyjazny interfejs użytkownika, bez żadnych opłat. Należy jednak umieścić przed nim reverse proxy z terminacją TLS, zanim cokolwiek zostanie wystawione na zewnątrz, ponieważ domyślnie działa on w oparciu o zwykły HTTP. Jeśli oczekujesz zarządzanego TLS i 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 jest wystarczające do testów lub bardzo małej konfiguracji. Powyżej tego limitu Cloudron jest płatną subskrypcją, rozliczaną 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 należy uwzględnić koszty, jeśli infrastruktura będzie się rozwijać.

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ż zarządza całą maszyną. CasaOS i Coolify są bardziej elastyczne, ponieważ instalują własny stos Docker i w zasadzie mogą współdzielić maszynę, ale oba wymagają portów 80 oraz 443, więc wchodzą w konflikt z każdym serwerem WWW lub proxy, które już działa. Na maszynie, która już obsługuje inne usługi, panel jest zazwyczaj niewłaściwym narzędziem; lepiej wybrać Traefik i Compose.

Jak później przenieść się z panelu?

Zaplanuj wyjście, zanim będzie potrzebne. W przypadku CasaOS skopiuj pliki 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ż paczki Cloudron nie są przenośne, przenoszone są tylko dane. W każdym przypadku przetestuj przywracanie na tymczasowej maszynie, zanim usuniesz starą.