Cloudron vs CasaOS vs Coolify na VPS

Cel projektu

Wybór narzędzia jest równie istotny jak sama instalacja. Trzy panele obiecują przekształcenie czystego serwera VPS w platformę do hostowania aplikacji metodą „point-and-click”: Cloudron, CasaOS oraz Coolify. W niniejszym poradniku każdy z nich zostanie zainstalowany na nowym systemie Ubuntu 24.04. Po instalacji pierwszej aplikacji przeanalizowano kluczowe aspekty: TLS, kopie zapasowe, aktualizacje, zużycie pamięci RAM oraz stopień uzależnienia od dostawcy (vendor lock-in). Po lekturze będzie można zdecydować, które rozwiązanie jest odpowiednie lub czy właściwą odpowiedzią jest rezygnacja z paneli na rzecz Docker Compose.

Żadne z tych rozwiązań nie jest magiczne. Pod każdym z nich działa ten sam silnik Docker Engine, którym można zarządzać ręcznie. Panel oferuje automatyzację czterech procesów: instalację aplikacji jednym kliknięciem, automatyczne certyfikaty TLS, harmonogram kopii zapasowych oraz zarządzanie użytkownikami. Jeśli te funkcje uzasadniają dodatkowy narzut zasobów, panel jest wart instalacji. Jeśli uruchamiasz tylko jedno lub dwa usługi i chcesz mieć pełną kontrolę nad systemem, należy najpierw zapoznać się z sekcją „Skip all three”.

Wspólne wymagania wstępne i istotne utrudnienia

Wszystkie trzy rozwiązania wymagają serwera VPS typu KVM, a nie wirtualizacji kontenerowej. Docker wymaga rzeczywistego jądra, a Cloudron nie obsługuje OpenVZ ani LXC. Należy zweryfikować za pomocą systemd-detect-virt: kvm lub qemu jest dopuszczalne, natomiast openvz lub lxc nie jest dopuszczalne. Na planie KVM polecenie zwraca kvm, a na bare metal zwraca none; oba wyniki oznaczają możliwość kontynuacji.

Poza tym parametry ulegają różnicom, co stanowi główny czynnik decyzyjny.

• RAM. CasaOS działa poprawnie przy 1GB; oprogramowanie jest zoptymalizowane pod sprzęt Raspberry Pi i zużywa mało zasobów. Coolify wymaga minimum 2GB RAM oraz dwóch rdzeni CPU, przy czym około 600 MB zajmuje sam proces Coolify. Cloudron wymaga minimum 2GB RAM, jednak optymalna wartość to 4GB, ponieważ przed instalacją jakiejkolwiek aplikacji uruchamia serwer pocztowy oraz bazę danych.
• Domena i zarządzalny DNS. Zarówno Cloudron, jak i Coolify wymagają rzeczywistej domeny z działającym DNS. Cloudron najlepiej działa przy dostępie API do dostawcy DNS, co umożliwia samodzielne tworzenie rekordów i certyfikatów wildcard. CasaOS może działać na samym adresie IP, ale wtedy brak jest obsługi TLS.
• Porty. Wszystkie trzy rozwiązania wymagają otwartych portów 80 oraz 443 dla protokołów HTTP i HTTPS. Coolify dodatkowo obsługuje panel sterowania na porcie 8000, używa portu 6001 dla kanału realtime oraz 6002 dla terminala w przeglądarce. Na każdym z systemów należy pozostawić otwarty port 22 dla usługi SSH.

Przed rozpoczęciem należy skonfigurować DNS dla serwera. Panel, który nie potrafi rozwiązać własnej nazwy hosta, nie może pobrać certyfikatu, co spowoduje konieczność debugowania zamiast instalacji oprogramowania. Należy skierować rekord A na adres IP serwera, a dla Coolify należy dodać rekord wildcard (*.apps.example.com), aby każda zainstalowana aplikacja posiadała własną poddomenę.

Cloudron: dopracowane, autorskie rozwiązanie typu appliance

