Coolify, własny PaaS na własnym serwerze

Coolify, własny PaaS na własnym serwerze

Coolify to samodzielnie hostowana platforma wdrożeniowa: instalujesz ją na własnym serwerze i dostajesz wdrożenia prosto z repozytorium, bazy danych, certyfikaty TLS oraz środowiska podglądowe. Repozytorium coollabsio/coolify ma około 60,8 tysiąca gwiazdek i licencję Apache 2.0, a bieżące wydanie stabilne nosi numer 4.3.9 z 18 sierpnia 2026 roku.

Co Coolify robi na Twoim serwerze

Po instalacji dostajesz panel webowy, który zarządza Dockerem na jednej maszynie albo na kilku maszynach naraz. Wskazujesz repozytorium, Coolify buduje z niego obraz, uruchamia kontener i podpina go pod reverse proxy, który sam wystawia certyfikat. To jest cały mechanizm i nie ma w nim magii, jest za to sporo kleju, którego nie musisz pisać sam.

Warstwa budowania opiera się na pakietach budujących. Do wyboru masz Nixpacks, który sam wykrywa technologię projektu, tryb statyczny serwowany przez Nginx, własny Dockerfile, Docker Compose dla aplikacji wieloskładnikowych oraz gotowy obraz z rejestru. Źródłem kodu może być publiczne repozytorium, repozytorium prywatne podpięte przez aplikację GitHuba albo przez klucz wdrożeniowy.

Ruch obsługuje Traefik albo Caddy, do wyboru. Certyfikaty wystawiane są automatycznie, pod warunkiem że port 80 jest otwarty, bo tędy idzie weryfikacja domeny. Dla każdej aplikacji podajesz porty do wystawienia, a pierwszy z nich staje się domyślnym portem sprawdzania kondycji kontenera.

Oprócz aplikacji Coolify uruchamia bazy danych i gotowe usługi. Wsparcie obejmuje PostgreSQL, MySQL, MariaDB, MongoDB, Redis i kilka innych silników, a katalog jednoklikowych usług liczy według opisu repozytorium ponad 280 pozycji. Każda z nich to po prostu przygotowany plik Compose, który możesz następnie nadpisać własnym.

Czego Coolify nie robi, też trzeba powiedzieć wprost. Nie ma sieci dostarczania treści, nie ma funkcji brzegowych, nie ma skalowania poziomego uruchamianego samoczynnie pod ruchem. Nie ma też rozwiązania problemu, że Twój serwer stoi w jednym miejscu na świecie. Jeśli potrzebujesz treści blisko użytkownika w kilkunastu regionach, Coolify tego nie zastąpi i sensowniej jest postawić przed nim Cloudflare.

Wersja, licencja i stan projektu

Projekt istnieje od stycznia 2021 roku i rozwija się szybko. Repozytorium ma 5318 rozgałęzień, 670 otwartych zgłoszeń, nie jest zarchiwizowane, a ostatnia zmiana w gałęzi głównej pochodzi z 20 sierpnia 2026 roku. Za całością stoi węgierska spółka coolLabs Solutions Kft.

Z numerem wersji wiąże się drobna pułapka, na którą warto zwrócić uwagę przy przypinaniu obrazu. Plik versions.json w gałęzi głównej wskazuje dla kanału v4 wersję 4.3.10, ale najnowszym opublikowanym wydaniem stabilnym jest 4.3.9. Do tego istnieje 4.4-rc.1 oznaczone jako wydanie przedpremierowe. Numer z gałęzi głównej wyprzedza więc to, co faktycznie zostało wydane, i jeśli budujesz automatyzację wokół tego pliku, sprawdzaj oba źródła.

# co uwaza sie za biezaca wersje: galaz glowna kontra opublikowane wydanie
curl -s https://raw.githubusercontent.com/coollabsio/coolify/main/versions.json

