Jak zainstalować Cloudron na VPS krok po kroku

Instalacja Cloudron na VPS: wersja skrócona

Aby zainstalować Cloudron na serwerze VPS, wymagany jest czysty system Ubuntu, co najmniej 2 GB pamięci RAM oraz domena, dla której można edytować rekordy DNS. Sama instalacja składa się z trzech poleceń i jednego restartu. Większość problemów pojawia się przed tym krokiem (nieodpowiedni obraz bazowy, niewłaściwy typ wirtualizacji) lub po nim (DNS, poczta, kopie zapasowe).

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

Cloudron instaluje, aktualizuje, tworzy kopie zapasowe oraz wystawia certyfikaty TLS (transport layer security) dla hostowanych samodzielnie aplikacji. Każda aplikacja działa w kontenerze Docker, przed wszystkimi znajduje się serwer nginx, a każda aplikacja otrzymuje własną subdomenę w ramach posiadanej domeny. Ten ostatni szczegół jest powodem, dla którego konfigurację DNS należy przeprowadzić w pierwszej kolejności.

Dlaczego Cloudron wymaga określonego systemu operacyjnego

Skrypt instalacyjny sprawdza serwer przed rozpoczęciem instalacji. Niepowodzenie testu oznacza konieczność zamówienia nowego serwera. Należy zapoznać się z wymaganiami przed wyborem obrazu systemu.

• Tylko Ubuntu i tylko trzy wydania. Każdy inny system kończy działanie błędem Cloudron requires Ubuntu 20.04, 22.04, 24.04. Debian, Rocky oraz Alpine nie są wspierane. Ubuntu 24.04 wymaga Cloudron 8 lub nowszego, co skrypt weryfikuje automatycznie.
• Tylko architektura 64-bitowa Intel lub AMD: Error: Cloudron only supports amd64/x86_64. VPS oparty na ARM nie uruchomi oprogramowania.
• Wymagana pełna wirtualizacja sprzętowa. Na VPS opartym na kontenerach skrypt zatrzymuje się z błędem Error: Cloudron does not support lxc, only runs on bare metal or with full hardware virtualization, ponieważ wykrywa kontener za pomocą systemd-detect-virt --container. KVM jest obsługiwany. OpenVZ oraz LXC nie są.
• System plików root musi być ext4 lub xfs. W przypadku innych systemów plików występuje błąd Error: Cloudron requires '/' to be ext4 or xfs, co dotyczy obrazów btrfs oraz zfs.
• Wymagane co najmniej 941 MB pamięci RAM oraz 20 GB na /, mierzone za pomocą free -m oraz rozmiaru systemu plików root.
• Wymagany całkowicie czysty serwer. Jeśli nginx, docker lub node są już zainstalowane, skrypt przerywa pracę z błędem Error: Some packages like nginx/docker/nodejs are already installed..

Ostatni punkt jest najczęściej kwestionowany, dlatego wyjaśniamy jego przyczynę. Cloudron instaluje konkretne wersje Docker, nginx, Node.js oraz MySQL, samodzielnie tworzy konfigurację nginx dla każdej hostowanej aplikacji i zarządza regułami firewalla iptables. Docker zainstalowany wcześniej ma nieodpowiednią wersję, a istniejące pliki konfiguracyjne nginx zostaną nadpisane. Cloudron przejmuje kontrolę nad całą maszyną, dlatego należy przeznaczyć na niego dedykowany VPS.

Jeden dodatkowy test jest często pomijany. Na starszych procesorach bez obsługi AVX (advanced vector extensions) skrypt wyświetla CPU has no AVX support. MongoDB will be disabled, co uniemożliwia instalację każdej aplikacji wymagającej MongoDB. Przed uruchomieniem instalacji należy sprawdzić procesor za pomocą grep -m1 -o avx /proc/cpuinfo, który wyświetla avx na obsługiwanym hoście i nie zwraca nic na starym sprzęcie.

Ile pamięci RAM wymaga Cloudron?