Definicja. Cloudron to komercyjna platforma, która przekształca serwer w zarządzane urządzenie typu appliance. System zawiera własny reverse proxy, bazę danych oraz stos pocztowy, a także wyselekcjonowany App Store z gotowymi aplikacjami (Nextcloud, WordPress, Gitea, Mattermost i inne). Rozwiązanie jest przeznaczone dla użytkowników wymagających pełnego zarządzania aplikacjami, w tym automatycznych aktualizacji, automatycznych certyfikatów oraz automatycznych kopii zapasowych, którzy są gotowi za to zapłacić.

Instalacja. System wymaga czystego serwera i przejmuje nad nim pełną kontrolę. Należy uruchomić poniższą procedurę wyłącznie na nowym serwerze 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 uruchamia ponownie system. Po ponownym uruchomieniu należy otworzyć https://<your-ip>, zaakceptować tymczasowy certyfikat self-signed i dokończyć konfigurację w przeglądarce: należy wskazać własną domenę, wybrać dostawcę DNS, a następnie system utworzy panel zarządzania pod adresem my.example.com.

Dodawanie pierwszej aplikacji. W panelu sterowania należy otworzyć App Store, wybrać na przykład Nextcloud, wskazać subdomenę files.example.com i kliknąć Install. Cloudron tworzy rekord DNS, pobiera certyfikat Let's Encrypt, przygotowuje bazę danych, konfiguruje single sign-on oraz planuje kopie zapasowe bez konieczności edycji plików konfiguracyjnych. Jest to główna funkcja produktu.

TLS i kopie zapasowe. To najważniejszy element systemu. Każda subdomena aplikacji otrzymuje automatyczny certyfikat Let's Encrypt, który jest odnawiany automatycznie. Kopie zapasowe są planowane i wbudowane w system; można je zapisywać w lokalnym katalogu, w S3 lub innym pamięci zdalnej. System umożliwia przywracanie danych dla pojedynczych aplikacji oraz klonowanie aplikacji do nowej subdomeny jednym kliknięciem.

Koszty i licencjonowanie, przeczytaj przed zakupem. Cloudron to płatny produkt z ograniczonym darmowym planem: darmowa wersja pozwala na instalację dwóch aplikacji. Instalacja trzeciej aplikacji wymaga wykupienia subskrypcji; płatne plany (Pro lub Max, rozliczane miesięcznie lub rocznie, oba z nielimitowaną liczbą aplikacji) odblokowują pełną funkcjonalność. Jest to kluczowa informacja dotycząca Cloudron. Produkt jest dopracowany, ponieważ stanowi model biznesowy, a darmowa wersja pełni funkcję rozszerzanego okresu próbnego, a nie rozwiązania dla rozbudowanych stosów technologicznych.

Tryb błędu: zasada czystego serwera. Próba instalacji Cloudron na serwerze, na którym działają już inne usługi, spowoduje przerwanie instalacji 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 nadmierna rygorystyczność. Cloudron wymaga konkretnych wersji nginx, Docker oraz Node i integruje je głęboko z systemem, co uniemożliwia współistnienie z własnymi instancjami tych usług. Rozwiązaniem jest czysty obraz Ubuntu 24.04: bez serwera WWW, bez Docker, bez ręcznie skonfigurowanego firewalla. W przypadku użycia niewłaściwego obrazu instalacja zostanie przerwana. System obsługuje wyłącznie wspierane wersje Ubuntu LTS (22.04 lub 24.04) na architekturze x86-64; architektury ARM, LXC oraz OpenVZ nie są obsługiwane.

Drugi tryb błędu: certyfikaty wildcard wymagają DNS API. Wybranie opcji "Manual" podczas konfiguracji DNS zamiast podania tokenu API uniemożliwia automatyczne tworzenie rekordów oraz certyfikatów wildcard. W takim przypadku każda nowa aplikacja wymaga ręcznego dodania rekordu DNS przed wystawieniem certyfikatu, a panel sterowania pozostaje w stanie oczekiwania. Przyznanie Cloudron dostępu API do wspieranego dostawcy DNS (Cloudflare, Route 53, DigitalOcean i inne) umożliwia pełną automatyzację procesu za pomocą jednego kliknięcia.