curl -s https://api.github.com/repos/coollabsio/coolify/releases/latest \
  | grep '"tag_name"'

Licencja jest prosta i to rzadka sytuacja w tej kategorii narzędzi. W katalogu głównym repozytorium leży jeden plik LICENSE z pełnym tekstem Apache License 2.0, interfejs programistyczny GitHuba raportuje apache-2.0, i nie ma osobnego katalogu z kodem przeznaczonym dla klientów komercyjnych. Nie ma też pakietu dodatkowego, którego instalacja wciągałaby licencję zastrzeżoną. Cała funkcjonalność, którą widzisz w wariancie płatnym, siedzi w tym samym otwartym kodzie.

Ta jednolitość ma praktyczny skutek: wariant samodzielnie hostowany nie jest wersją okrojoną. Producent nie trzyma niczego za bramką licencyjną, więc nie musisz sprawdzać przy każdym wydaniu, czy funkcja, na której polegasz, nie przeniosła się do płatnego katalogu.

Ryzyko leży gdzie indziej. Projekt niesie jeden dominujący utrzymujący i firmę o niewielkiej skali, a numeracja wydań idzie w tempie kilku na tydzień. Aktualizacja potrafi zmienić zachowanie proxy albo sposób generowania plików Compose, a Ty poznasz to na własnej instalacji, nie na środowisku testowym producenta.

Wymagania serwera, instalacja i porty

Minimum sprzętowe podane w dokumentacji to dwa rdzenie procesora, 2 GB pamięci i 30 GB wolnego miejsca. Producent zaznacza, że przy niższych parametrach Coolify prawdopodobnie ruszy, ale zaleca zapas, bo w tej samej pamięci mieszczą się jeszcze Twoje aplikacje i procesy budowania. Architektura musi być 64-bitowa, amd64 albo arm64.

Lista obsługiwanych systemów jest szeroka: dystrybucje oparte na Debianie, na Red Hacie, na SUSE, Arch Linux, Alpine Linux oraz 64-bitowy Raspberry Pi OS. Skrypt instalacyjny automatycznie obsługuje wyłącznie wydania Ubuntu z długim wsparciem, czyli 20.04, 22.04 i 24.04. Na Ubuntu spoza tej listy, na przykład 24.10, zostaje instalacja ręczna. Na części dystrybucji, wymieniany jest AlmaLinux, Docker musi być zainstalowany wcześniej. Wymagany silnik Dockera to wersja 24 albo nowsza.

# minimum: 2 rdzenie, 2 GB RAM, 30 GB wolnego miejsca, amd64 albo arm64
curl -fsSL https://cdn.coollabs.io/coolify/install.sh | sudo bash

# porty wymagane przy dostepie po adresie IP serwera
# 8000 panel, 6001 komunikacja w czasie rzeczywistym, 6002 terminal
# 22 SSH, 80 wystawienie certyfikatu, 443 ruch HTTPS

# klucz publiczny musi trafic do roota na kazdym zarzadzanym serwerze
cat ~/.ssh/coolify.pub >> /root/.ssh/authorized_keys

Port 6002 obsługuje terminal w panelu i jest wymagany od wersji 4.0.0-beta.336. Po podpięciu własnej domeny do panelu porty 8000, 6001 i 6002 można zamknąć, bo ruch pójdzie przez proxy na 443. Zostają wtedy 22, 80 i 443.

Zamykanie portów ma tu jednak haczyk, który zaskakuje ludzi przyzwyczajonych do zwykłych serwerów. Docker zapisuje własne reguły iptables oparte na translacji adresów i potrafi ominąć UFW, więc blokada zapisana w UFW nie zadziała tak, jak się spodziewasz. Dokumentacja zaleca zaporę po stronie dostawcy chmury, a jeśli dostawca jej nie ma, narzędzie ufw-docker utrzymywane przez społeczność.