Skrypt odmawia uruchomienia przy wartości poniżej 941 MB, przy użyciu Error: Cloudron requires atleast 1GB physical memory, a dokumentacja zaleca 2 GB pamięci RAM oraz 20 GB miejsca na dysku. Obie te wartości stanowią absolutne minimum dla samej platformy, nie uwzględniając uruchamianych na niej aplikacji. Zanim zainstalujesz pierwszą aplikację, Cloudron już uruchamia Docker, nginx, własną usługę box, kontenery bazodanowe udostępniane aplikacjom (MySQL, PostgreSQL, MongoDB), Redis oraz stos pocztowy. Uruchom docker ps na świeżej instalacji, aby je policzyć.

Limity pamięci dla aplikacji nakładają się na tę bazę. Każdy pakiet aplikacji zawiera niski domyślny limit, który można zwiększyć za pomocą suwaka w widoku zasobów (Resources) danej aplikacji. Gdy aplikacja przekroczy swój limit, restartuje się i wysyła powiadomienie OOM (out of memory), więc serwer, na którym jedna aplikacja ciągle się restartuje, zazwyczaj boryka się z problemem limitu, a nie z błędem oprogramowania.

Poniżej przedstawiam rekomendacje dotyczące rozmiaru serwera. Są to zalecenia dla infrastruktury, której nie trzeba będzie przebudowywać w przyszłym miesiącu. Nie są to wyniki pomiarów benchmarkowych.

[
  {
    "label": "2 apps (free tier)",
    "vcpu": 2,
    "ram_gb": 4,
    "disk_gb": 60
  },
  {
    "label": "5 apps",
    "vcpu": 4,
    "ram_gb": 8,
    "disk_gb": 120
  },
  {
    "label": "10 apps",
    "vcpu": 6,
    "ram_gb": 16,
    "disk_gb": 240
  }
]

Dwie aplikacje działają stabilnie na 4 GB pamięci RAM i 60 GB miejsca na dysku. Około dziesięciu aplikacji wymaga 16 GB pamięci RAM i 240 GB miejsca na dysku, ponieważ bazowe zużycie platformy nie maleje, a każda aplikacja dodaje obraz Docker, bazę danych oraz własne dane. Miejsce na dysku kończy się szybciej, niż można przypuszczać: obrazy, dane aplikacji i lokalne kopie zapasowe współdzielą jeden wolumin, dopóki kopie zapasowe nie zostaną przeniesione poza serwer.

Cloudron zapewnia każdej aplikacji nieograniczony swap, więc ustawiony limit pamięci dotyczy wyłącznie pamięci RAM. Na obrazie VPS bez pliku wymiany (swap file) polecenie swapon --show nie wyświetla żadnych informacji, a presja na pamięć powoduje natychmiastowe restarty OOM zamiast spowolnienia działania aplikacji. Dodanie 2 GB swapu to tanie zabezpieczenie, choć nie zastępuje ono fizycznej pamięci. Różnica w cenie między planami VPS jest niewielka w porównaniu z godzinami poświęconymi na dostrajanie limitów, dlatego warto sprawdzić rzeczywiste koszty VPS i wybrać wyższy wariant.

DNS: rekord wildcard umożliwiający działanie subdomen aplikacji

Cloudron umieszcza panel sterowania pod adresem my.example.com, a każdą aplikację w osobnej subdomenie, dlatego DNS jest wymaganiem wstępnym, a nie późniejszym krokiem. Skieruj te rekordy na publiczny adres IP serwera przed pierwszym otwarciem panelu:

• my.example.com jako rekord A. Jest to adres panelu sterowania.
• *.example.com jako rekord A. Jest to rekord umożliwiający działanie subdomen aplikacji, dzięki czemu wiki.example.com oraz git.example.com będą rozwiązywane w momencie instalacji tych aplikacji.
• example.com jako rekord A, tylko jeśli chcesz, aby aplikacja działała w domenie głównej.

Rekord wildcard ma niższy priorytet niż rekord jawny, więc istniejący rekord www.example.com wskazujący na inny adres będzie nadal działał.

Podczas konfiguracji wybierasz sposób, w jaki Cloudron zarządza DNS:

• Dostawca API. Cloudron przechowuje token dla Cloudflare, DigitalOcean, Route53, Hetzner, Porkbun, Linode, deSEC, Gandi, Namecheap i około dwudziestu innych, a następnie samodzielnie zapisuje każdy rekord, w tym rekordy pocztowe.
• Wildcard. Dodajesz rekord * ręcznie, a Cloudron nie zapisuje żadnych danych.
• Ręczny. Cloudron wyświetla każdy rekord i czeka na jego dodanie przed instalacją każdej pojedynczej aplikacji.