CasaOS: darmowy panel sterowania dla home-lab

Opis produktu. CasaOS od IceWhale to darmowy i open-source'owy panel sterowania działający w oparciu o Docker. Zapewnia pulpit, sklep z aplikacjami oraz menedżer plików. Produkt został zaprojektowany z myślą o serwerach domowych, dlatego cechuje się szybką instalacją, przyjaznym interfejsem UI i minimalną konfiguracją. Jest przeznaczony dla użytkowników chcących uzyskać lepszy interfejs dla Docker bez ponoszenia kosztów licencyjnych.

Instalacja. Proces wymaga wykonania jednej komendy i nie wymaga czystego systemu:

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

Instalator dodaje zestaw usług systemd (casaos, casaos-gateway, casaos-app-management i inne). Przed uruchomieniem przeglądarki należy potwierdzić dostępność bramy sieciowej:

systemctl status casaos-gateway

Po uruchomieniu panel sterowania jest dostępny pod adresem http://<your-ip> (protokół HTTP, port 80). Po utworzeniu lokalnego konta następuje logowanie.

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 standardowe oprogramowanie dla serwerów domowych, więc serwer multimediów Jellyfin na VPS lub biblioteka zdjęć Immich można zainstalować w kilka kliknięć. Możliwy jest również import dowolnego docker-compose.yaml, co stanowi główną zaletę: aplikacje to standardowe kontenery, a nie format własnościowy.

TLS i kopie zapasowe – ograniczenia. W tych obszarach widoczne są ograniczenia wersji darmowej. CasaOS domyślnie obsługuje wszystkie usługi przez protokół HTTP, w tym własny panel sterowania. System nie posiada wbudowanej obsługi Let's Encrypt ani harmonogramu kopii zapasowych. Dane są przechowywane w wolumenach Docker w lokalizacji /DATA, a ich zabezpieczenie (np. poprzez cron i restic lub tar) leży po stronie użytkownika.

Brak TLS i ryzyko bezpieczeństwa. Brak szyfrowania nie powoduje błędów. Po instalacji aplikacji i otwarciu http://<your-ip>:8080 usługa działa, ale połączenie jest nieszyfrowane, co przeglądarka oznacza komunikatem "Not Secure". Hasła oraz pliki cookie sesji są przesyłane tekstem jawnym. Dodatkowo w panelu sterowania wykryto luki typu remote-code-execution (CVE-2023-37265 oraz CVE-2023-37266, pozwalające na obejście uwierzytelniania i pełną kompromitację hosta). Bezpośrednie wystawienie portu HTTP na publiczny internet stanowi realne zagrożenie. Rozwiązaniem jest nieudostępnianie CasaOS bezpośrednio do sieci. Należy zastosować reverse proxy obsługujący TLS, na przykład nginx z certyfikatem Let's Encrypt z Certbot, Caddy lub Cloudflare Tunnel, i przekierować ruch do CasaOS wyłącznie w sieci lokalnej. Należy pamiętać, że CasaOS zajmuje port 80, więc proxy i CasaOS będą konkurować o ten port, chyba że port CasaOS zostanie zmieniony.

Koszt. Produkt jest całkowicie darmowy i nie posiada limitów aplikacji. Kosztem jest konieczność samodzielnej konfiguracji TLS, kopii zapasowych oraz wzmacniania zabezpieczeń (hardening).

Coolify: self-hosted PaaS

Opis. Coolify to platform-as-a-service typu open-source do samodzielnego hostowania, działająca na własnym serwerze na wzór Heroku lub Vercel. Podstawową jednostką nie jest "instalacja gotowej aplikacji", lecz "wdrożenie repozytorium Git": po podłączeniu repozytorium Coolify buduje je (za pomocą Nixpacks lub własnego Dockerfile) i wdraża, wykonując redeploy przy każdym pushu. Platforma oferuje również bazy danych i usługi instalowane jednym kliknięciem. Rozwiązanie jest przeznaczone dla programistów, którzy wdrażają własny kod i chcą korzystać z modelu push-to-deploy bez 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 kontynuacją należy sprawdzić, czy kontenery działają poprawnie:

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