Połączenie z każdym zarządzanym serwerem idzie po SSH z uwierzytelnianiem kluczem, a klucz publiczny musi znaleźć się w pliku authorized_keys użytkownika root. Coolify potrafi wygenerować parę kluczy z poziomu panelu. Można też trzymać instancję i aplikacje na jednej maszynie, ale dokumentacja tego nie zaleca, bo obciążenie od budowania potrafi wyłączyć panel w chwili, w której najbardziej go potrzebujesz.

Przy kilku serwerach trzeba zrozumieć jedną rzecz, żeby nie tracić godzin na diagnostykę DNS. Każdy podłączony serwer uruchamia własne proxy i obsługuje ruch swoich aplikacji sam. Serwer główny daje wyłącznie panel, wykonuje połączenia SSH i sprawdza kondycję, natomiast nie przekazuje ruchu dalej. Domenę kierujesz więc na adres serwera, na którym stoi aplikacja, a nie na adres instancji Coolify.

Wdrożenia z repozytorium, zmienne i środowiska podglądowe

Wdrożenie po każdym wypchnięciu zmian działa tylko dla repozytoriów podpiętych przez aplikację GitHuba, bo wtedy Coolify dostaje webhooki. Ta sama zależność dotyczy środowisk podglądowych uruchamianych samoczynnie: włącznik istnieje wyłącznie w tym trybie i domyślnie jest wyłączony. Przy repozytorium publicznym albo kluczu wdrożeniowym zostaje ręczne uruchomienie wdrożenia dla wybranego zgłoszenia zmian.

Adres środowiska podglądowego buduje się z szablonu, domyślnie {{pr_id}}.{{domain}}. Zgłoszenie o numerze 123 przy domenie example.com trafia więc pod 123.example.com, co wymaga wpisu wieloznacznego w DNS i certyfikatu obejmującego poddomeny. Gdy zasób ma kilka domen, do szablonu wchodzi pierwsza z nich.

Zmienne środowiskowe mają dwa niezależne przełączniki: dostępność w fazie budowania i dostępność w działającym kontenerze. Oba są włączone domyślnie. Panel oferuje widok deweloperski, w którym cały zestaw edytujesz jako zwykły plik w formacie klucz i wartość.

# widok deweloperski: caly zestaw zmiennych w formacie .env
NODE_ENV=production
DATABASE_URL=postgres://app:$DB_PASSWORD@postgres:5432/app_production

# zmienna predefiniowana przez Coolify, skrot rewizji z ktorej powstal obraz
NEXT_PUBLIC_COMMIT=$SOURCE_COMMIT

# zmienne wspoldzielone: zespol, projekt, srodowisko
SMTP_HOST={{team.SMTP_HOST}}
SENTRY_ENVIRONMENT={{environment.NODE_ENV}}

Dwa pola potrafią oszczędzić wieczora. Przełącznik Literal wyłącza rozwijanie odwołań, więc hasło zawierające znak dolara przestaje być traktowane jak nazwa innej zmiennej. Przełącznik Multiline zachowuje łamania linii dla kluczy prywatnych i certyfikatów, a wartość wielolinijkowa jest przy wdrożeniu obejmowana pojedynczymi cudzysłowami, co blokuje interpretację przez powłokę. Wartości wielolinijkowe i zablokowane sekrety edytujesz wyłącznie w widoku zwykłym.

Osobna sprawa to sekrety w fazie budowania. Domyślnie zmienne budowania idą jako --build-arg, a ich wartości zostają w metadanych obrazu i widać je w docker history. Opcja sekretów budowania Dockera przełącza to na --secret id=KEY,env=KEY, wymaga BuildKit i silnika Dockera od wersji 18.09, a Coolify sam dopisuje dyrektywę składni i montowania.

# syntax=docker/dockerfile:1
FROM node:22-alpine
WORKDIR /app
COPY package.json package-lock.json ./
RUN --mount=type=secret,id=NPM_TOKEN npm ci
COPY . .
RUN --mount=type=secret,id=NPM_TOKEN npm run build
CMD ["node", "server.js"]

