Problem z hostingiem Next.js rzadko polega na tym, że „nie ma gdzie wrzucić projektu”. Opcji jest aż za dużo. Prawdziwy problem zaczyna się wtedy, gdy trzeba zdecydować, czy aplikacja ma być statyczna, renderowana po stronie serwera, podpięta pod bazę danych, tania w utrzymaniu, łatwa do oddania klientowi albo przewidywalna kosztowo po wzroście ruchu.
Next.js potrafi działać jako statyczny eksport, aplikacja SSR, aplikacja z API routes, route handlers, server actions, ISR, obrazkami optymalizowanymi w locie i middleware. To nie są szczegóły techniczne dla geeków. To są rzeczy, które przesądzają, czy wystarczy Cloudflare Pages, czy lepiej wejść w Vercel, czy taniej i rozsądniej będzie postawić VPS pod Next.js z Coolify.
Najkrótsza zasada: dla prostego frontendu wybieraj platformę frontendową, dla pełnej aplikacji wybieraj środowisko, które naprawdę obsługuje jej tryb działania. Klasyczny hosting WWW ma sens tylko wtedy, gdy Next.js kończy jako statyczne pliki HTML/CSS/JS. Przy SSR, API, ISR i runtime Node.js przestaje być „hostingiem Next.js”, a zaczyna być półśrodkiem.
Vercel, Netlify i Cloudflare — najprostsze opcje dla frontendu
Vercel jest najwygodniejszym wyborem, gdy projekt korzysta z typowych funkcji Next.js i ma szybko trafić na produkcję. Import repozytorium, preview deploymenty, automatyczna konfiguracja, SSR przez Vercel Functions, ISR, cache i optymalizacja obrazów działają bez walki z infrastrukturą. Vercel wprost opisuje Next.js jako framework utrzymywany przez siebie, a wdrożenie na Vercel jako zero-configuration z dodatkami dotyczącymi skalowania, dostępności i globalnej wydajności.
Tę wygodę trzeba jednak kupować świadomie. Plan Hobby jest darmowy, ale przeznaczony do użytku osobistego i niekomercyjnego. Plan Pro kosztuje 20 USD miesięcznie + dodatkowe użycie, ma 20 USD wliczonego kredytu użycia, a Vercel rozlicza między innymi transfer, edge requests i funkcje. W tabeli limitów Vercel pokazuje m.in. 100 GB Fast Data Transfer miesięcznie w Hobby, 1 TB miesięcznie w Pro, a potem stawkę od 0,15 USD za GB; edge requests to 1 mln miesięcznie w Hobby i 10 mln miesięcznie w Pro, potem od 0,000002 USD za request.
To oznacza prostą decyzję: Vercel jest świetny dla SaaS-a, panelu, sklepu, aplikacji SSR, MVP i projektu klienta, który ma działać szybko i bez ręcznej administracji. Nie jest najlepszym wyborem, gdy głównym kryterium jest tani hosting Next.js przy dużym transferze, wielu obrazach, botach albo trudnym do przewidzenia ruchu. W takim projekcie pierwszą czynnością po deployu powinno być ustawienie budżetu i alertów, bo Vercel ma model usage-based. Nowe zespoły mają domyślny budżet on-demand 200 USD, który można zmienić, a po dojściu do 100% można skonfigurować twarde zatrzymanie projektów.
Netlify jest bliżej Vercela, niż wiele osób pamięta z czasów prostego Jamstacka. Dziś Netlify deklaruje pełne wsparcie dla głównych funkcji Next.js przez OpenNext adapter: App Router, SSR, ISR, SSG, Server Actions, middleware, route handlers, image optimization, redirects, rewrites i internationalization. Adapter tworzy funkcje serverless dla SSR/ISR/API/Server Actions, edge function dla middleware i obsługuje cache oraz rewalidację.
Cennik Netlify jest obecnie oparty na kredytach. Free ma 300 credits/mies., Personal kosztuje 9 USD/mies. i ma 1000 credits/mies., Pro kosztuje 20 USD/mies. z nielimitowaną liczbą członków i ma 3000 credits/mies., a Enterprise startuje od 500 USD/mies. Produkcyjny deploy kosztuje 15 credits, compute 10 credits za GB-hour, bandwidth 20 credits za GB, a web requests 2 credits za 10 tys. requestów.
W praktyce Netlify wybierałbym tam, gdzie zespół mocno korzysta z preview deployów, prostych integracji, statycznych stron, formularzy, edge funkcji i chce alternatywy dla Vercela bez przechodzenia od razu na VPS. Dla klasycznej strony firmowej albo bloga Netlify jest bardzo wygodny. Dla aplikacji z ciężkim SSR trzeba już policzyć kredyty, bo koszt nie bierze się z samego „planu Pro”, tylko z produkcyjnych deployów, compute, transferu i requestów.
Cloudflare trzeba rozdzielić na dwie opcje: Cloudflare Pages i Cloudflare Workers. Pages jest świetne dla statycznych frontendów, landing page’y, blogów, dokumentacji, stron marketingowych i prostych aplikacji, które po buildzie są zestawem plików. W darmowym planie Pages ma 500 buildów miesięcznie, 1 build jednocześnie, timeout buildu 20 minut, limit 20 tys. plików na site i 100 custom domains na projekt. Na planie Pro limity buildów rosną do 5000 miesięcznie i 5 concurrent builds, a na Business do 20 tys. buildów miesięcznie i 20 concurrent builds.
Dla pełnego Next.js Cloudflare kieruje dziś w stronę Workers. Dokumentacja Cloudflare mówi wprost: pełną aplikację SSR Next.js należy wdrażać przez Next.js Workers guide, a statyczny Next.js na Pages wybierać tylko dla statycznego eksportu. Cloudflare Workers obsługuje Next.js przez adapter OpenNext; wspierane są m.in. App Router, Pages Router, route handlers, React Server Components, SSG, SSR, ISR, Server Actions, streaming, middleware i image optimization przez Cloudflare Images. Ograniczenie: Node.js in Middleware nie jest jeszcze wspierany.
Kosztowo Cloudflare bywa bardzo atrakcyjny. Workers Free daje 100 tys. requestów dziennie, a Workers Paid kosztuje minimum 5 USD miesięcznie i obejmuje 10 mln requestów miesięcznie, potem 0,30 USD za każdy dodatkowy milion requestów. W modelu Standard wliczone jest też 30 mln CPU milliseconds miesięcznie, potem 0,02 USD za dodatkowy milion CPU ms. Cloudflare nie dolicza osobnych opłat za egress ani bandwidth w Workers, a requesty do static assets są darmowe i nielimitowane.
Cloudflare jest bardzo mocną Vercel alternatywą, ale nie traktowałbym go jako zamiennika „kliknij i zapomnij” dla każdego projektu. Dla statycznych stron — tak. Dla aplikacji SSR — tak, jeśli zespół akceptuje runtime Workers, adapter, testowanie w workerd, konfigurację zmiennych i ograniczenia kompatybilności. Cloudflare sam podkreśla, że next dev działa lokalnie w Node.js, a preview powinno być uruchamiane w runtime Workers przez wrangler dev, bo to bliżej produkcji.
Hosting z Node.js jest osobną kategorią. To nie jest Vercel, nie jest typowy VPS i nie jest klasyczny hosting WWW. Dobry hosting Node.js powinien dawać:
- uruchamianie procesu Node.js, a nie tylko wrzucenie plików,
- własną komendę startową, np.
npm run start, - zmienne środowiskowe,
- logi aplikacji,
- integrację z GitHub albo przynajmniej sensowny deploy,
- SSL, restart procesu, backupy,
- informację, ile jest RAM, CPU i ile aplikacji Node można uruchomić.
Przykład takiego podejścia w modelu zarządzanym pokazuje Hostinger: plan „Zarządzany hosting Node.js” w polskiej wersji strony jest promowany od 15,99 zł/mies., z odnowieniem 72,99 zł/mies., zasobami 2 vCPU, 3 GB RAM, 50 GB NVMe i nielimitowaną przepustowością; wariant „Node.js na VPS” jest promowany od 34,99 zł/mies., z odnowieniem 64,99 zł/mies., zasobami 2 vCPU, 8 GB RAM, 100 GB NVMe i 8 TB przepustowości. Tego typu oferta ma sens dla prostych aplikacji i klientów, którzy chcą panel, stałą cenę i mniej administracji. Nie wybierałbym jej dla projektu, który wymaga nietypowego reverse proxy, wielu usług Dockerowych, kolejek, Redis, własnego Postgresa i precyzyjnej kontroli procesu wdrożeniowego.
Klasyczny hosting WWW zostaje na końcu listy. Next.js może wygenerować statyczny eksport i wtedy da się go hostować na dowolnym serwerze plików — Apache, Nginx, zwykły hosting, CDN. Ale statyczny eksport nie wspiera funkcji wymagających serwera Node.js albo dynamicznej logiki w runtime: API Routes, rewrites, redirects, headers, proxy, ISR, domyślnej Image Optimization, Draft Mode i getServerSideProps. Taki hosting ma sens dla prostego bloga, landing page’a, dokumentacji albo strony firmowej bez backendu. Nie ma sensu dla aplikacji SSR.
VPS i Coolify — tańsza alternatywa dla większej kontroli
VPS pod Next.js wybiera się nie dlatego, że jest modny, tylko dlatego, że daje kontrolę nad procesem. Uruchamiasz aplikację jako Node.js server, najczęściej przez Docker, PM2 albo systemd, ustawiasz reverse proxy, SSL, firewall, backupy, monitoring i deploy. W zamian masz przewidywalny rachunek: płacisz za serwer, a nie za każde użycie funkcji, requestów czy transferu na platformie serverless.
Next.js oficjalnie wspiera self-hosting. Dokumentacja zaleca użycie reverse proxy, np. Nginx, przed serwerem Next.js, ponieważ proxy przejmuje część ochrony przed błędnymi requestami, wolnymi połączeniami, limitami payloadu, rate limitingiem i podobnymi problemami. Image Optimization działa przy next start, ale przy większej skali trzeba myśleć o cache, dysku, wielu instancjach i trwałym storage dla wygenerowanych stron.
To jest przewaga i koszt VPS-a jednocześnie. Przy jednym małym serwerze wszystko jest proste: aplikacja, baza, Redis, reverse proxy i backupy. Przy dwóch instancjach zaczynają się tematy, których na Vercel często nie dotykasz: wspólny cache, spójny build ID, rolling deployment, współdzielony klucz dla Server Actions, trwały storage i CDN. Next.js opisuje wprost, że domyślny cache w self-hostingu siedzi lokalnie, a przy wielu instancjach trzeba go synchronizować zewnętrznym mechanizmem, np. Redisem albo S3.
Cenowo VPS potrafi wygrać brutalnie. OVHcloud w polskiej ofercie VPS-1 pokazuje 16,32 zł netto / 20,07 zł brutto miesięcznie, bez opłaty instalacyjnej, za 2 vCores, 4 GB RAM, 40 GB SSD NVMe, codzienny automatyczny backup, nielimitowany ruch i 200 Mbps przepustowości do sieci publicznej. VPS-2 to 30,77 zł netto / 37,85 zł brutto miesięcznie, 4 vCores, 8 GB RAM, 75 GB SSD NVMe, backup, nielimitowany ruch i 400 Mbps. DigitalOcean pokazuje Droplety od 4 USD/mies., z billingiem sekundowym i miesięcznym limitem, ale jest to IaaS: dostajesz maszynę, a system operacyjny, aplikacja i dane są po twojej stronie. Dodatkowy transfer wychodzący kosztuje tam 0,01 USD za GiB.
Dla frazy Next.js hosting Polska odpowiedź brzmi więc: jeśli chodzi o lokalne rozliczenie, fakturę, serwer w Europie, przewidywalną cenę i kontrolę, VPS od dostawcy działającego w Polsce lub UE jest rozsądną drogą. Jeśli chodzi o najłatwiejszy deploy Next.js, Polska nie ma większego znaczenia — Vercel, Netlify i Cloudflare i tak działają globalnie. Lokalizacja zaczyna mieć znaczenie przy danych klientów, umowach, RODO, latency do bazy danych i wymaganiach organizacyjnych.
Coolify jest próbą połączenia VPS-a z wygodą platformy typu Vercel. To panel do self-hostingu, który potrafi wdrażać aplikacje, bazy danych i usługi na twoich serwerach. Wersja self-hosted jest darmowa, bez ograniczeń funkcji, ale wymaga własnej infrastruktury. Coolify Cloud kosztuje 5 USD miesięcznie jako base price z możliwością podłączenia 2 serwerów, a każdy dodatkowy serwer to 3 USD miesięcznie; aplikacje nadal działają na twoich serwerach, a Coolify działa jako zarządzany panel.
To bardzo dobra opcja dla małych software house’ów, freelancerów i projektów klienta z niskim budżetem. Zamiast ręcznie konfigurować deploy dla każdej aplikacji, ustawiasz VPS, podpinasz repozytorium, konfigurujesz zmienne, domenę, SSL, bazę danych i deployujesz kolejne projekty podobnym schematem. Koszt infrastruktury może być niski, szczególnie gdy na jednym większym VPS-ie mieści się kilka małych projektów.
Granica jest prosta: Coolify nie zdejmuje odpowiedzialności za serwer. Nadal ktoś musi aktualizować system, kontrolować wykorzystanie dysku, sprawdzać backupy, reagować na padniętą bazę, odtwarzać dane, monitorować RAM i CPU, pilnować certyfikatów, DNS-ów, logów i limitów. Panel upraszcza deploy, ale nie zamienia VPS-a w usługę w pełni zarządzaną.
Dlatego dla projektu klienta trzeba rozdzielić koszt techniczny od kosztu odpowiedzialności. VPS za 20–40 zł miesięcznie wygląda świetnie w Excelu. Jeżeli jednak nikt nie ma w umowie administracji, backupu i reakcji na awarię, „tani hosting Next.js” może po pierwszym incydencie stać się najdroższą decyzją w projekcie.
Najrozsądniejszy układ VPS + Coolify wygląda tak:
- mały projekt klienta: 1 VPS, Coolify, automatyczny deploy, backup plików i bazy poza serwer,
- kilka małych projektów: większy VPS albo dwa VPS-y, osobne kontenery, kontrola zasobów,
- SaaS startujący od zera: VPS + Coolify + zewnętrzny backup + monitoring,
- SaaS rosnący: wydzielenie bazy danych, Redis, object storage, CDN, potem ewentualnie load balancer i więcej instancji.
Nie pchałbym na Coolify projektu, którego nikt techniczny nie będzie utrzymywał. Nie pchałbym też wszystkiego na jeden tani VPS, jeśli aplikacja trzyma bazę produkcyjną, płatności, pliki użytkowników i krytyczny panel administracyjny. Oszczędność ma sens tylko wtedy, gdy nie kasuje bezpieczeństwa.
Który hosting wybrać dla bloga, strony firmowej, SaaS-a i aplikacji klienta?
Najpierw decyzja, potem technologia. Poniższa tabela jest praktyczniejsza niż porównanie funkcji, bo odpowiada na pytanie gdzie hostować Next.js w konkretnym typie projektu.
| Typ projektu | Najlepszy wybór | Kiedy zmienić decyzję |
|---|---|---|
| Landing page | Cloudflare Pages / Vercel | Gdy strona jest statyczna, Cloudflare Pages będzie tańsze i bardzo szybkie. Vercel wybierz, gdy projekt ma iść dalej w stronę aplikacji Next.js. |
| Blog statyczny | Cloudflare Pages / Netlify | Gdy blog używa tylko statycznego eksportu, można użyć nawet klasycznego hostingu WWW. Przy preview CMS, ISR albo podglądach redakcyjnych lepiej Vercel lub Netlify. |
| Strona firmowa | Cloudflare Pages / Netlify / Vercel | Dla formularzy, panelu CMS i preview deploymentów Netlify lub Vercel dadzą mniej pracy. Dla prostych podstron Cloudflare Pages wystarczy. |
| Blog z Headless CMS | Vercel / Netlify | Jeżeli treści mają się odświeżać bez pełnego redeploya, wybieraj platformę z dobrą obsługą ISR/revalidation. |
| Aplikacja SSR | Vercel / Netlify / Cloudflare Workers / VPS | Vercel jest najprostszy. Cloudflare Workers będzie atrakcyjny kosztowo, ale wymaga testów kompatybilności. VPS wybierz przy potrzebie kontroli i przewidywalnej ceny. |
| SaaS z bazą danych | VPS + Coolify / Vercel + zewnętrzna baza / Cloudflare Workers + usługi Cloudflare | VPS daje kontrolę kosztów. Vercel daje szybkość wdrożenia. Cloudflare ma sens, gdy akceptujesz jego runtime i ekosystem. |
| Aplikacja klienta z niskim budżetem | VPS + Coolify | Tylko wtedy, gdy w budżecie jest administracja. Bez tego bezpieczniej wybrać Netlify, Vercel albo zarządzany hosting Node.js. |
| Projekt eksperymentalny | Vercel Free / Netlify Free / Cloudflare Free | Free tier jest dobry do testów, portfolio i MVP. Projekt komercyjny nie powinien opierać się na limitach, których nikt nie monitoruje. |
| Aplikacja z dużym transferem statycznym | Cloudflare Pages / Workers | Cloudflare wygrywa, gdy większość ruchu to statyczne assety. Przy dynamicznym SSR trzeba policzyć Workers requesty i CPU. |
| Panel administracyjny dla firmy | Vercel / VPS + Coolify | Vercel, gdy liczy się szybkie wdrożenie i preview. VPS, gdy ważniejsza jest kontrola środowiska, sieci i kosztów. |
| Projekt wymagający polskiej/UE faktury i kontroli danych | VPS w Polsce/UE + Coolify albo hosting Node.js | Wybieraj, gdy wymagania organizacyjne są ważniejsze niż wygoda serverless. Sprawdź backup, lokalizację danych i SLA. |
| Klasyczna strona bez backendu | Cloudflare Pages / Netlify / klasyczny hosting WWW | Klasyczny hosting tylko przy output: 'export' i braku funkcji serwerowych Next.js. |
W praktyce rekomendacje układają się tak:
1. Najpierw ustal tryb działania aplikacji.
Jeżeli projekt można zbudować jako statyczny eksport, najtańsze i najprostsze opcje to Cloudflare Pages, Netlify albo nawet klasyczny hosting. Jeżeli potrzebujesz getServerSideProps, route handlers, API, ISR, Server Actions albo dynamicznych danych użytkownika, odpada zwykły hosting WWW. Next.js jasno wskazuje, że statyczny eksport nie obsługuje funkcji wymagających serwera Node.js lub dynamicznej logiki w runtime.
2. Jeżeli chcesz najmniej ryzyka technicznego, wybierz Vercel.
To szczególnie sensowne przy aplikacji SSR, MVP SaaS-a, dashboardzie, produkcie z częstymi zmianami i projekcie, w którym koszt pracy developera jest ważniejszy niż różnica kilkunastu dolarów miesięcznie. Ustaw jednak limity kosztów od pierwszego dnia.
3. Jeżeli chcesz dobrą platformę frontendową bez przywiązania do Vercela, wybierz Netlify.
Netlify jest mocne przy preview, pracy zespołowej i statyczno-dynamicznych projektach. Przy większej aplikacji nie patrz tylko na cenę planu, ale na kredyty: deploye, compute, transfer i requesty.
4. Jeżeli projekt jest statyczny lub edge-first, wybierz Cloudflare.
Cloudflare Pages to świetny wybór dla statycznych stron. Cloudflare Workers to dobra opcja dla pełniejszego Next.js, ale wymaga testów w runtime Cloudflare i uważności przy bibliotekach Node.js, middleware i integracjach.
5. Jeżeli chcesz kontroli kosztów i serwera, wybierz VPS + Coolify.
To najlepszy kompromis dla freelancera, małego software house’u, projektu klienta z ograniczonym budżetem albo SaaS-a, który ma przewidywalny ruch. Warunek: backupy, monitoring i administracja muszą być częścią planu, nie dodatkiem „kiedyś się zrobi”.
6. Jeżeli klient chce panel i stałą opłatę, rozważ hosting z Node.js.
To sensowne dla prostych aplikacji, które nie wymagają pełnej kontroli serwera. Przed zakupem sprawdź wersję Node.js, RAM, CPU, limity aplikacji, sposób deployu, logi, zmienne środowiskowe, backupy i odnowienie ceny po promocji.
Najczęstszy błąd to wybór hostingu od ceny, a nie od architektury. „Mam Next.js, więc wrzucę na hosting” działa tylko wtedy, gdy projekt kończy jako statyczne pliki. Przy pełnej aplikacji decyzję zaczyna się od pytań: czy potrzebuję SSR, czy mam bazę danych, czy używam API routes, czy obrazy mają być optymalizowane w locie, czy ruch będzie przewidywalny, kto odpowiada za backup i kto odbierze telefon, gdy aplikacja padnie.
Dobra decyzja startowa wygląda tak: landing i blog statyczny — Cloudflare Pages; aplikacja SSR — Vercel albo Netlify; pełniejszy projekt z kontrolą kosztów — VPS + Coolify; eksperyment — free tier; klasyczny hosting WWW — tylko statyczny eksport. To usuwa większość kosztownych pomyłek już przed pierwszym deployem.
FAQ: najczęstsze pytania o hosting Next.js
Czy Vercel jest najlepszym hostingiem dla Next.js?
Tak, jeżeli priorytetem jest najprostsze wdrożenie, SSR, ISR, preview deploymenty i minimalna konfiguracja. Nie, jeżeli najważniejsza jest najniższa stała cena przy dużym transferze albo pełna kontrola serwera.
Czy Cloudflare Pages nadaje się do Next.js?
Tak, ale głównie do statycznego Next.js. Dla pełnej aplikacji SSR Cloudflare kieruje dziś do Workers i adaptera OpenNext, nie do klasycznego Pages.
Czy można hostować Next.js na zwykłym hostingu WWW?
Tak, tylko jako statyczny eksport. Gdy projekt używa SSR, API Routes, ISR, domyślnej optymalizacji obrazów albo dynamicznej logiki serwerowej, zwykły hosting WWW odpada.
Co jest tańsze: Vercel czy VPS?
Dla małego projektu Vercel może być tańszy, bo oszczędza czas. Dla kilku aplikacji, większego transferu albo stałego ruchu VPS zwykle wygrywa kosztowo, ale dolicz administrację, monitoring i backupy.
Czy Coolify zastępuje Vercel?
Częściowo. Coolify daje wygodniejszy deploy na własnym serwerze, ale nie przejmuje odpowiedzialności za infrastrukturę. Vercel sprzedaje zarządzaną platformę, Coolify upraszcza self-hosting.
Jaki hosting wybrać dla SaaS-a w Next.js?
Na start: Vercel, jeśli liczy się szybkość wdrożenia; VPS + Coolify, jeśli liczy się kontrola kosztów; Cloudflare Workers, jeśli aplikacja pasuje do runtime Cloudflare i chcesz mocno korzystać z edge.
Czy hosting z Node.js wystarczy do Next.js?
Wystarczy, jeśli pozwala uruchomić proces Node.js, obsługuje komendę startową, zmienne środowiskowe, logi, SSL i ma wystarczające zasoby. Nie wystarczy, jeśli to tylko klasyczny hosting plików z dopiskiem „Node.js” bez realnego runtime aplikacji.
Co wybrać dla projektu klienta z niskim budżetem?
VPS + Coolify, ale tylko z jasno wpisaną administracją i backupami. Bez tego lepszy będzie Netlify, Vercel albo zarządzany hosting Node.js, bo mniej rzeczy zostaje po stronie klienta i freelancera.