Wszystkie kontenery coolify, coolify-db, coolify-redis, coolify-realtime oraz coolify-proxy powinny raportować status 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; osoba, która uzyska do niej dostęp jako pierwsza, przejmuje kontrolę nad serwerem. Następnie należy ustawić domenę instancji oraz skierować rekord DNS typu wildcard (*.example.com lub *.apps.example.com) na serwer, aby Coolify mogło przypisać każdą wdrożoną aplikację do jej własnej subdomeny.

Dodawanie pierwszej aplikacji. Należy podłączyć źródło Git (GitHub, GitLab lub zwykły adres URL repozytorium), wybrać gałąź (branch), ustawić domenę i uruchomić wdrożenie. Wbudowany proxy Traefik od Coolify obsługuje routing subdomeny i żądanie certyfikatu. W przypadku gotowego oprogramowania, katalog Services umożliwia wdrożenie za pomocą kilku kliknięć: stos automatyzacji workflow n8n, który można by skonfigurować ręcznie jest dostępny jako pojedynczy wpis, podobnie jak Uptime Kuma do monitorowania stron statusu.

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 (dumps) Postgres i MySQL do pamięci masowej zgodnej z protokołem S3. Pełna kopia zapasowa instancji (sama konfiguracja Coolify, znajdująca się w /data/coolify) wymaga manualnego działania, dlatego należy samodzielnie wyeksportować i przechować te dane.

Koszt i licencja. Wersja self-hosted jest całkowicie open-source i bezpłatna, bez limitów liczby aplikacji. Dostępna jest opcjonalna, płatna usługa Coolify Cloud, która hostuje warstwę sterującą (control plane), podczas gdy aplikacje nadal działają na własnych serwerach; jest to rozwiązanie wygodne, ale niewymagane.

Błąd: aplikacja została wdrożona, ale domena nie ładuje się. Panel sterowania działa poprawnie na http://<ip>:8000, proces budowania kończy się sukcesem (status green), ale adres URL aplikacji zwraca błąd połączenia lub błąd 404 page not found od Traefik. Wskazuje to na problem z proxy lub DNS, a nie z samą aplikacją. Przyczyny są dwie. Po pierwsze, porty 80 lub 443 były już zajęte w momencie próby uruchomienia proxy, co spowodowało zatrzymanie kontenera 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", jest to inny błąd: Coolify nie może nawiązać komunikacji z gniazdem (socket) Docker serwera, co zazwyczaj wynika z zatrzymania demona Docker lub błędnego klucza SSH. Przed podjęciem działań należy sprawdzić rzeczywistą przyczynę w logach:

docker logs coolify-proxy --tail 100

Napraw błąd na stronie Proxy: wybierz Restart Proxy lub zresetuj konfigurację proxy do ustawień domyślnych i uruchom ją ponownie, a następnie odczekaj około dwie minuty na zakończenie procesu. Port 8000 należy pozostawić dostępnym wyłącznie dla własnego adresu IP (lub tymczasowo otworzyć go w przypadku problemów z proxy), zamiast pozostawiać go otwartym dla wszystkich — port ten służy do obsługi panelu sterowania przez protokół HTTP; dokumentacja Coolify wskazuje, że porty 8000, 6001 i 6002 mogą zostać zamknięte po skonfigurowaniu dostępu do panelu sterowania przez własną domenę.

Obciążenie zasobów na tym samym VPS

Wartości zmierzono w stanie bezczynności na tej samej maszynie z 4GB RAM, przed uruchomieniem jakichkolwiek rzeczywistych obciążeń. Własne parametry należy zweryfikować za pomocą free -m oraz docker stats --no-stream, zamiast polegać na pojedynczej wartości, ponieważ suma zależy od zestawu uruchomionych aplikacji.