Wartość sekretu jest w danym kroku widoczna jako zmienna środowiskowa i nie zostaje w warstwach obrazu. Coolify liczy z sekretów skrót zapisywany jako COOLIFY_BUILD_SECRETS_HASH i na tej podstawie unieważnia pamięć podręczną budowania dopiero wtedy, gdy sekret się zmienił. Jeśli na serwerze budującym nie ma BuildKit, mechanizm cicho wraca do --build-arg, więc przy wrażliwych tokenach sprawdź to jawnie.

Przy publikowaniu portu na hosta tracisz aktualizacje kroczące, bo dwie instancje nie mogą jednocześnie trzymać tego samego portu. Wycofanie zmiany działa wyłącznie na obrazach dostępnych lokalnie. Sprawdzanie kondycji jest domyślnie włączone dla wszystkich kontenerów, a Traefik nie skieruje ruchu do kontenera, który ma zdefiniowane sprawdzanie i wypada w nim źle. To najczęstsza przyczyna błędu 502 zaraz po pierwszym wdrożeniu.

Kopie zapasowe, aktualizacje i dyżur pod telefonem

Tutaj leży sedno wyboru między Coolify a usługą zarządzaną. Panel automatyzuje zrzuty baz danych i potrafi wysyłać je do dowolnego magazynu zgodnego z S3, ale to Ty konfigurujesz harmonogram, Ty pilnujesz miejsca i, co ważniejsze, Ty sprawdzasz, czy odtworzenie w ogóle działa. Kopia, której nikt nigdy nie odtworzył, jest kopią wyłącznie z nazwy.

# zrzut w formacie custom, dokladnie taki uruchamia Coolify dla PostgreSQL
pg_dump --format=custom --no-acl --no-owner --username postgres app_production

# odtworzenie na innej maszynie
pg_restore --verbose --clean -h localhost -U postgres -d postgres \
  pg-dump-postgres-1697207547.dmp

# odpowiedniki dla pozostalych silnikow
mysqldump -u root -p"$MYSQL_ROOT_PASSWORD" app_production
mariadb-dump -u root -p"$MYSQL_ROOT_PASSWORD" app_production
mongodump --authenticationDatabase=admin --uri="$MONGO_URI" --gzip --archive=dump.gz

Format custom w PostgreSQL nie jest plikiem SQL, więc odtwarzasz go przez pg_restore, a nie przez psql. Ustaw sobie w kalendarzu kwartalne odtworzenie zrzutu na maszynie testowej, bo to jedyny sposób, żeby dowiedzieć się o problemie wcześniej niż w dniu awarii.

Aktualizacje instancji można zostawić automatyczne albo uruchamiać ręcznie. W obu przypadkach odpowiedzialność jest Twoja: nikt nie wycofa nieudanego wydania za Ciebie, nikt nie odbierze telefonu, gdy proxy przestanie odnawiać certyfikat, i nikt nie zauważy, że dysk zapełnił się warstwami starych obrazów. To ostatnie zdarza się często, dlatego Coolify ma osobny mechanizm sprzątania Dockera, który trzeba włączyć świadomie.

Do tego dochodzi zależność od Twojego dostawcy serwera. Kiedy padnie jedyna maszyna w jedynym centrum danych, aplikacja jest niedostępna do czasu, aż ktoś ją podniesie. Dostawcy zarządzani rozkładają to ryzyko na wiele regionów i wliczają w cenę. Przy Coolify płacisz mniej i to Ty jesteś tym rozłożeniem ryzyka.

Warto policzyć ten koszt w godzinach, zanim policzysz go w pieniądzach. Jeżeli utrzymujesz kilkanaście własnych projektów, godzina miesięcznie na aktualizacje i przeglądy jest ceną świetną. Jeżeli obsługujesz jednego klienta produkcyjnie i nie masz nikogo na zastępstwo w czasie urlopu, ta sama godzina bywa ceną złą.

