Vercel jest wygodny do momentu, w którym projekt zaczyna wychodzić poza prosty schemat: jedna aplikacja, kilka zmiennych środowiskowych, deploy z Gita i spokój. Problem pojawia się przy kilku projektach naraz, własnej bazie danych, workerach, Redisie, dłużej działających procesach, przewidywalnym budżecie albo zwykłej chęci trzymania infrastruktury u siebie. Wtedy pojawia się pytanie: czy da się zachować wygodę deploymentu z GitHuba, ale nie płacić za każdy kolejny element osobno?
Coolify odpowiada właśnie na ten problem. To self-hosted PaaS, czyli panel do uruchamiania aplikacji, baz danych i usług na własnym serwerze. W praktyce dostajesz coś, co przypomina wygodę Vercela, Heroku albo Railway, ale działa na Twoim VPS-ie. Coolify wspiera między innymi aplikacje typu Next.js, Nuxt, Remix, SvelteKit, backendy, API, bazy danych, GitHub/GitLab/Bitbucket/Gitea, automatyczne certyfikaty Let’s Encrypt, backupy baz do storage’u zgodnego z S3 i deployment przez SSH na własne serwery.
To nie jest jednak tani Vercel „bez haczyków”. Haczyk jest duży i trzeba go nazwać od razu: serwer jest Twój, więc odpowiedzialność też jest Twoja. Coolify ułatwia deploy, SSL, logi, zmienne środowiskowe i bazy danych, ale nie zamienia VPS-a w managed hosting. Awaria dysku, brak backupu, zapchany Docker, nieudana aktualizacja systemu, brak miejsca na build — to nadal Twoje problemy.
Czym jest Coolify i komu może zastąpić Vercel, Heroku albo Railway?
Self-hosted PaaS to platforma aplikacyjna instalowana na Twojej infrastrukturze. Nie klikasz ręcznie docker run, nie piszesz od zera konfiguracji reverse proxy i nie odnawiasz certyfikatów SSL ręcznie. Zamiast tego logujesz się do panelu, podpinasz repozytorium, ustawiasz domenę, zmienne środowiskowe, port aplikacji i uruchamiasz deploy.
Coolify robi dokładnie to: zarządza aplikacjami jako kontenerami Dockera, pomaga budować projekty z repozytoriów Git, obsługuje domeny, SSL, logi, bazy danych i usługi pomocnicze. Oficjalne wymagania minimalne to 2 rdzenie CPU, 2 GB RAM i 30 GB wolnego miejsca, ale to minimum oznacza raczej „panel wstanie”, a nie „komfortowo zbudujesz kilka aplikacji Next.js i jeszcze uruchomisz PostgreSQL”. Dokumentacja Coolify sama ostrzega, że buildy mogą być zasobożerne, a przy budowaniu i uruchamianiu aplikacji na tym samym serwerze trzeba monitorować zasoby, rozważyć swap albo większy VPS.
Praktyczna granica wygląda tak:
- 2 vCPU / 4 GB RAM / 40 GB SSD — rozsądny start dla jednej lub dwóch małych aplikacji, panelu Coolify i prostego API.
- 4 vCPU / 8 GB RAM / 80 GB SSD — znacznie lepszy wybór, jeśli na tym samym VPS-ie ma działać Next.js, Node.js, PostgreSQL i Redis.
- 8 vCPU / 16 GB RAM i więcej — sensowne przy kilku projektach produkcyjnych, buildach w godzinach pracy, workerach, kolejkach i większych bazach.
- 1 vCPU / 1 GB RAM — nie. To proszenie się o problemy przy buildzie, aktualizacji, backupie albo większym ruchu.
Na dzień 19 czerwca 2026 r. najtańsze sensowne konfiguracje w Hetznerze nadal mieszczą się w widełkach „kilkadziesiąt złotych miesięcznie”, ale trzeba patrzeć na szczegóły. Po zmianie cennika od 15 czerwca 2026 r. przykładowy CX23 kosztuje 5,49 euro miesięcznie netto bez IPv4, a CX33 kosztuje 8,49 euro miesięcznie netto bez IPv4. Publiczny adres IPv4 w Hetznerze kosztuje dodatkowo 0,50 euro miesięcznie netto. Przy kursie NBP 1 EUR = 4,2604 PLN daje to około 25,5 zł netto miesięcznie za CX23 z IPv4 i około 38,3 zł netto miesięcznie za CX33 z IPv4. Do tego dochodzi VAT zgodnie z Twoim sposobem rozliczenia.
Dla porównania: Vercel ma plan Hobby za 0 dolarów, ale do użytku osobistego i niekomercyjnego, a plan Pro kosztuje 20 dolarów miesięcznie plus ewentualne dodatkowe użycie. Railway działa w modelu subskrypcji i zużycia: plan Hobby ma minimum 5 dolarów miesięcznie z kredytem w tej samej wysokości, a Pro minimum 20 dolarów miesięcznie z większymi limitami i dłuższą historią logów.
Najprościej ująć to tak:
| Opcja | Najlepsza, gdy | Koszt wejścia | Co dostajesz | Co nadal jest Twoim problemem |
|---|---|---|---|---|
| Vercel | Hostujesz głównie Next.js, zależy Ci na managed platformie, edge, preview deployments i minimalnej administracji | 0 USD dla Hobby, 20 USD/mies. Pro plus usage | Bardzo wygodny deploy, świetna integracja z Next.js, brak administracji serwerem | Koszty przy większym użyciu, limity planów, zależność od platformy |
| Railway | Chcesz szybko uruchamiać aplikacje, bazy i usługi bez zarządzania VPS-em | od 5 USD/mies. Hobby z rozliczeniem użycia | Wygodny panel, szybki deploy, mniej administracji niż VPS | Zużycie CPU/RAM/egress, limity planów, koszt rośnie z obciążeniem |
| Coolify na VPS | Chcesz wygody panelu, ale na własnym serwerze i z przewidywalnym kosztem bazowym | zwykle kilkadziesiąt zł netto/mies. za VPS | Deploy z Gita, SSL, aplikacje, bazy, logi, backupy w jednym panelu | Serwer, aktualizacje, backupy, monitoring, awarie VPS-a |
| Ręczny VPS | Lubisz pełną kontrolę i nie przeszkadza Ci ręczna administracja | najniższy koszt infrastruktury | Maksymalna elastyczność | Docker, proxy, SSL, deploy, logi, backupy i aktualizacje robisz sam |
Coolify ma największy sens dla osób, które mają już podstawowe obycie z VPS-em. Nie trzeba być administratorem Linuksa z dziesięcioletnim stażem, ale trzeba rozumieć, czym jest SSH, DNS, port 80/443, firewall, wolne miejsce na dysku i backup poza serwerem.
Najlepsze przypadki użycia:
- freelancer trzymający kilka małych aplikacji dla klientów;
- mały software house, który chce mieć staging, preview i proste projekty w jednym panelu;
- indie hacker z aplikacją Next.js, API, PostgreSQL i Redisem;
- developer, który wyrósł z ręcznego VPS-a, ale nie chce płacić za każdą usługę osobno;
- zespół techniczny, który akceptuje własną odpowiedzialność za infrastrukturę.
Kiedy nie wybierać Coolify? Gdy aplikacja jest krytyczna biznesowo, a nikt w zespole nie potrafi odtworzyć jej z backupu. Gdy potrzebujesz globalnej infrastruktury edge, wysokiego SLA, managed bazy danych i wsparcia po stronie dostawcy. Gdy każda godzina przestoju kosztuje więcej niż kilka miesięcy Vercela, Railway albo managed hostingu. Coolify obniża próg wejścia, ale nie usuwa odpowiedzialności.
Jak wygląda wdrożenie aplikacji z Gita na własny VPS?
Najbezpieczniej zacząć od świeżego VPS-a. Coolify też to rekomenduje, bo instalator zakłada kontrolę nad Dockerem, katalogami, kluczami SSH i usługami systemowymi. Automatyczny instalator działa dla Ubuntu LTS 20.04, 22.04 i 24.04, a proces wymaga między innymi SSH, użytkownika root, firewalla i curl. Instalator instaluje potrzebne narzędzia, Dockera w wersji 24 lub nowszej, tworzy katalogi, klucze SSH i uruchamia Coolify. Docker zainstalowany przez Snap nie jest wspierany.
Podstawowa instalacja wygląda tak:
curl -fsSL https://cdn.coollabs.io/coolify/install.sh | sudo bashPo instalacji panel jest dostępny pod adresem:
http://ADRES_IP_SERWERA:8000Pierwszą rzecz trzeba zrobić od razu: utworzyć konto administratora. Coolify ostrzega, że jeśli panel po świeżej instalacji zostanie publicznie dostępny bez założonego admina, ktoś inny może przejąć inicjalną konfigurację. To nie jest teoretyczny problem — port 8000 widoczny w internecie prędzej czy później zostanie przeskanowany.
Praktyczna kolejność po instalacji:
- Utwórz konto administratora w panelu.
- Podłącz domenę panelu, na przykład
coolify.twojadomena.pl. - Ustaw rekord DNS A na adres IP serwera.
- Otwórz porty 80 i 443 na firewallu.
- Włącz HTTPS dla domeny panelu.
- Skonfiguruj powiadomienia o błędach deploymentu, backupach i serwerze.
- Dopiero potem przenoś aplikacje produkcyjne.
Domeny w Coolify działają prosto, ale nie wybaczają złego DNS-u. Dla aplikacji ustawiasz pełny adres, na przykład:
https://app.twojadomena.plJeśli domena zaczyna się od https://, Coolify automatycznie konfiguruje proxy i certyfikat Let’s Encrypt. Certyfikaty są odnawiane automatycznie, ale tylko wtedy, gdy DNS prowadzi na właściwy serwer, porty są dostępne, a po drodze nie przeszkadza źle skonfigurowany proxy, na przykład Cloudflare. Dla challenge HTTP potrzebny jest port 80, a dla TLS-ALPN port 443. Jeżeli ustawisz rekord AAAA dla IPv6, a serwer albo proxy nie obsługuje go poprawnie, certyfikat też może się wysypać.
Deployment z GitHuba można zrobić na kilka sposobów. Dla publicznego repozytorium wystarczy adres repo. Dla prywatnego najwygodniejsza jest GitHub App, bo pozwala nadać dostęp tylko do wybranych repozytoriów. Coolify obsługuje automatyczne deploymenty przez GitHub App, GitHub Actions i webhooki. Przy GitHub App auto deploy jest domyślnie włączony, więc push na odpowiednią gałąź może od razu uruchomić build.
Typowy deploy aplikacji Next.js wygląda tak:
- W panelu wybierasz New Resource.
- Wybierasz źródło: GitHub App albo publiczny URL repozytorium.
- Wskazujesz serwer, na którym aplikacja ma działać.
- Wybierasz repozytorium i branch.
- Zostawiasz domyślny buildpack, jeśli projekt jest typowy.
- Ustawiasz port aplikacji, najczęściej 3000 dla aplikacji Node/Next.
- Dodajesz domenę, na przykład
https://app.twojadomena.pl. - Wklejasz zmienne środowiskowe.
- Klikasz Deploy i sprawdzasz logi buildu oraz logi runtime.
Coolify uruchamia aplikacje jako kontenery Docker. Przy buildach może używać między innymi Nixpacks, które rozpoznaje projekt po plikach lockfile i dobiera komendy dla npm, Yarn albo pnpm. Jeśli projekt ma nietypową strukturę, monorepo, własny Dockerfile albo wymaga dodatkowych pakietów systemowych, lepiej nie walczyć z autodetekcją. Wtedy ustawiasz własny Dockerfile albo Docker Compose i masz pełną kontrolę nad buildem.
Najczęstsze potknięcia przy Next.js na VPS-ie:
- aplikacja nasłuchuje na złym porcie;
- proces słucha tylko na
localhost, a powinien być dostępny w kontenerze; - brakuje zmiennych środowiskowych podczas buildu;
NEXT_PUBLIC_*zostało zmienione po buildzie i nie działa tak, jak oczekiwano;- build zjada za dużo RAM-u na małym VPS-ie;
- cache, uploady albo pliki generowane lokalnie znikają po przebudowaniu kontenera;
- aplikacja wymaga funkcji specyficznych dla Vercela, których nie ma w prostym kontenerze Node.js.
Zmienne środowiskowe w Coolify można edytować w widoku formularza albo wkleić hurtem w formacie .env. To wygodne przy migracji z Vercela albo Railway, ale trzeba od razu rozdzielić dwie rzeczy: zmienne potrzebne w czasie buildu i zmienne potrzebne w czasie działania aplikacji. Coolify obsługuje oba tryby, a domyślnie zmienne mogą być dostępne zarówno podczas buildu, jak i runtime.
Dla Next.js ma to praktyczne znaczenie. Zmienna NEXT_PUBLIC_API_URL zwykle zostanie „wypalona” w bundle’u frontendu podczas buildu. Zmienna DATABASE_URL może być potrzebna przy migracjach, buildzie albo runtime — zależnie od frameworka, ORM-a i sposobu startu aplikacji. Sekretów produkcyjnych nie trzyma się w repozytorium. Wkleja się je w panelu albo definiuje jako zmienne współdzielone na poziomie projektu czy środowiska.
Logi są pierwszym miejscem, do którego zaglądasz po nieudanym deployu. Build logs pokażą problemy z zależnościami, Node’em, lockfile’em, pamięcią albo błędami kompilacji. Runtime logs pokażą, czy aplikacja wstała, czy połączyła się z bazą, czy nie wywaliła się na migracjach. Coolify obsługuje też log drains do narzędzi zewnętrznych, między innymi Axiom i New Relic, a monitoring obejmuje między innymi użycie dysku, status kontenerów i backupy. Powiadomienia można wysyłać przez e-mail, Telegram, Discord, Slack/Mattermost, Pushover albo webhooki.
Aktualizacje są miejscem, w którym kończy się bajka o „własnym Vercelu”. Coolify w instalacji self-hosted może sprawdzać aktualizacje i wykonywać auto update, ale dla produkcji rozsądniej jest wyłączyć automatyczne aktualizacje panelu i robić je świadomie: backup, aktualizacja, kontrola usług. Coolify nie instaluje automatycznie paczek systemowych na serwerze — potrafi sprawdzać i pokazywać dostępne aktualizacje, a samo patchowanie systemu wykonujesz z panelu albo ręcznie. Aktualizacja Dockera oznacza restart Dockera, a więc chwilową niedostępność aplikacji i samego Coolify.
Tu jest dobra zasada operacyjna: najpierw staging, potem produkcja. Najpierw przenieś prostą aplikację bez bazy. Potem API. Dopiero na końcu bazę danych. Jeżeli nie umiesz odtworzyć aplikacji z backupu na nowym VPS-ie, to nie masz jeszcze gotowej infrastruktury produkcyjnej — masz tylko działający serwer.
Next.js, Node.js, PostgreSQL i Redis w jednym panelu
Największa zaleta Coolify wychodzi wtedy, gdy aplikacja nie kończy się na frontendzie. Panel pozwala trzymać w jednym miejscu aplikację Next.js, backend Node.js, bazę PostgreSQL, cache lub kolejkę w Redisie, domeny, zmienne środowiskowe, logi i backupy. Dla małych projektów to ogromna różnica względem ręcznego VPS-a, gdzie każdy z tych elementów wymaga osobnej konfiguracji.
Ale „w jednym panelu” nie znaczy „w bezpiecznym klastrze”. Jeśli wszystko działa na jednym VPS-ie, to awaria tego VPS-a zatrzymuje wszystko: aplikację, API, bazę, Redis, panel i logi lokalne. To jest akceptowalne dla wielu małych projektów, stagingów, narzędzi wewnętrznych i aplikacji o umiarkowanym ryzyku. Nie jest akceptowalne dla systemu, który ma zarabiać pieniądze 24/7 bez planu awaryjnego.
Przy PostgreSQL najważniejsze są trzy decyzje:
- baza powinna być dostępna prywatnie dla aplikacji, a nie wystawiona publicznie do internetu;
DATABASE_URLpowinien trafić do zmiennych środowiskowych aplikacji, nie do repozytorium;- backup musi trafiać poza VPS, a nie tylko na ten sam dysk.
Coolify obsługuje zaplanowane backupy baz, między innymi PostgreSQL. Harmonogram ustawia się wyrażeniami cron, a backup PostgreSQL opiera się o pg_dump; przywracanie odbywa się przez pg_restore. Backupy można wysyłać do storage’u zgodnego z S3, na przykład AWS S3, DigitalOcean Spaces, MinIO, Cloudflare R2, Backblaze B2, Scaleway, Hetzner S3, Wasabi albo Vultr.
Tu łatwo popełnić groźny błąd: backup instancji Coolify to nie to samo co backup danych aplikacji. Backup panelu pomaga odtworzyć konfigurację Coolify, ale nie załatwia automatycznie backupu wolumenów, uploadów, baz danych i danych aplikacyjnych. Dokumentacja Coolify mówi to wprost: dane aplikacji i wolumeny trzeba backupować osobno. Do odtworzenia instancji potrzebny jest też między innymi APP_KEY, więc tego pliku nie traktuje się jak nieistotnego szczegółu.
Minimalny zestaw dla małej produkcji powinien wyglądać tak:
- codzienny backup PostgreSQL do storage’u poza VPS-em;
- test odtworzenia backupu na osobnym środowisku;
- snapshot VPS-a przed większymi aktualizacjami;
- monitoring wolnego miejsca na dysku;
- powiadomienia o błędach backupu i deploymentu;
- spis zmiennych środowiskowych potrzebnych do odtworzenia aplikacji;
- procedura migracji na nowy VPS, nawet jeśli ma tylko kilka kroków.
Redis wymaga osobnej decyzji. Jeśli służy wyłącznie jako cache, jego utrata boli, ale zwykle nie niszczy danych. Jeśli trzymasz w nim sesje, kolejki, limity, joby albo dane, których nie da się łatwo odtworzyć, traktuj go jak element wymagający planu trwałości i odtwarzania. Nie wrzucaj do Redisa „na chwilę” rzeczy, których utrata oznacza ręczne sprzątanie produkcji.
W przypadku Next.js trzeba też sprawdzić, czy aplikacja faktycznie dobrze pasuje do klasycznego kontenera Node.js. Prosty SSR, API routes, Prisma, PostgreSQL i Redis — to zwykle działa dobrze. Gorzej, jeśli projekt mocno opiera się na funkcjach platformowych Vercela: edge functions, specyficznych cronach, storage’u, image optimization skonfigurowanym pod Vercel, serverlessowym modelu wykonywania albo integracjach marketplace. Da się część z tego zastąpić, ale to już migracja architektury, nie tylko zmiana hostingu.
Ręczny VPS daje większą kontrolę, ale Coolify usuwa dużo żmudnej pracy. Nie musisz za każdym razem pisać konfiguracji reverse proxy, pilnować certyfikatów, ręcznie tworzyć deployment scripts i sklejać logów z kilku usług. Nadal jednak musisz pilnować rzeczy, których panel za Ciebie nie rozwiąże:
- miejsce na dysku — Docker image, cache buildu, logi i backupy potrafią zjeść dysk szybciej niż aplikacja;
- aktualizacje systemu — podatności nie znikają dlatego, że aplikacja działa w kontenerze;
- odtwarzanie po awarii — backup bez testu restore jest tylko nadzieją;
- obciążenie buildem — mały VPS może paść nie od ruchu użytkowników, ale od
npm run build; - jedno miejsce awarii — jeden VPS to jeden punkt, którego awaria zatrzymuje cały stack;
- poczta wychodząca — wysyłkę maili lepiej oprzeć o zewnętrzny SMTP/API, a nie liczyć na reputację świeżego VPS-a.
Najrozsądniejsza ścieżka migracji jest prosta. Najpierw uruchom Coolify na VPS-ie z co najmniej 2 vCPU i 4 GB RAM. Potem przenieś jedną aplikację bez krytycznych danych. Sprawdź deploy z GitHuba, domenę, SSL, logi, restart kontenera i aktualizację panelu. Następnie dodaj PostgreSQL, ustaw backup do zewnętrznego storage’u i wykonaj test przywrócenia. Dopiero po tym przenoś produkcyjną bazę.
Jeżeli celem jest tylko zaoszczędzenie kilku dolarów na jednej aplikacji Next.js, Coolify może być przesadą. Jeżeli masz kilka aplikacji, bazę, Redis, staging, preview, worker i chcesz przewidywalnego kosztu na własnym serwerze — wtedy Coolify zaczyna mieć bardzo dużo sensu. Nie jako magiczny hosting bez obowiązków, tylko jako porządny panel operacyjny dla własnego VPS-a.
FAQ: najczęstsze pytania o Coolify na VPS
Czy Coolify zastępuje Vercel w 100%?
Nie. Zastępuje część wygody: deploy z Gita, domeny, SSL, logi, zmienne środowiskowe i uruchamianie aplikacji. Nie zastępuje infrastruktury edge Vercela, managed SLA ani odpowiedzialności za serwer.
Czy Coolify jest managed hostingiem?
Nie. Coolify self-hosted działa na Twoim VPS-ie. Ty odpowiadasz za system, aktualizacje, backupy, monitoring, odtwarzanie po awarii i koszty serwera.
Jaki VPS wybrać na start?
Dla testów i małej aplikacji: 2 vCPU, 4 GB RAM, 40 GB SSD. Dla Next.js, Node.js, PostgreSQL i Redis na jednym serwerze: lepiej zacząć od 4 vCPU, 8 GB RAM i 80 GB SSD.
Czy 2 GB RAM wystarczy?
Oficjalnie to minimum, ale praktycznie szybko robi się ciasno. Build Next.js, PostgreSQL i Redis na tej samej maszynie potrafią zjeść zasoby w złym momencie.
Czy SSL w Coolify działa automatycznie?
Tak, jeśli domena wskazuje na serwer, porty 80 i 443 są otwarte, a konfiguracja DNS/proxy nie blokuje Let’s Encrypt. Samo wpisanie domeny w panelu nie naprawi złego DNS-u.
Czy można wdrażać prywatne repozytoria z GitHuba?
Tak. Najwygodniej przez GitHub App, bo można ograniczyć dostęp tylko do wybranych repozytoriów i korzystać z automatycznych deploymentów po pushu.
Czy PostgreSQL w Coolify nadaje się na produkcję?
Tak, dla małych i średnich projektów, pod warunkiem że masz backup poza VPS-em, monitoring dysku i przetestowane odtwarzanie. Dla krytycznych systemów lepsza może być managed baza danych.
Czy backup Coolify wystarczy?
Nie. Backup instancji Coolify nie zastępuje backupu danych aplikacji, baz, uploadów i wolumenów. Trzeba backupować je osobno.
Co się stanie, gdy VPS padnie?
Aplikacja przestanie działać. Jeśli wszystko było na jednym VPS-ie, padnie też baza, Redis i panel. Odtwarzasz środowisko z backupów albo snapshotów. To Twoja odpowiedzialność.
Od czego zacząć bezpiecznie?
Od jednej niekrytycznej aplikacji. Najpierw sprawdź deploy, domenę, SSL, logi i restart. Potem ustaw backup PostgreSQL do zewnętrznego storage’u i wykonaj test restore. Produkcję przenoś dopiero po tym kroku.