Rekord DNS typu wildcard to nie to samo co certyfikat wildcard. Domyślnym dostawcą certyfikatów jest Let's Encrypt Prod - Wildcard, który potwierdza własność poprzez DNS, więc działa tylko z dostawcą API. W przypadku backendów Wildcard lub Manual, system przełącza się na jeden certyfikat na aplikację, weryfikowany przez HTTP, co oznacza, że port 80 musi pozostać otwarty na stałe. Jeśli Twój rejestrator lub dostawca DNS znajduje się na liście obsługiwanych przez API, skorzystaj z tej opcji: rekordy pocztowe i certyfikaty przestaną być Twoim zmartwieniem.

Zweryfikuj ustawienia przed przejściem dalej. dig +short my.example.com oraz dig +short anything.example.com powinny zwracać adres IP Twojego serwera. Jeśli zapytanie o wildcard nie zwraca wyniku, aplikacje nie będą działać poprawnie, mimo że panel sterowania będzie dostępny.

Jeśli domena znajduje się za Cloudflare, ustaw rekordy w trybie DNS only. Proxy przekazuje tylko ruch HTTP i HTTPS, co powoduje niedziałanie portów pocztowych, a każda aplikacja widzi adres Cloudflare zamiast adresu odwiedzającego.

Uruchomienie skryptu instalacyjnego

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

Skrypt należy uruchomić jako root lub za pomocą sudo, ponieważ w przeciwnym razie pierwszym komunikatem będzie This script should be run as root.. Instalacja trwa kilka minut i przebiega w trybie cichym, gdyż dane wyjściowe apt oraz obrazy pobierane przez Docker są kierowane do pliku dziennika. Proces można monitorować z poziomu drugiej sesji SSH:

tail -f /var/log/cloudron-setup.log

Na końcu wyświetlony zostanie komunikat After reboot, visit one of the following URLs and accept the self-signed certificate to finish setup. wraz z adresem serwera, a następnie pojawi się pytanie The server has to be rebooted to apply all the settings. Reboot now ? [Y/n]. Należy odpowiedzieć twierdząco. Flaga --skip-reboot jest dostępna, jeśli wymagane jest zaplanowanie restartu, jednak Cloudron nie będzie gotowy do pracy, dopóki serwer nie zostanie ponownie uruchomiony.

Pierwsze uruchomienie: domena, backend DNS i konto administratora

Otwórz https://<server-ip> i zaakceptuj ostrzeżenie przeglądarki. Certyfikat jest podpisany samodzielnie, ponieważ Cloudron nie zna jeszcze Twojej domeny, więc nie ma możliwości zwrócenia się do urzędu certyfikacji. W przeglądarce Chrome kliknij Advanced, a następnie Proceed to <ip> (unsafe). W przeglądarce Firefox kliknij Advanced, a następnie Accept the Risk and Continue.

Pierwszy ekran prosi o podanie domeny. Wpisz example.com, a panel sterowania zostanie przypisany do my.example.com. Możesz użyć subdomeny, takiej jak cloudron.example.com, wtedy panel będzie dostępny pod adresem my.cloudron.example.com. Wybierz backend DNS, wklej token API, jeśli go posiadasz, i utwórz konto administratora, używając adresu e-mail, do którego masz stały dostęp: jest on używany do rejestracji w Let’s Encrypt oraz do wysyłania wszystkich powiadomień z platformy.

Po zapisaniu ustawień Cloudron wystąpi o certyfikaty i przeniesie panel sterowania pod adres https://my.example.com. Adres URL oparty na adresie IP przestanie w tym momencie działać, dlatego należy dodać nowy adres do zakładek.

Certyfikaty: co podlega odnowieniu i kiedy proces zostaje przerwany

Odnowienie certyfikatu odbywa się automatycznie zgodnie z protokołem ACME Renewal Information (ARI) oraz harmonogramem publikowanym przez urząd certyfikacji, co w praktyce oznacza odnowienie na około miesiąc przed wygaśnięciem. Nieudana próba odnowienia skutkuje wysłaniem wiadomości e-mail do administratora, a wygasły certyfikat zostaje zastąpiony wbudowanym certyfikatem z podpisem własnym. To właśnie ten mechanizm awaryjny jest przyczyną ostrzeżeń przeglądarki na stronach, które jeszcze wczoraj działały poprawnie.