Cennik i wariant zarządzany

Wariant samodzielnie hostowany jest darmowy bezterminowo, bez ograniczeń funkcji, bez limitu wdrożeń, zespołów, użytkowników i podłączonych serwerów. Płacisz wyłącznie za serwer, na którym to stoi.

Coolify Cloud kosztuje 5 dolarów miesięcznie w cenie bazowej obejmującej podłączenie dwóch serwerów, plus 3 dolary miesięcznie za każdy kolejny serwer. Rozliczenie roczne obniża rachunek o 20 procent. Kupujesz w tym wariancie wyłącznie panel działający na infrastrukturze producenta: serwery pod aplikacje przynosisz własne, z dowolnego dostawcy, a aplikacje nadal wdrażają się na Twoje maszyny.

Różnice sprowadzają się do obsługi. W chmurze producent utrzymuje panel, wykonuje jego aktualizacje i kopie zapasowe, daje adres app.coolify.io bez konfigurowania własnej domeny oraz powiadomienia pocztą bez stawiania własnego serwera SMTP. Na serwerach podłączonych do wariantu chmurowego wystarczy otworzyć porty 22, 80 i 443. Jedno ograniczenie jest wymienione wprost w tabeli producenta: liczba zespołów jest nieograniczona, ale każdy dodatkowy zespół wymaga osobnej subskrypcji.

Sprawa istotna dla oceny ryzyka: chmura oparta jest o ten sam otwarty kod, więc rezygnacja z subskrypcji nie odbiera Ci narzędzia. Zostajesz z tymi samymi kontenerami na tych samych serwerach i możesz postawić panel u siebie. To zupełnie inna sytuacja niż przy platformach zamkniętych, gdzie odejście oznacza przepisanie konfiguracji wdrożeń od zera.

Coolify a alternatywy

Wybór jest właściwie decyzją o tym, czym chcesz płacić. Przy stałym, przewidywalnym obciążeniu jeden serwer za kilkanaście dolarów miesięcznie obsłuży kilkanaście aplikacji, które u dostawcy zarządzanego kosztowałyby wielokrotność tej kwoty. Przy ruchu skokowym i przy zespole, który nie ma nikogo od infrastruktury, rozliczenie za zużycie i cudzy dyżur są warte swojej ceny.

Jest jeszcze trzecia droga, przydatna zanim cokolwiek postawisz na serwerze. Do pokazania klientowi wersji roboczej z laptopa wystarczy tunel w rodzaju Portless, bez stawiania czegokolwiek trwałego.

Najbliższym krewnym jest Dokploy, który rozwiązuje ten sam problem, ale inaczej dzieli licencję. Rdzeń jest na Apache 2.0, więc odsprzedaż hostingu klientom jest dozwolona, natomiast katalogi oznaczone jako proprietary podlegają własnej licencji źródłowo dostępnej i produkcyjne użycie tego, co w nich siedzi, czyli logowania jednokrotnego, SCIM, dziennika audytowego i ról własnych, wymaga umowy handlowej. Druga rzecz warta uwagi przy audycie: plik licencyjny nazywa się tam LICENSE.MD wielkimi literami, więc narzędzie szukające LICENSE albo LICENSE.md po prostu go nie znajdzie.

Typowe błędy

Pierwszy to instalacja Coolify na maszynie, na której już coś działa. Dokumentacja zaleca świeży serwer, bo instalator dokłada Dockera, proxy i własne sieci, a konflikt portu 80 albo istniejąca konfiguracja Nginx potrafią zablokować wystawianie certyfikatów.

Drugi to poleganie na UFW. Docker zapisuje reguły iptables z translacją adresów, które omijają UFW, więc port zablokowany w UFW nadal bywa dostępny z sieci. Używaj zapory po stronie dostawcy albo ufw-docker.