• CasaOS jest najlżejszy. Panel to niewielki zestaw usług Go; należy założyć obciążenie rzędu 150 do 300 MB ponad zasoby zużywane przez kontenery.
• Coolify uruchamia własne kontenery wspierające (aplikacja, Postgres, Redis, usługa czasu rzeczywistego oraz Traefik), zatem w stanie bezczynności zużywa około 600 MB do 1 GB przed wdrożeniem czegokolwiek.
• Cloudron jest najbardziej obciążający w spoczynku, ponieważ uruchamia własne instancje nginx, bazy danych, stosu pocztowego oraz monitoringu, niezależnie od tego, czy są one używane; należy zarezerwować 1 do 1.5 GB w stanie bezczynności. Dlatego wymagane jest minimum 2GB, a system działa stabilniej przy 4GB.

Na małym VPS z 2GB, CasaOS pozostawia najwięcej miejsca na rzeczywiste aplikacje, natomiast Cloudron pozostawia najmniej. Jeśli planowany budżet to 2GB, a wymagany jest Cloudron z działającym serwerem pocztowym, należy zaplanować rozszerzenie zasobów maszyny.

Porównanie aktualizacji, kopii zapasowych i uzależnienia od dostawcy

Aktualizacje. Cloudron aktualizuje platformę oraz każdą aplikację według przetestowanego harmonogramu: wymaga to minimalnego nakładu pracy. Coolify aktualizuje się samodzielnie z poziomu panelu za pomocą jednego przycisku. CasaOS aktualizuje panel poprzez skrypt instalacyjny lub apt, natomiast użytkownik musi samodzielnie pobierać i restartować zainstalowane aplikacje.

Uzależnienie od dostawcy (lock-in), problem występujący w drugim roku. CasaOS zapewnia najmniejsze uzależnienie: aplikacje to standardowe projekty Compose, więc pliki docker-compose.yaml oraz wolumeny w /DATA można skopiować na dowolny inny host. Coolify zajmuje pozycję pośrednią: wdrożenia opierają się na własnych plikach Dockerfile i repozytoriach, jednak ich konfiguracja znajduje się w bazie danych Coolify, co wymaga ponownego utworzenia projektów na nowym hostu. Cloudron zapewnia największe uzależnienie: aplikacje są pakowane przez Cloudron; dane można łatwo przenieść dzięki funkcji kopii zapasowych, jednak pakiety aplikacji nie są przenoszalne, co wymusza ponowne wdrożenie na docelowej platformie. Dane są przenoszalne, infrastruktura nie.

Który produkt wybrać

Najpierw krótka wersja, a następnie szczegóły. Wybierz Cloudron, jeśli wymagany jest minimalny nakład pracy przy zarządzaniu serwerem, planowane jest uruchomienie wielu pakietowych aplikacji oraz akceptowana jest roczna opłata za zarządzane usługi TLS, kopie zapasowe i aktualizacje. Wybierz CasaOS, jeśli rozwiązanie ma służyć jako home lab wewnątrz własnej sieci lub reverse proxy, wymagany jest przyjazny interfejs dla Docker oraz brak opłat abonamentowych. Wybierz Coolify, jeśli wymagane jest wdrażanie własnego kodu z Git z funkcją push-to-deploy oraz automatycznym TLS, bez kosztów związanych z usługami PaaS. Jeśli żadna z powyższych opcji nie odpowiada potrzebom, należy zapoznać się z następną sekcją.

Pomiń wszystkie trzy, jeśli...

