Cloudflare Workers i Pages

Cloudflare Workers i Pages: szybkie strony i API bez utrzymywania serwerów

Cloudflare Workers to platforma typu serverless, czyli taka, w której infrastrukturą zarządza dostawca, a zespół dostarcza tylko kod. Strona, API lub cała aplikacja działa w globalnej sieci Cloudflare, obejmującej setki lokalizacji, więc żądanie jest obsługiwane blisko użytkownika, a firma nie utrzymuje własnych serwerów. Cloudflare Pages to osobna usługa tej samej firmy, służąca do publikowania stron statycznych i frontendów prosto z repozytorium Git.

W kwietniu 2025 roku Cloudflare ogłosił, że w Workers można budować kompletne aplikacje – z plikami statycznymi, renderowaniem po stronie serwera i bazą danych – i że dalsze inwestycje oraz nowe funkcje kieruje właśnie tam. Usługa Pages nadal jest wspierana. Poniżej porównujemy obie usługi i opisujemy, jak je wdrażamy.

Czym są Workers i Pages i co je wyróżnia

Workers uruchamia kod nie w kontenerach ani na maszynach wirtualnych, lecz w izolatach V8 – lekkich, oddzielonych od siebie środowiskach silnika JavaScript znanego z przeglądarki Chrome. Według dokumentacji Cloudflare izolat startuje około stu razy szybciej niż proces Node.js w kontenerze i zużywa o rząd wielkości mniej pamięci. Skraca to tzw. zimny start, czyli opóźnienie przy pierwszym wywołaniu po przerwie.

Kod powstaje w JavaScripcie, TypeScripcie, Pythonie lub Ruście, a platforma współpracuje z frameworkami takimi jak React, Vue, Svelte, Next.js i Astro. Usługi Cloudflare podłącza się przez tzw. powiązania (bindings), bez osobnych serwerów:

• KV – magazyn klucz–wartość do szybkich odczytów, np. konfiguracji i danych w pamięci podręcznej. Jest „ostatecznie spójny” (eventually consistent): zmiana może dotrzeć do innych lokalizacji po 60 sekundach lub później.
• D1 – zarządzana baza SQL z semantyką SQLite. Funkcja Time Travel pozwala przywrócić jej stan z dowolnej minuty ostatnich 30 dni, a pojedyncza baza może mieć do 10 GB (oba limity dotyczą planu płatnego). Usługa jest projektowana pod wiele mniejszych baz, np. osobną dla każdego klienta systemu.
• R2 – magazyn plików zgodny z API Amazon S3, bez opłat za transfer danych wychodzących (egress).
• Durable Objects – obiekty z silnie spójnym magazynem danych do koordynacji wielu użytkowników naraz: czatów, wspólnej edycji, powiadomień na żywo.
• Queues i Hyperdrive – kolejki zadań z gwarancją dostarczenia oraz szybsze połączenie z istniejącą bazą PostgreSQL lub MySQL.

Cloudflare Workers – cała aplikacja w jednym wdrożeniu

Worker może jednocześnie serwować pliki statyczne – HTML, CSS, obrazy, skrypty – i wykonywać kod po stronie serwera. Według dokumentacji zapytania o pliki statyczne są bezpłatne i bez limitu, a płatne jest dopiero uruchomienie kodu, np. przy renderowaniu strony po stronie serwera (SSR). Strona, frontend sklepu czy panel klienta mogą więc działać jako jedno wdrożenie z jednego repozytorium.

Worker może też działać przed istniejącą stroną, np. przed WordPressem. Trasy (routes) uruchamiają kod dla wybranych adresów domeny obsługiwanej przez Cloudflare – tak wdraża się przekierowania przy zmianie adresów, nagłówki bezpieczeństwa czy testy A/B bez zmian w kodzie serwera.

Wdrożenia obsługuje narzędzie wiersza poleceń Wrangler albo Workers Builds – integracja z GitHubem i GitLabem, która publikuje zmiany z gałęzi produkcyjnej, a dla pozostałych gałęzi tworzy podgląd. Do dyspozycji są też:

• adresy wersji (version URLs) – podgląd przed wdrożeniem, który można zabezpieczyć logowaniem przez Cloudflare Access,
• wdrożenia stopniowe (gradual deployments) – nowa wersja najpierw obsługuje tylko część ruchu,
• Cron Triggers – kod uruchamiany według harmonogramu, np. do synchronizacji danych.

Cloudflare Pages – publikacja stron z repozytorium Git

Pages łączy się z repozytorium w GitHubie lub GitLabie i buduje stronę przy każdym commicie. Gałąź produkcyjna trafia pod główny adres, a każda inna dostaje adres podglądu, widoczny także w pull requestach (prośbach o scalenie zmian). Podglądy mają nagłówek X-Robots-Tag: noindex, więc nie trafiają do wyszukiwarek, a dostęp do nich można ograniczyć przez Cloudflare Access. Pages obsługuje też wgrywanie gotowych plików (Direct Upload), funkcje po stronie serwera i szybki powrót do poprzedniej wersji.

W dokumentacji Pages Cloudflare pisze wprost, że Workers obsługuje większość zastosowań Pages, ma szerszy zestaw funkcji i jest główną platformą firmy do budowy aplikacji, dlatego nowe projekty należy zaczynać od Workers. Pages zachowuje jednak kilka przewag:

• subdomenę można podpiąć samym rekordem CNAME, bez przenoszenia DNS do Cloudflare (Workers z własną domeną wymaga strefy DNS w Cloudflare),
• pełna obsługa Early Hints, czyli odpowiedzi HTTP 103 z podpowiedzią, jakie pliki przeglądarka może pobrać wcześniej,
• routing funkcji wynikający ze struktury plików, bez kompilacji.