Większość problemów wynika z dwóch przyczyn. Walidacja HTTP wymaga otwartego portu 80, więc zamknięcie tego portu z założeniem, że „wszystko i tak działa przez HTTPS”, przerywa proces odnowienia dla każdej aplikacji korzystającej z certyfikatów typu Wildcard lub ręcznej walidacji DNS. Walidacja DNS wymaga tokena API z aktywnymi uprawnieniami do zapisu, więc rotacja lub ograniczenie zakresu uprawnień tego tokena powoduje ciche przerwanie odnowień, aż do momentu otrzymania powiadomienia e-mail.

Widok Domains zawiera przycisk Renew All, który pozwala na natychmiastowe wymuszenie próby odnowienia, oraz dostawcę Let's Encrypt Staging do celów testowych. Certyfikaty z środowiska Staging nie są uznawane przez przeglądarki, co jest zamierzonym działaniem: pozwala to na wielokrotne ponawianie prób bez wyczerpywania limitów produkcyjnych.

Czy należy korzystać z wbudowanego serwera poczty?

Cloudron dostarcza kompletny stos pocztowy z obsługą skrzynek IMAP, protokołem submission, filtrami sieve oraz podpisami DKIM (DomainKeys Identified Mail). Funkcję tę aktywuje się dla każdej domeny w sekcji Email w panelu sterowania. Najtrudniejszym zadaniem jest zapewnienie dostarczalności poczty, co nie wynika z ograniczeń samego Cloudron.

• Port wyjściowy 25 jest blokowany przez większość dostawców VPS w celu przeciwdziałania spamowi. Niektórzy dostawcy odblokowują go po zgłoszeniu do działu wsparcia. Przetestuj połączenie z serwera za pomocą nc -zv aspmx.l.google.com 25 (zainstaluj netcat-openbsd, jeśli polecenie jest niedostępne). Otwarte porty zwracają raport succeeded, natomiast zablokowany port zawiesza się do momentu przekroczenia limitu czasu.
• Rekord PTR (reverse DNS) jest ustawiany przez dostawcę VPS, a nie przez hosta DNS, i musi być zgodny z nazwą hosta serwera pocztowego. Poczta wysyłana z adresu z generycznym rekordem PTR trafia do folderów ze spamem.
• Rekordy SPF, DKIM oraz DMARC są generowane automatycznie w przypadku korzystania z backendu DNS opartego na API. W przypadku backendów typu Wildcard lub Manual należy dodać je ręcznie; brak rekordu DKIM sprawia, że każda podpisana wiadomość jest niemożliwa do zweryfikowania.

Konfiguracją sprawdzającą się w większości przypadków jest odbieranie poczty przez Cloudron i wysyłanie jej za pośrednictwem przekaźnika (relay), takiego jak SendGrid, Postmark, Mailgun lub Amazon SES, skonfigurowanego w widoku Email. Przekaźnik musi zezwalać na wysyłkę z dowolnego adresu w domenie, w przeciwnym razie powiadomienia z aplikacji od różnych nadawców będą odrzucane. Jeśli poczta jest głównym powodem zakupu serwera, należy uruchomić dedykowany serwer pocztowy, taki jak Mailcow na oddzielnej maszynie z własną reputacją adresu IP.

Jeśli w ogóle nie korzystasz z funkcji poczty Cloudron, zablokuj porty 25, 465, 587, 993 oraz 4190 w zaporze sieciowej dostawcy. Należy to zrobić na poziomie infrastruktury zewnętrznej, a nie na serwerze, ponieważ Cloudron samodzielnie zarządza regułami iptables i zakłada, że ma nad nimi wyłączną kontrolę. Jest to przeciwieństwo standardowego VPS, gdzie regułami ufw zarządza się samodzielnie.

Skonfiguruj miejsce docelowe kopii zapasowych, zanim będą potrzebne

Domyślnie kopie zapasowe trafiają do lokalnego systemu plików w /var/backups, na ten sam dysk, na którym znajdują się pozostałe dane. Dokumentacja jest w tej kwestii jednoznaczna: „Przechowywanie kopii zapasowych na tym samym fizycznym dysku co serwer platformy jest niebezpieczne”. Awaria jednego dysku powoduje utratę zarówno aplikacji, jak i kopii zapasowych.

