Astro od kilku wersji nie jest wyłącznie generatorem stron statycznych. Tryb SSR, trasy API, autoryzacja po stronie serwera i bezpośredni dostęp do bazy danych tworzą realny backend, nie tylko renderowanie markdownu podczas budowania projektu. A infrastruktura hostingowa nie zawsze za tym nadąża. Część platform obsługuje SSR tylko przez własny adapter, który ogranicza to, co możesz zrobić. Część rozlicza Cię za każde wywołanie funkcji, mimo że pod spodem i tak stoi zwykły proces Node.js.
Wdrażałem projekty Astro, zarówno statyczne, jak i SSR, na kilku różnych platformach. Poniżej znajdziesz realne różnice, a nie porównanie ze stron sprzedażowych dostawców.
Statyka i SSR to dwa różne pytania
Zanim wybierzesz hosting, odpowiedz sobie na jedno pytanie: czy Twoja strona faktycznie renderuje coś na żądanie, czy tylko wygląda dynamicznie, a w praktyce całą treść da się wygenerować podczas budowania projektu?
W sytuacji, w której masz bloga, portfolio, stronę produktową czy dokumentację, w 9 na 10 przypadków wystarczy output: 'static', a wtedy wybór hostingu to głównie kwestia limitu transferu i ceny, ponieważ różnice w wydajności między dostawcami są marginalne.
W wypadku projektów z logiką wymagającą świeżych danych przy każdym żądaniu, na przykład personalizację, dashboard, checkout albo cokolwiek z sesją użytkownika, wchodzisz w tryb SSR. Tam różnice między platformami robią się poważne: zimne starty, limity czasu wykonania funkcji, brak długo żyjących połączeń.
Dopiero układasz architekturę projektu? Zacznij od rozróżnienia statyki, wysp i renderowania na żądanie. Szerzej omawiam to w artykułach o Server Islands w Astro oraz o kontrolowaniu JavaScriptu w Astro.
Porównanie platform
| Platforma | Tryb statyczny | Tryb SSR | Adapter | Orientacyjna cena |
|---|---|---|---|---|
| Vercel | Bardzo dobry, bez konfiguracji | Serverless (zimne starty) | @astrojs/vercel | Bezpłatnie / od ok. 76 zł/mies. (20 USD) |
| Netlify | Bardzo dobry, podglądy wdrożeń | Netlify Functions (zimne starty) | @astrojs/netlify | Bezpłatnie / od ok. 76 zł/mies. (20 USD) |
| Cloudflare Pages | Świetny, bez limitu transferu | Workers, ograniczenia środowiska | @astrojs/cloudflare | Bezpłatnie / Workers od ok. 19 zł/mies. (5 USD) |
| Railway | OK, ale nie to jest mocna strona | Natywny Node.js, bez zimnych startów | @astrojs/node | Od ok. 4 zł/mies. (1 USD) + zużycie |
| Render | Bezpłatnie, ale z usypianiem | Usługa web, stabilna | @astrojs/node | Bezpłatnie (statyka) / od ok. 27 zł/mies. (7 USD) |
| DigitalOcean App Platform | Działa, więcej konfiguracji | Usługa web | @astrojs/node | Od ok. 19 zł/mies. (5 USD) |
Ceny zmieniają się regularnie, więc traktuj je jako orientację do porównania rzędu wielkości, nie jako aktualny cennik. Kwoty w złotówkach liczę po zaokrąglonym kursie 1 USD ≈ 3,80 zł z 24 lipca 2026 roku. Przed decyzją zawsze sprawdź oficjalną stronę dostawcy.
Vercel: dobry wybór, jeśli już tam jesteś
Vercel to domyślny wybór dla wielu projektów JavaScriptowych, a integracja z Astro faktycznie działa bez problemów w trybie statycznym: automatyczne wykrywanie frameworka, cache na brzegu sieci, podgląd każdego PR-a.
Przy SSR sprawy się trochę komplikują. Adapter @astrojs/vercel wdraża Twoje trasy serwerowe jako funkcje serverless, co oznacza zimne starty (realnie 200-500 ms), limity czasu wykonania (10 s na planie darmowym, 60 s na planie Pro) i brak trwałych połączeń. WebSockety czy długo działające procesy po prostu nie zadziałają.
Warto też liczyć się z tym, że opłaty za transfer, wywołania funkcji i minuty builda potrafią się sumować szybciej, niż się wydaje. Projekt hobbystyczny po jednym skoku ruchu może nagle przeskoczyć z darmowego planu na kilkadziesiąt dolarów miesięcznie.
Vercel jest sensownym wybórem, gdy masz już inne projekty (np. Next.js) na Vercelu i chcesz trzymać Astro w tym samym koncie, albo Twoja strona jest w pełni statyczna. Jeśli porównujesz decyzję z projektem Next.js, zobacz też osobny tekst o tym, gdzie hostować Next.js w 2026 roku.
Netlify: solidny, ale z tymi samymi ograniczeniami co Vercel
Netlify robił hosting stron statycznych, zanim to było modne, i integracja z Astro jest bardzo dobrze dopracowana: podglądy wdrożeń, obsługa formularzy, funkcje serverless wbudowane w platformę.
SSR działa przez Netlify Functions, czyli ich odpowiednik AWS Lambda. Problem zimnych startów jest tu odczuwalny bardziej niż na Vercelu. Pierwsze żądanie po dłuższym okresie bezczynności potrafi trwać ponad sekundę, co dla strony SSR, gdzie użytkownik oczekuje natychmiastowej odpowiedzi, jest zauważalne.
Netlify to dobry wybór, gdy budujesz stronę mocno opartą na treści i zależy Ci na podglądach wdrożeń oraz obsłudze formularzy bez własnego backendu.
Cloudflare Pages: najlepszy darmowy hosting dla statyki
Dla czystej statyki Cloudflare Pages jest trudny do pobicia: bez limitu transferu na darmowym planie, brak zimnych startów, globalna sieć . Realnie 0 zł miesięcznie nawet przy sporym ruchu.
SSR to inna historia. Adapter @astrojs/cloudflare kompiluje kod serwerowy do uruchomienia na Workers, czyli izolacie V8, a nie Node.js. Oznacza to brak modułu fs, node:path, child_process i ograniczone node:crypto. Jeśli Twój kod SSR albo jakakolwiek zależność korzysta z API Node.js, nie zadziała bez polyfilli albo przepisania. Do tego dochodzi limit 128 MB pamięci i 30 sekund czasu CPU na planie darmowym, a dostęp do bazy danych wymaga Cloudflare D1 albo połączeń zewnętrznych przez service bindings.
Cloudflare Pages to odpowiedni wybór, w sytuacji gdy strona jest w pełni statyczna i zależy Ci na zerowym koszcie hostingu. Nie polecam go do SSR, chyba że świadomie akceptujesz ograniczenia środowiska Workers. Jeśli rozważasz ten kierunek, najpierw przeczytaj tekst o wdrożeniu Astro na Cloudflare Workers.
Railway, Render, DigitalOcean: realny Node.js zamiast serverless
Te trzy platformy mają jeden wspólny mianownik: zamiast kompilować Twój kod do funkcji serverless, uruchamiają go jako zwykły proces Node.js przez standardowy adapter @astrojs/node. Oznacza to w praktyce brak zimnych startów, brak limitów czasu wykonania i brak zależności od adaptera konkretnego dostawcy. Twój kod po prostu działa tak samo jak lokalnie.
Railway ma wygodne środowisko pracy (czytelny panel, jednoklikowe bazy danych), ale rozliczenie jest zależne od zużycia. Płacisz za CPU, RAM i transfer, więc realny koszt poznasz dopiero na fakturze. Mały projekt z niedużym ruchem może zmieścić się w ok. 19 zł (5 USD), a projekt ze stałym ruchem spokojnie przekroczyć 57-76 zł (15-20 USD).
Render ma darmową statykę, ale z usypianiem po 15 minutach nieaktywności (pierwszy użytkownik czeka nawet kilkadziesiąt sekund), a SSR wymaga płatnej usługi web od ok. 27 zł/mies. (7 USD). Budowanie projektu bywa zauważalnie wolniejsze niż na innych platformach.
DigitalOcean App Platform działa dobrze, jeśli już masz tam infrastrukturę (bazy danych, droplety) i chcesz trzymać wszystko w ramach jednego konta. Konfiguracja przez YAML jest jednak bardziej rozbudowana, niż wymaga tego pojedynczy projekt Astro.
Co poza tą listą: zwykły VPS i mniejsi dostawcy
Warto pamiętać, że powyższa lista to platformy PaaS z gotowym procesem wdrożenia. Alternatywą, czasem tańszą i prostszą w utrzymaniu dla projektu SSR, jest zwykły VPS (Hetzner, DigitalOcean Droplet) z adapterem @astrojs/node uruchomionym za pm2 albo systemd. Inną opcją jest jeden z mniejszych, wyspecjalizowanych hostingów oferujących płaski cennik za proces Node.js zamiast rozliczenia według zużycia. To rozwiązanie wymaga trochę więcej pracy na starcie (konfiguracja serwera, SSL, reverse proxy), ale eliminuje niepewność co do rachunku na koniec miesiąca. Przy takim modelu rozliczeń to realny problem przy nagłym wzroście ruchu.
Który adapter wybrać
Jeśli hostujesz na platformie serverless, używasz jej dedykowanego adaptera: @astrojs/vercel, @astrojs/netlify albo @astrojs/cloudflare. Jeśli hostujesz gdziekolwiek, gdzie kod działa jako natywny proces Node.js (Railway, Render, DigitalOcean, VPS), używasz @astrojs/node. To ten drugi jest najbardziej przenośny. Działa na każdej platformie z Node.js, więc zmiana hostingu w przyszłości nie wymaga przepisywania warstwy serwerowej.
Jak wybieram hosting w projektach StriveLab
W praktyce decyzja sprowadza się do trzech pytań:
- Strona w pełni statyczna? Cloudflare Pages, jeśli priorytetem jest koszt zero, albo Vercel/Netlify, jeśli chcesz wdrożenie bez konfiguracji i podgląd PR-ów.
- SSR z realnym ruchem? Platforma z natywnym Node.js (Railway, Render, DigitalOcean albo VPS) zamiast serverless. Unikasz zimnych startów i nieprzewidywalnych limitów czasu wykonania.
- Już jesteś w jakimś ekosystemie (Vercel dla Next.js, DigitalOcean dla reszty infrastruktury)? Zostań tam, dopóki nie zaczniesz trafiać w limity. Migracja hostingu ma sens dopiero wtedy, gdy pojawia się realny problem, nie prewencyjnie.
Dla klientów, którzy pytają mnie o rekomendację na starcie projektu, domyślnie proponuję Vercel jako punkt wyjścia dla Astro i Next.js, głównie ze względu na najniższy próg wejścia i wygodę pracy przy iteracji. Ale też nie zawsze, bo jeśli projekt ma realny SSR i przewidywalny, stały ruch, koszt na Vercelu potrafi z czasem przewyższyć prostszy setup na hoście Node.js. Pełny rachunek warto zestawić z kosztami utrzymania całej strony, bo w projektach treściowych hosting jest tylko częścią wyniku. Ten temat rozwijam w artykule o kosztach utrzymania Astro i Cloudflare kontra WordPress.