Przeniesienie projektu z Pages do Workers opisuje oficjalny przewodnik Cloudflare. Według dokumentacji migracja jest często prosta, bo popularne frameworki mają gotowe adaptery dla Workers.

Kiedy warto wybrać Workers lub Pages i co to daje firmie

• Strona firmowa lub landing page – bez serwera, którego system trzeba aktualizować.
• Strona headless – frontend, np. w Astro lub Next.js, pobiera treści z CMS-a przez API; więcej piszemy na stronie o stronach headless CMS.
• API, formularze i webhooki – np. przekazywanie zapytań z formularza do CRM bez utrzymywania osobnej aplikacji.
• Użytkownicy w wielu krajach – żądania obsługuje lokalizacja Cloudflare najbliższa odwiedzającemu.

Jeśli aplikacja potrzebuje pełnego serwera z dostępem do systemu operacyjnego, procesów działających stale w tle albo jednej dużej, mocno obciążonej bazy relacyjnej, lepiej sprawdzi się zwykle maszyna wirtualna i zarządzana baza w chmurze. Worker może wtedy działać przed aplikacją, a z bazą łączyć się przez Hyperdrive. Osobną usługą jest Cloudflare Argo, które kieruje ruch najwydajniejszą ścieżką w sieci Cloudflare, omijając przeciążenia – opisujemy je na stronie Cloudflare Argo.

Co budujemy i utrzymujemy na Cloudflare w G2 TEAM

Jako agencja interaktywna i software house tworzymy strony internetowe, sklepy, aplikacje webowe i portale. Na Cloudflare Workers i Pages przygotowujemy elementy, które nie wymagają własnego serwera:

• strony firmowe i landing pages publikowane jako Worker z plikami statycznymi,
• frontendy stron headless i sklepów połączone z CMS-em lub platformą e-commerce,
• API i integracje dla aplikacji webowych i portali – z bazą D1, plikami w R2 i kolejkami zadań,
• warstwy przed istniejącymi stronami: przekierowania 301, nagłówki bezpieczeństwa, ograniczenie dostępu do wybranych sekcji.

Utrzymanie obejmuje aktualizacje zależności, kontrolę logów i błędów, przegląd zużycia płatnych usług i porządek w tokenach dostępowych.

Workers i Pages a inne platformy

Wybór zależy od tego, co ma działać po stronie serwera, gdzie mają być dane i kto będzie utrzymywał projekt. Platformę Vercel, alternatywę zwłaszcza dla projektów w Next.js, opisujemy na stronie Vercel.

Jak pracujemy z Cloudflare

1. Konto klienta. Konto Cloudflare zakładamy na firmę klienta – to klient jest jego właścicielem, a nasz zespół dostaje dostęp jako członkowie konta.
2. Repozytorium i sekrety. Kod, konfiguracja Wranglera i dokumentacja trafiają do repozytorium Git. Wdrożenia z systemu CI używają tokenów API o możliwie wąskich uprawnieniach, zapisanych jako sekrety, nigdy w kodzie.
3. Podgląd i akceptacja. Każda zmiana ma adres podglądu, który klient sprawdza przed publikacją; podgląd może wymagać logowania.
4. Wdrożenie. Publikację uruchamia integracja z GitHubem lub GitLabem albo zewnętrzny system CI, np. Bitbucket Pipelines z Wranglerem.
5. Kopie, monitoring i koszty. Bazy D1 chroni Time Travel, a dodatkowo można je eksportować do pliku SQL. Logi pozwalają szybko wychwycić błędy, a zużycie płatnych usług sprawdzamy w panelu Cloudflare.

Najczęstsze pytania

Nowy projekt: Workers czy Pages?

Zwykle Workers – tak zaleca Cloudflare i tam trafiają nowe funkcje. Pages ma sens przy istniejących projektach albo wtedy, gdy strona ma działać na subdomenie, a DNS domeny ma zostać u obecnego dostawcy.

Czy domenę trzeba przenieść do Cloudflare?

Nie trzeba zmieniać rejestratora. Workers z własną domeną wymaga jednak, aby strefę DNS obsługiwał Cloudflare, czyli zmiany serwerów nazw. W Pages subdomenę wystarczy wskazać rekordem CNAME, ale domena główna (bez „www”) również wymaga strefy w Cloudflare.

Gdzie przechowywane są dane?

Kod Workera wykonuje się w lokalizacji Cloudflare, do której trafia żądanie. Dla baz D1 i magazynów R2 można jednak ustawić jurysdykcję UE: baza D1 działa i przechowuje dane wyłącznie w Unii Europejskiej, a pliki w R2 pozostają w UE. Przy danych osobowych ustalamy to już na etapie projektu architektury.

Czy na Cloudflare Workers uruchomimy WordPressa?

WordPress wymaga PHP i bazy MySQL lub MariaDB, więc zostaje na serwerze. Worker może działać przed nim, a przy przebudowie na model headless WordPress pozostaje panelem do edycji treści, podczas gdy frontend działa na Workers.

Porozmawiajmy o Twoim projekcie

Planujesz stronę lub API na Cloudflare, chcesz przenieść projekt z Pages do Workers albo sprawdzić, czy ta platforma pasuje do Twojej aplikacji? Opisz sytuację w formularzu „Zapytaj o ofertę” poniżej. Odpowiemy z propozycją architektury i zakresu prac, a jeśli Cloudflare nie będzie dobrym wyborem, powiemy to wprost.