Otwórz sekcję Backups, następnie Backup Sites i już pierwszego dnia wskaż inną lokalizację. Standardowym rozwiązaniem jest pamięć obiektowa zgodna z S3 (Backblaze B2, Wasabi, Cloudflare R2, DigitalOcean Spaces lub bucket MinIO na drugim serwerze), choć obsługiwane są również protokoły SSHFS, NFS, CIFS oraz zwykłe systemy plików.

O wartości kopii zapasowej decydują trzy ustawienia:

• Format. tgz tworzy jedno skompresowane archiwum dla każdej aplikacji i przy każdym uruchomieniu przesyła całość ponownie. rsync przesyła tylko zmienione pliki, co jest znacznie tańsze w przypadku dużych instancji Nextcloud, ale wiąże się z większą liczbą zapytań do API pamięci masowej.
• Szyfrowanie. Opcjonalny standard AES-256 obejmujący zarówno zawartość plików, jak i ich nazwy. Cloudron nie przechowuje kopii hasła, więc jego utrata oznacza, że kopii zapasowych nie będzie w stanie odszyfrować nikt, w tym sam użytkownik. Zapisz hasło w samodzielnie hostowanym menedżerze haseł przed kliknięciem przycisku zapisu.
• Retencja. Określana jako liczba, na przykład 7 dziennych i 4 tygodniowe. Długa retencja w pamięci obiektowej generuje comiesięczne koszty, dlatego należy wybrać wartość, za którą użytkownik jest gotów płacić.

Następnie przetestuj przywracanie danych. Zainstaluj małą aplikację, przywróć ją z poziomu panelu sterowania i sprawdź, czy dane zostały poprawnie odtworzone. Kopia zapasowa, której nigdy nie przywrócono, jest jedynie przypuszczeniem, że dane są bezpieczne.

Limity darmowego planu

Według stanu na sierpień 2026 r. darmowy plan jest ograniczony do dwóch zainstalowanych aplikacji. Wszystkie pozostałe funkcje są dostępne w pakiecie: aktualizacje aplikacji, kopie zapasowe dla poszczególnych aplikacji, firewall, serwer pocztowy oraz single sign-on. Trzecia aplikacja to moment, w którym wymagana jest licencja. Płatne plany znoszą limit aplikacji, a wyższy z nich dodaje grupy użytkowników i role, serwer katalogowy oraz możliwość tworzenia kopii zapasowych w wielu lokalizacjach. Ceny ulegają zmianom, dlatego należy sprawdzać stronę z cennikiem Cloudron, zamiast polegać na liczbach podanych w poradniku.

Licencja obejmuje jedną instalację Cloudron, więc dwa małe serwery kosztują dwukrotnie więcej niż jeden większy. Taki model cenowy skłania większość użytkowników do korzystania z jednego, większego VPS, co jest sprzeczne z typową poradą, aby rozpraszać usługi na wiele maszyn. Należy odpowiednio dobrać rozmiar serwera, mając to na uwadze, ponieważ późniejszy podział usług oznacza konieczność opłacenia dwóch licencji.

Gdy wystąpi awaria

Rozpocznij od wbudowanego narzędzia diagnostycznego. Sprawdza ono kolejno DNS, certyfikaty, dysk, pamięć oraz każdą usługę, wskazując test, który zakończył się niepowodzeniem:

sudo cloudron-support --troubleshoot

Następnie użyj standardowych narzędzi systemd (menedżera systemu i usług). systemctl status box raportuje stan samej usługi Cloudron, journalctl -u box -n 100 wyświetla jej ostatnie logi, a journalctl -u docker dotyczy działającego w tle środowiska uruchomieniowego kontenerów. Wszelkie błędy, które wystąpiły podczas instalacji, znajdują się w /var/log/cloudron-setup.log.

Jeśli panel sterowania nie ładuje się, przyczyną jest zazwyczaj konfiguracja DNS lub firewall dostawcy, a nie sam Cloudron. Uruchom dig +short my.example.com ze swojego laptopa i potwierdź, że porty 80 oraz 443 są otwarte w firewallu sieciowym dostawcy, który jest zarządzany niezależnie od reguł samego serwera. W przypadku ponownej instalacji skrypt odmówi wykonania drugiego uruchomienia z komunikatem Error: Cloudron is already installed. To reinstall, start afresh; najczystszym rozwiązaniem jest wówczas ponowne przygotowanie serwera.