Należy rzetelnie ocenić skalę operacji. Jeśli uruchamiasz tylko jedno lub dwa aplikacje, bądź też chcesz dokładnie kontrolować zawartość serwera, pomiń panele zarządzania. Narzut systemowy oraz uzależnienie od dostawcy (lock-in) są nieuzasadnione przy małym, stabilnym stosie technologicznym. Metoda DIY polega na użyciu reverse proxy przed własnymi plikami Compose: Traefik z automatycznym TLS przed wieloma aplikacjami Docker Compose zapewnia funkcjonalność HTTPS równoważną rozwiązaniom typu one-click, bez obciążenia panelami, a kopie zapasowe można wykonywać za pomocą zaplanowanego zadania cron restic, którego mechanizm jest w pełni zrozumiały.

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 sytuacja jest jeszcze bardziej oczywista: Instalacja Nextcloud na Docker z TLS i własnym harmonogramem kopii zapasowych to jeden plik Compose i jeden certyfikat. Uruchamianie całego urządzenia (appliance) w celu obsługi jednej aplikacji jest nieefektywne kosztowo. Jeśli nadal rozważasz co uruchomić, zanim zdecydujesz jak, lepszym punktem wyjścia jest przewodnik po tym, co warto hostować samodzielnie w 2026.

FAQ

Czy panel self-hosted jest niezbędny?

Tylko jeśli wymagane są funkcje automatyzujące w wielu aplikacjach: instalacja jednym kliknięciem, automatyczny TLS, harmonogram kopii zapasowych oraz zarządzanie użytkownikami. W przypadku jednej lub dwóch usług, Docker Compose za Traefik zapewnia te same funkcje TLS przy znacznie mniejszym obciążeniu i braku vendor lock-in. Panele są opłacalne przy dużej liczbie aplikacji, gdy koszt czasu pracy przewyższa koszt zużycia pamięci RAM.

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

W środowisku home lab, gdzie nic nie jest wystawione na publiczny internet, CasaOS jest najprostszym rozwiązaniem: oferuje jedną komendę i przyjazny interfejs UI bez opłat. Należy jednak ustawić reverse proxy z obsługą TLS przed wystawieniem usług, ponieważ system przesyła dane protokołem HTTP. Jeśli wymagane jest zarządzane TLS i automatyczne kopie zapasowe oraz akceptowalny jest koszt subskrypcji, Cloudron oferuje największą automatyzację w ramach limitu dwóch darmowych aplikacji.

Czy Cloudron jest darmowy?

Częściowo. Darmowy pakiet pozwala na obsługę dwóch aplikacji, co jest wystarczające do testów lub bardzo małych instalacji. Powyżej tego limitu Cloudron wymaga płatnej subskrypcji (miesięcznej lub rocznej), która umożliwia instalację nieograniczonej liczby aplikacji. Jest to produkt komercyjny z ograniczonym darmowym planem, a nie oprogramowanie free software, dlatego należy uwzględnić koszty w budżecie przy planowaniu rozbudowy stosu technologicznego.

Czy można uruchomić panele obok istniejących aplikacji?

Cloudron: nie. Wymagany jest czysty system Ubuntu. Instalacja zostanie przerwana, jeśli system posiada już zainstalowane nginx, Docker lub Node, ponieważ panel zarządza całym systemem operacyjnym. CasaOS oraz Coolify są bardziej elastyczne, ponieważ instalują własny stos Docker i teoretycznie mogą współdzielić maszynę, jednak oba wymagają portów 80 oraz 443. Powoduje to konflikt z dowolnym serwerem WWW lub proxy. Na maszynie, która już hostuje usługi, panel zazwyczaj nie jest właściwym narzędziem; zaleca się użycie Traefik oraz Compose.

Jak przeprowadzić migrację z panelu w przyszłości?

Należy zaplanować migrację przed usunięciem obecnej instalacji. W przypadku CasaOS należy skopiować docker-compose.yaml aplikacji oraz wolumeny /DATA na nowy host i uruchomić je ponownie. W przypadku Coolify należy wyeksportować konfigurację każdego projektu i wskazać te same repozytoria w docelowym środowisku. W przypadku Cloudron należy przywrócić dane z kopii zapasowych do nowo zainstalowanych aplikacji na nowej platformie, ponieważ pakietowanie Cloudron nie jest przenoszone, a jedynie dane. W każdym przypadku należy przetestować proces przywracania na maszynie testowej przed usunięciem starego serwera.