Trzeci to skierowanie DNS na serwer główny przy konfiguracji wieloserwerowej. Serwer z panelem nie przekazuje ruchu do aplikacji stojących na innych maszynach, więc rekord musi wskazywać serwer docelowy.

Czwarty to oczekiwanie samoczynnych środowisk podglądowych przy repozytorium podpiętym kluczem wdrożeniowym. Ta funkcja, podobnie jak wdrożenie po wypchnięciu zmian, działa wyłącznie przy podpięciu przez aplikację GitHuba.

Piąty to trzymanie tokenów w zmiennych budowania bez sekretów Dockera. Wartości przekazane jako --build-arg zostają w metadanych obrazu i odczyta je każdy, kto ma do niego dostęp.

Szósty to konfiguracja kopii zapasowych bez ani jednej próby odtworzenia. Zrzut PostgreSQL w formacie custom odtwarza się przez pg_restore, a nie przez psql, i lepiej dowiedzieć się tego w spokojny wtorek niż w trakcie awarii.

Siódmy to brak sprzątania po Dockerze. Stare obrazy i warstwy budowania rosną, aż zapełnią dysk, a wtedy przestaje działać wszystko naraz, łącznie z panelem, przez który chciałbyś to naprawić.

FAQ

Czy Coolify jest naprawdę darmowy?

Tak. Wariant samodzielnie hostowany jest darmowy bezterminowo, bez ograniczeń funkcji i bez limitu serwerów, wdrożeń czy użytkowników. Płatny jest tylko Coolify Cloud, czyli panel utrzymywany przez producenta, w cenie 5 dolarów miesięcznie za dwa podłączone serwery i 3 dolary za każdy kolejny. Serwery pod aplikacje w obu wariantach są Twoje.

Jaki serwer wystarczy na start?

Dokumentacja podaje jako minimum dwa rdzenie, 2 GB pamięci i 30 GB miejsca, na architekturze amd64 albo arm64. Producent zaleca zapas ponad to minimum, bo w tej samej pamięci mieszczą się procesy budowania. Przy poważniejszym użyciu sensownie jest oddzielić maszynę z panelem od maszyn z aplikacjami.

Czy Coolify zastąpi Vercela?

W zakresie wdrożeń z repozytorium, certyfikatów i środowisk podglądowych działa podobnie. Nie zastąpi natomiast sieci dostarczania treści, funkcji brzegowych ani obecności w wielu regionach naraz, bo aplikacja stoi na Twoim serwerze w jednej lokalizacji. Do rozłożenia treści geograficznie potrzebna jest dodatkowa warstwa.

Co się stanie, gdy zrezygnuję z subskrypcji chmury?

Chmura oparta jest o ten sam otwarty kod na licencji Apache 2.0, a aplikacje przez cały czas działają na Twoich serwerach. Możesz zainstalować panel u siebie i prowadzić dalej te same zasoby. Nie tracisz dostępu do narzędzia razem z subskrypcją.

Czy da się uruchomić Coolify na Raspberry Pi?

Tak, przy 64-bitowym Raspberry Pi OS. Architektura arm64 jest obsługiwana, a dokumentacja ma osobny przewodnik konfiguracji. Pamiętaj o minimalnych wymaganiach pamięci i o tym, że karta pamięci nie jest dobrym nośnikiem dla bazy danych działającej produkcyjnie.

Które porty muszę otworzyć?

Przy dostępie po adresie IP potrzebne są 8000 dla panelu, 6001 dla komunikacji w czasie rzeczywistym, 6002 dla terminala oraz 22, 80 i 443. Po podpięciu własnej domeny do panelu trzy pierwsze można zamknąć. Serwery podłączone do Coolify Cloud wymagają wyłącznie 22, 80 i 443.

Dokumentację znajdziesz na stronie Coolify, warunki wariantu zarządzanego na stronie cennika, a kod źródłowy w repozytorium na GitHubie.