Kiedy Cloudron nie jest odpowiednim rozwiązaniem

Cloudron sprawdza się, gdy użytkownik oczekuje gotowych aplikacji, a nie zarządzania infrastrukturą. Rozwiązanie to nie pasuje, jeśli celem jest uruchamianie własnych kontenerów we własny sposób, ponieważ Cloudron przejmuje kontrolę nad Nginx, Docker oraz firewallem i nadpisuje wszelkie wprowadzone tam zmiany. Jeśli plan zakłada korzystanie z folderu plików compose, Traefik przed własnymi stosami Docker Compose zapewnia taką samą automatyzację TLS i routing subdomen bez konieczności instalowania dodatkowej platformy. Jeśli wybór nie został jeszcze dokonany, porównanie Cloudron, CasaOS i Coolify zestawia te narzędzia obok siebie, a szersza lista usług do samodzielnego hostowania stanowi lepszy punkt wyjścia niż przewodnik instalacji.

FAQ

Ile pamięci RAM wymaga Cloudron na serwerze VPS?

Skrypt instalacyjny przerywa działanie przy wartości poniżej 941 MB, a dokumentacja zaleca 2 GB, jednak jest to wartość minimalna dla samej platformy bez zainstalowanych aplikacji. Cloudron uruchamia Docker, nginx, własną usługę box, kontenery bazodanowe oraz stos pocztowy od momentu pierwszego uruchomienia. Należy zaplanować 4 GB dla dwóch aplikacji oraz 16 GB dla około dziesięciu. Warto dodać plik wymiany (swap), ponieważ Cloudron zapewnia aplikacjom nieograniczony dostęp do pamięci swap, a serwer bez niej w przypadku dużego obciążenia pamięci będzie wymuszał restarty.

Czy mogę zainstalować Cloudron na systemie Debian lub na serwerze z już działającym Dockerem?

Nie jest to możliwe. Skrypt sprawdza wersję systemu i przerywa pracę z błędem Cloudron requires Ubuntu 20.04, 22.04, 24.04, dlatego Debian, Rocky oraz Alpine nie są wspierane. Instalacja zatrzymuje się również, gdy wykryte zostaną nginx, docker lub node, ponieważ platforma instaluje własne, sztywno określone wersje tych komponentów oraz samodzielnie zarządza konfiguracją nginx i regułami iptables. Należy rozpocząć od czystego obrazu Ubuntu na serwerze VPS typu KVM.

Dlaczego moje subdomeny aplikacji nie działają, mimo że panel sterowania jest dostępny?

Brakuje rekordu DNS typu wildcard. Instalacja tworzy lub wymaga rekordu A dla my.example.com, dzięki czemu panel sterowania jest rozpoznawany, podczas gdy wiki.example.com zwraca błąd NXDOMAIN, a przeglądarka informuje o braku witryny. Należy dodać rekord A dla *.example.com wskazujący na adres IP serwera, a następnie zweryfikować poprawność za pomocą dig +short wiki.example.com przed instalacją aplikacji.

Czy muszę korzystać z serwera pocztowego Cloudron?

Nie. Można wyłączyć obsługę poczty przychodzącej i korzystać z zewnętrznego przekaźnika (relay), takiego jak Postmark, Mailgun lub Amazon SES. Jest to bezpieczniejsze rozwiązanie, jeśli dostawca blokuje port wychodzący 25 lub gdy adres IP nie posiada reputacji w systemach pocztowych. Jeśli całkowicie rezygnujesz z funkcji Cloudron Email, zamknij porty 25, 465, 587, 993 oraz 4190 w zaporze sieciowej dostawcy, zamiast na samym serwerze.

Co się stanie po osiągnięciu limitu dwóch aplikacji w planie darmowym?

Panel sterowania blokuje możliwość instalacji trzeciej aplikacji i prosi o klucz licencyjny. Aplikacje już działające pozostają nienaruszone: są nadal aktualizowane, tworzone są ich kopie zapasowe, a certyfikaty pozostają ważne. Dodanie licencji znosi limit bez konieczności ponownej instalacji czegokolwiek, dlatego plan darmowy jest odpowiednim sposobem na przetestowanie platformy na rzeczywistej domenie.