Coolify na własnym serwerze VPS zastąpił mi Railway w niecałą dobę. Przeniosłem cztery aplikacje: QuizBase z bazą ponad 1,2 mln pytań, RoundKit, platformę do gier szkoleniowych i jedno narzędzie wewnętrzne. Najdłuższa przerwa dla użytkowników trwała 1 minutę i 40 sekund, rachunek spadł mniej więcej o połowę, a po dniu poprawek QuizBase odpowiada szybciej niż na Railway i bez błędów przyjmuje 400 zapytań na sekundę. Opisuję, jak to zrobiłem, ile to kosztuje, na czym się potknąłem i dlaczego dobry VPS w 2026 roku trudno w ogóle kupić.
Dlaczego się wyprowadziłem, opisałem osobno w tekście o tym, jak Railway traci zaufanie klientów. Tu zajmuję się samą przeprowadzką.
Kto to właściwie zrobił?
Nie jestem programistą, więc uczciwie: migrację zrobiłem z pomocą Claude Code. To nie wyglądało tak, że narzędzie samo podejmowało decyzje i wszystko robiło. Podział był taki:
- Ja: wybór dostawcy i warunków, zamówienie i płatność, akceptacja planu, kolejność aplikacji, zgoda na każde przełączenie, decyzje przy każdym rozwidleniu i kilka kliknięć tam, gdzie dostawca nie ma API.
- Claude Code: research ofert, zabezpieczenie serwera, instalacja i konfiguracja Coolify przez API, przenoszenie baz, przełączanie domen przez API Cloudflare, sprawdzanie wyniku po każdym kroku i zapis wszystkiego w dokumentacji.
Całość zajęła kilkanaście godzin mojego czasu na cztery projekty. Bez agenta nie zabrałbym się za to w ogóle. Więcej o tym, jak z nim pracuję, piszę w tekście Claude Code od zera.
Dlaczego w 2026 roku tak trudno kupić dobry VPS?
Bo brakuje pamięci RAM. Zapotrzebowanie centrów danych AI wywindowało ceny pamięci i dysków, a dostawcy serwerów przenoszą to na klientów. Hetzner, symbol taniego hostingu w Europie, w 2026 roku kilka razy podnosił ceny i ogranicza zakładanie nowych serwerów w chmurze, powołując się na ograniczoną dostępność komponentów. Podobnie dzieje się u innych dostawców.
Moje warunki były proste: maszyna od ręki, rozliczana miesięcznie, bez długiej umowy i bez przedpłaty, z 32 GB RAM, bo sama baza QuizBase potrzebuje kilku gigabajtów. Okazało się, że to dużo. Oto co sprawdziłem 9 listopada 2026 (ceny netto za miesiąc):
| Oferta | Parametry | Cena | Dlaczego odpadła |
|---|---|---|---|
| Hetzner Cloud CX43 | 8 rdzeni / 16 GB | ok. 20 € | Blokada nowych serwerów |
| OVH VPS-4 | 8 rdzeni / 24 GB | 20-23,5 € | Niedostępne |
| netcup VPS 4000 | 12 rdzeni / 32 GB | ok. 44 € | Zamówienia online nie dało się złożyć z moim nazwiskiem i numerem VAT, wirtualny asystent odsyłał do maili z działem obsługi |
| Hostinger KVM 8 | 8 rdzeni / 32 GB | 93,99 zł, potem 213,99 zł | Tylko z przedpłatą za 24 miesiące |
| Scaleway Elastic Metal | 6 rdzeni / 32 GB, serwer dedykowany | 40 € + 40 € na start | Serwer dedykowany bez migawek, opłata startowa |
| OVH Eco (serwery dedykowane) | 6 rdzeni / 32 GB | 226-294 zł | Drożej, opłata startowa |
| AWS Lightsail / EC2 | 4 rdzenie / 16 GB | ok. 87-90 $ | Za drogo przy połowie pamięci |
| Google Cloud | 4 rdzenie / 16 GB | ok. 89-98 $ | Za drogo, z rocznym zobowiązaniem |
| Wybrany VPS | 16 rdzeni / 32 GB / 320 GB | poniżej 200 zł | Od ręki, bez umowy, polska faktura |
Dostawcy nie podaję. Wybrałem go pragmatycznie, nie z miłości, a nie chcę, żeby ten tekst był reklamą. Ważniejszy jest wniosek: tanie oferty z rankingów często istnieją tylko na papierze. Licz się z tym, że pierwsza i druga opcja będą niedostępne, i sprawdzaj dostępność, zanim zaplanujesz przeprowadzkę.
Dlaczego Coolify, a nie inna platforma?
Najpierw sprawdziłem, czy nie wystarczy przenieść się na inną platformę tego typu, na przykład Render, Fly albo Northflank. Nie wystarczy. Większość rachunku stanowi pamięć bazy danych, a za nią wszędzie płaci się podobnie albo drożej.
Coolify to darmowy panel open source, który instalujesz na własnym serwerze. Daje to, co lubiłem w Railway: wysyłasz kod do repozytorium, a panel sam buduje i uruchamia aplikację. Do tego bazy danych, kopie zapasowe, zadania cykliczne i powiadomienia. Działa na każdym serwerze z Ubuntu i Dockerem i zjada około 1-1,5 GB pamięci.
Dla mnie przesądziło jeszcze jedno: Coolify ma pełne API. Nie znoszę klikania po panelach, a dzięki API całą konfigurację zrobiliśmy z Claude Code, bez otwierania przeglądarki. Każde narzędzie oceniam właśnie tak: czy da się nim sterować bez klikania.
Coolify a Railway - co jest gorsze, a co lepsze?
| Railway | Coolify na VPS | |
|---|---|---|
| Wdrażanie | Wysyłasz kod i gotowe | Też, po jednorazowej konfiguracji |
| Rachunek | Za zużycie, rośnie z pamięcią | Stały, niezależny od obciążenia |
| Zapas mocy | Każdy GB pamięci kosztuje | 16 rdzeni i 32 GB do dyspozycji |
| Bezpieczeństwo i aktualizacje | Robi platforma | Robisz Ty |
| Kopie zapasowe | Częściowo platforma | Robisz Ty, w tym próbne odtworzenie |
| Strojenie bazy | Częściowo platforma | Pełna kontrola, pełna odpowiedzialność |
| Awaria sprzętu | Problem platformy | Problem dostawcy VPS i Twój plan odtworzenia |
Gorsze jest jedno, ale zasadnicze: jesteś administratorem. Railway częściowo zarządzał bazą, aktualizacjami i bezpieczeństwem za mnie. Teraz to moja robota. Dlatego zanim przeniosłem pierwszą aplikację, serwer dostał logowanie wyłącznie kluczem, automatyczne łatki bezpieczeństwa, blokadę prób włamania i zaporę, która wpuszcza ruch na stronę tylko z Cloudflare. Coolify sam pilnuje aktualizacji, wysyła maila przy nieudanym wdrożeniu albo kopii i zbiera metryki.
Lepsze jest wszystko, co dotyczy kontroli i pieniędzy. Restart bazy po zmianie konfiguracji przerywa działanie na trzy sekundy. Bazie mogłem dać 10 GB pamięci zamiast 6 i nie kosztowało mnie to ani złotówki więcej.
Jak wyglądała przeprowadzka krok po kroku?
Kluczowa decyzja zapadła dużo wcześniej: domeny, DNS i cały ruch szły przez Cloudflare, a nie przez Railway. Dzięki temu przełączenie aplikacji to zmiana jednego rekordu DNS, działa od razu, a cofnięcie zajmuje sekundy. Piszę o tym więcej przy kosztach własnego API.
Kolejne kroki:
- Serwer i zabezpieczenia - wszystko opisane wyżej, zanim pojawiła się jakakolwiek aplikacja.
- Kopie zapasowe od pierwszego dnia - bazy i pliki co noc poza serwer, do zewnętrznego magazynu. Jedną kopię od razu odtworzyliśmy na próbę i porównaliśmy liczby rekordów. Kopia, której nikt nie odtworzył, jest tylko nadzieją.
- Kolejność od najmniej ryzykownej - najpierw narzędzie wewnętrzne, którego nikt nie używa, jako próba całej ścieżki. Potem gra szkoleniowa, RoundKit, a na końcu QuizBase z największą bazą.
- Każda aplikacja najpierw obok - nowa wersja uruchomiona na serwerze, a stara dalej działa na Railway. Test przez tymczasowy adres w Cloudflare, na przykład
app-test, z porównaniem odpowiedzi ze starą wersją, trasa po trasie. - Przełączenie w spokojnym momencie - grę przełączyliśmy, gdy nie trwało żadne szkolenie, a QuizBase w nocy.
| Aplikacja | Co przenosiliśmy | Przerwa dla użytkowników |
|---|---|---|
| Narzędzie wewnętrzne | Baza, 2,1 GB plików | Brak (nikt nie używał) |
| Gra szkoleniowa | Aplikacja, baza plikowa, gry | Praktycznie brak |
| RoundKit | Aplikacja (baza zostaje u zewnętrznego dostawcy) | Brak |
| QuizBase | Ponad 1,2 mln pytań, ok. 10 GB bazy, cache, cztery zadania cykliczne | 1 min 40 s |
Przy QuizBase pomógł jeden trik. Duże tabele z pytaniami prawie się nie zmieniają, więc przenieśliśmy je wcześniej, w ramach próby generalnej. W momencie przełączenia trzeba było skopiować tylko tabele, które zmieniają się na bieżąco, czyli konta, klucze i statystyki. To zajęło 56 sekund, a potem liczby rekordów we wszystkich 47 tabelach zgadzały się co do jednego.
Na czym się potknęliśmy?
Gładko nie znaczy bezbłędnie. Lista pułapek, które warto znać przed własną przeprowadzką:
- Sprawdzanie zdrowia aplikacji wymaga narzędzia w obrazie. Coolify sprawdza aplikację poleceniem, którego odchudzone obrazy nie mają. Wdrożenie się cofało, choć aplikacja działała.
- Railway budował inaczej niż plik w repozytorium. Railway składał obraz po swojemu, a plik budowania w repo był nieaktualny i brakowało w nim przeglądarki do generowania PDF-ów. Wyszło dopiero na teście.
- Prawdziwy adres IP użytkownika za Cloudflare. Między użytkownikiem a aplikacją są teraz dwa pośredniki zamiast jednego. Bez poprawki ograniczenia liczby zapytań liczyłyby wszystkich jako jednego klienta.
- Cloudflare po przełączeniu jeszcze chwilę pamięta stary adres. Test uruchomiony od razu dostał błąd ze starego serwera, a po kilkunastu sekundach wszystko było zielone. Nie panikuj w pierwszej minucie.
- Przeprowadzka odkrywa stare grzechy. Narzędzie wewnętrzne okazało się mieć wersję PHP z krytyczną luką, więc od razu je zatrzymaliśmy. Na Railway działało z nią publicznie od tygodni.
Ile to kosztuje i jak działa po przeprowadzce?
Koszt: na Railway płaciłem według cennika około 75-90 dolarów miesięcznie, z czego prawie wszystko to pamięć bazy QuizBase. Serwer kosztuje mnie poniżej 200 zł netto miesięcznie, czyli mniej więcej połowę. Zaraz po przeniesieniu wszystkich aplikacji zajętych było 4 z 31 GB pamięci, więc jest miejsce na kolejne produkty bez dopłaty.
Wydajność: tu muszę być uczciwy. Pierwszy pomiar rano po przeprowadzce wypadł gorzej niż na Railway: przy 50 zapytaniach na sekundę 95% odpowiedzi na głównych trasach przychodziło w 235-342 ms, a na Railway w około 100 ms. Przy 100 zapytaniach na sekundę test trzeba było przerwać, bo odpowiedzi szły po 4-16 sekund, a sufit wynosił około 51 zapytań na sekundę.
Diagnoza z tego samego poranka brzmiała: problem siedzi w programie, nie w sprzęcie. Potwierdziła się. Trzy zmiany dały prawie cały zysk:
- Pamięć podręczna dla list kategorii. Ponad połowa pracy procesora (55%) szła na wielokrotne przetwarzanie tych samych dużych list.
- Gotowa pula do losowania pytań. Losowanie przez sortowanie zajmowało 94% czasu bazy pod ruchem.
- Cztery procesy aplikacji zamiast jednego. Mniej więcej czterokrotny zapas, a proces, który padnie, wraca sam w około sekundę.
Wynik po poprawkach:
| Pomiar | Railway (05.2026) | Serwer rano po przeprowadzce | Serwer po poprawkach |
|---|---|---|---|
| 95% odpowiedzi przy 50 zapytaniach/s, główne trasy | ok. 100 ms | 235-342 ms | 61-65 ms |
| To samo dla losowania pytań | 571 ms | 900 ms | 119 ms |
| 100 zapytań/s | nie mierzony | przerwany, 4-16 s | bez błędów, 111-168 ms |
| 200 zapytań/s | nie mierzony | sufit ok. 51 zapytań/s | bez błędów, 62-112 ms |
| 400 zapytań/s | nie mierzony | - | bez błędów, 63-115 ms |
| Restart bazy | - | szacowany ok. 1 min | 3 s |
Z każdego czasu około 50 ms to sama droga z mojego laptopa przez Cloudflare do serwera, więc aplikacja odpowiada jeszcze szybciej, niż widać w tabeli. Przy 400 zapytaniach na sekundę cztery procesy są prawie w pełni zajęte, ale cały serwer pracuje mniej więcej w jednej czwartej. Kolejny zapas to zmiana jednej liczby w panelu, bez pisania kodu.
Uczciwie trzeba dodać, że te poprawki pomogłyby też na Railway. Różnica polega na tym, że na serwerze dodatkowa pamięć dla bazy i kolejne procesy nic nie kosztują, a na Railway każdy gigabajt podnosiłby rachunek. To też praca, którą Railway częściowo robił za mnie. Teraz robię ją sam, ale z wynikiem lepszym i tańszym.
Czy to droga dla każdego?
Nie. Jeśli masz jedną małą aplikację i nie chcesz myśleć o serwerze, platforma typu Railway czy Render nadal ma sens. Jeśli nikt w zespole nie zajmie się aktualizacjami, kopiami i bezpieczeństwem, własny serwer szybko stanie się większym ryzykiem niż awarie platformy.
Własny serwer wygrywa, gdy masz kilka aplikacji i bazę, która potrzebuje kilku gigabajtów pamięci. Wtedy stała cena zaczyna bić rozliczenie za zużycie, a pełna kontrola przestaje być luksusem. Bariera wejścia, czyli wiedza administratora, mocno spadła, odkąd pracuję z agentem AI. Nie zastąpił mojego osądu, ale wykonał całą techniczną robotę i sprawdzał ją po każdym kroku. Czy to narzędzie dla Ciebie, piszę w tekście Claude Code - czy warto?.
Jeśli zastanawiasz się, czy przenieść produkty z platformy na własny serwer, albo chcesz nauczyć zespół pracy z agentem AI przy takich zadaniach, porozmawiajmy na konsultacjach albo przy szkoleniu dla firm.