Cloudflare Workers: darmowy backend, API i serverless functions dla małych aplikacji

Mała aplikacja bardzo szybko dobija do ściany: frontend już działa, strona statyczna jest szybka, ale nagle trzeba obsłużyć formularz kontaktowy, odebrać webhook, ukryć klucz do zewnętrznego API albo zapisać kilka rekordów. Stawianie pełnego VPS-a tylko po to, żeby zwrócić JSON albo przekazać dane do CRM-u, często jest przerostem formy nad treścią. Cloudflare Workers rozwiązuje dokładnie ten problem: daje mały backend uruchamiany na infrastrukturze Cloudflare, bez utrzymywania klasycznego serwera, procesu Node.js i osobnego deploya aplikacji backendowej.

Nie jest to jednak magiczny, darmowy serwer bez limitów. Workers działa w modelu serverless/edge, ma własny runtime, własny sposób liczenia zasobów i własne ograniczenia. Dobrze użyty świetnie nadaje się do małych API, formularzy, webhooków, proxy i lekkiej logiki przy stronie statycznej. Źle użyty potrafi zamienić prosty projekt w zestaw obejść, limitów i trudnych do debugowania różnic względem klasycznego Node.js.

Czym są Workers i dlaczego to coś więcej niż CDN?

Cloudflare kojarzy się z CDN-em, DNS-em i ochroną przed ruchem śmieciowym. Workers idą krok dalej: pozwalają uruchamiać kod po stronie serwera na platformie Cloudflare, blisko użytkownika, bez własnej maszyny, Nginxa, PM2, kontenera czy ręcznego skalowania. Cloudflare opisuje Workers jako platformę serverless do budowania, wdrażania i skalowania aplikacji w globalnej sieci Cloudflare; obsługiwane są między innymi JavaScript, TypeScript, Python i Rust.

Praktycznie wygląda to tak: użytkownik wchodzi pod adres, Cloudflare odbiera request, a Worker może:

• zwrócić JSON,
• wykonać request do zewnętrznego API,
• sprawdzić token,
• przekształcić odpowiedź,
• zapisać dane do KV, D1 albo R2,
• ustawić nagłówki cache,
• przekierować użytkownika,
• odrzucić spam,
• obsłużyć endpoint typu /api/contact.

Największa różnica względem klasycznego backendu polega na tym, że Worker nie jest procesem Node.js działającym stale na serwerze. To funkcja uruchamiana na żądanie w środowisku edge runtime. Nie myślisz o porcie 3000, reverse proxy i restartach procesu. Myślisz o handlerze requestu, odpowiedzi i limitach wykonania.

Stan na 19 czerwca 2026 r.: plan Workers Free daje 100 000 requestów dziennie i 10 ms CPU time na wywołanie. Plan płatny Workers Paid / Standard kosztuje minimum 5 USD miesięcznie, zawiera 10 mln requestów miesięcznie, a kolejne kosztują 0,30 USD za milion; zawiera też 30 mln CPU ms miesięcznie, a nadwyżka kosztuje 0,02 USD za milion CPU ms.

Tu trzeba rozróżnić dwie rzeczy: czas oczekiwania i czas CPU. Gdy Worker czeka na odpowiedź z API, bazy czy KV, nie zużywa CPU w takim samym sensie jak kod intensywnie liczący dane. Cloudflare mierzy CPU jako czas faktycznego wykonywania kodu; oczekiwanie na sieć nie jest wliczane do CPU time. To dlatego Workers dobrze pasują do logiki typu „odbierz request, sprawdź dane, zawołaj API, zwróć odpowiedź”, ale gorzej do ciężkiego renderowania, kompresowania dużych plików czy długiego przetwarzania danych.

Granica jest prosta: Worker jest świetny jako cienka warstwa backendowa, ale nie powinien udawać pełnego serwera aplikacyjnego, który wykonuje ciężką pracę w pamięci. Limit pamięci wynosi 128 MB na isolate, a przy przekroczeniu limitów Cloudflare może zwrócić błąd zasobów. Jeżeli aplikacja musi parsować duże pliki, przetwarzać obrazy, budować raporty przez kilka minut albo trzymać dużo danych w RAM-ie, trzeba od razu rozważyć inną architekturę: kolejki, osobny backend, Durable Objects, R2, zewnętrzną bazę albo klasyczny serwer.

Drugi niuans: Workers obsługują część API znanych z Node.js, ale to nie jest zwykły Node.js. Tryb nodejs_compat włącza kompatybilność z częścią wbudowanych API Node, jednak dokumentacja Cloudflare jasno rozróżnia API obsługiwane natywnie, częściowo obsługiwane oraz takie, które są tylko stubami lub polyfillami. W praktyce oznacza to, że biblioteka oparta o fetch, crypto, URL czy lekkie zależności zwykle przejdzie bez bólu. Biblioteka, która zakłada dostęp do procesu systemowego, nietypowego filesystemu, serwera HTTP tworzonego ręcznie albo długowiecznego połączenia w stylu klasycznego backendu, może się wyłożyć.

Najrozsądniejszy start:

• dla prostego endpointu użyj czystego Workera;
• dla większej liczby tras dodaj lekki router, na przykład Hono;
• dla sekretów używaj Wrangler secrets, nie zmiennych w kodzie;
• dla frontendu trzymaj statyczne pliki osobno, a Worker zostaw do logiki;
• przed deployem sprawdź, czy paczki npm działają w runtime Cloudflare, a nie tylko lokalnie w Node.

Workers to więc nie „CDN z dodatkiem JS”. To mały, szybki backend na brzegu sieci. Ale jego siła wynika właśnie z ograniczeń: im mniej udaje klasyczny serwer, tym lepiej działa.

API, formularz kontaktowy, webhooki i proxy bez własnego serwera

Najlepsze zastosowania Workers zaczynają się od bardzo konkretnych problemów. Strona statyczna ma formularz, ale nie ma gdzie wysłać danych. Landing page potrzebuje endpointu /api/lead. Aplikacja frontendowa korzysta z zewnętrznego API, ale nie można pokazać klucza w przeglądarce. Sklep wysyła webhook, który trzeba zweryfikować i zapisać. W takich przypadkach Worker daje backend dokładnie tam, gdzie jest potrzebny — między użytkownikiem, frontendem i usługą zewnętrzną.

Typowe zastosowania:

• formularz kontaktowy — Worker odbiera dane, waliduje pola, sprawdza honeypot lub Turnstile, wysyła wiadomość do usługi mailowej albo zapisuje lead;
• webhooki — Worker sprawdza podpis, odrzuca niepoprawny request, zapisuje zdarzenie i szybko zwraca 200 OK;
• API dla strony statycznej — frontend pobiera JSON z Workera zamiast z ciężkiego backendu;
• proxy do zewnętrznego API — Worker ukrywa klucz API, dodaje limity, filtruje parametry i normalizuje odpowiedź;
• krótkie linki — Worker sprawdza slug w KV albo D1 i robi przekierowanie;
• generowanie odpowiedzi JSON — Worker może składać dane z kilku źródeł i oddawać prosty format dla frontendu;
• zapis prostych danych — KV dla konfiguracji i prostych wpisów, D1 dla relacyjnych rekordów;
• obsługa plików przez R2 — upload, odczyt, podpisywane adresy, publiczne assety;
• cache na edge — Worker może zapisać odpowiedź w Cache API albo sterować cache przez fetch.

W praktycznym projekcie najpierw rozdzieliłbym ścieżki na trzy grupy:

1. Publiczne i statyczne — HTML, CSS, JS, obrazy. Tego nie przepuszczać przez funkcję, jeżeli nie trzeba.
2. API lekkie — formularze, proxy, JSON, krótkie linki, webhooki. To dobry teren dla Workers.
3. Operacje ciężkie lub długie — importy, raporty, obróbka plików, intensywne liczenie. Tego nie wciskać na siłę do jednego requestu.

Przykład minimalnej logiki dla formularza wygląda koncepcyjnie tak:

export default {
  async fetch(request, env, ctx) {
    if (request.method !== "POST") {
      return new Response("Method not allowed", { status: 405 });
    }

    const data = await request.json();

    if (!data.email || !data.message) {
      return Response.json({ error: "Brakuje emaila lub treści" }, { status: 400 });
    }

    // Tu: walidacja, antyspam, wysyłka do API mailowego lub zapis do D1/KV.
    return Response.json({ ok: true });
  }
};

To nie jest jeszcze produkcyjny formularz. Produkcyjna wersja powinna mieć walidację długości pól, ochronę przed spamem, limit metod, poprawne CORS, obsługę błędów z zewnętrznego API i brak sekretów w kodzie. Najczęstszy błąd w małych projektach wygląda banalnie: endpoint działa, ale przyjmuje dowolny payload, dowolną metodę i wysyła wszystko dalej. Po kilku dniach formularz robi za darmową bramkę do spamu.

Dla webhooków najważniejsza zasada brzmi: odpowiedz szybko, a cięższą pracę odłóż. Webhook ze Stripe, GitHuba, systemu płatności albo CMS-a nie powinien czekać, aż aplikacja wykona pięć kolejnych requestów i zapisze kilka dużych struktur. Najpierw trzeba zweryfikować podpis, zapisać minimalne zdarzenie, zwrócić sukces, a przetwarzanie puścić dalej — na przykład przez kolejkę albo osobny proces. Cloudflare ma też Queues, ale w prostym artykule o małych aplikacjach wystarczy decyzja: Worker nie powinien blokować webhooka długą pracą.

Przy proxy do zewnętrznego API Workers są szczególnie wygodne. Frontend nie dostaje klucza API, a Worker może wymusić listę dozwolonych parametrów. To ważne. Proxy typu „przekaż dowolny URL z query stringa” jest proszeniem się o kłopoty, bo szybko staje się otwartą bramką do nadużyć. Dobre proxy powinno mieć:

• stały host docelowy, a nie dowolny URL od użytkownika;
• whitelistę parametrów;
• limit rozmiaru odpowiedzi;
• timeout;
• cache dla powtarzalnych zapytań;
• osobny sekret trzymany poza repozytorium;
• logowanie błędów bez logowania pełnych danych osobowych.

Trzeba też pilnować subrequestów. Na planie Free pojedyncze wywołanie Workera ma limit 50 subrequestów, a do usług wewnętrznych Cloudflare 1000 subrequestów; na planie Paid limit wynosi domyślnie 10 000 i może być konfigurowany wyżej. To wystarcza dla formularza albo małego API. Nie wystarcza dla endpointu, który dla jednego użytkownika odpytuje setki adresów, robi batch do wielu usług i jeszcze generuje z tego raport.

Dla cache na edge wybór zależy od danych. Jeżeli odpowiedź jest publiczna i taka sama dla wszystkich, można używać cache agresywnie. Jeżeli odpowiedź zależy od użytkownika, tokena albo ciasteczka, trzeba uważać. Cache API w Workers pozwala ręcznie czytać i zapisywać odpowiedzi w cache Cloudflare, ale zawartość Cache API nie replikuje się automatycznie między centrami danych; odpowiedź zapisana w jednym miejscu nie musi od razu istnieć w innym. To dobry mechanizm dla publicznych odpowiedzi i danych pomocniczych, nie dla krytycznego stanu aplikacji.

W małych aplikacjach najlepiej sprawdza się taki podział:

• formularz kontaktowy: Worker + walidacja + zewnętrzne API mailowe lub D1;
• webhook: Worker + weryfikacja podpisu + szybki zapis zdarzenia;
• proxy API: Worker + sekrety + whitelisty + cache;
• krótkie linki: Worker + KV, gdy przekierowania rzadko się zmieniają;
• mały panel lub katalog: Worker + D1;
• pliki użytkownika: Worker + R2;
• często czytana konfiguracja: KV;
• publiczne odpowiedzi JSON: Cache API albo KV, zależnie od wymagań spójności.

Największy priorytet na starcie: ograniczyć zakres. Jeden Worker do jednego celu. Formularz, webhook i proxy do płatności w jednym pliku brzmi szybciej, ale potem trudniej ustawić limity, logowanie i odpowiedzialność za błędy.

Workers, KV, R2, D1 i Pages — jak wybrać właściwe narzędzie Cloudflare?

Cloudflare ma dziś cały zestaw usług, które łatwo wrzucić do jednego worka. Błąd polega na tym, że Workers, KV, R2, D1 i Pages rozwiązują różne problemy. Jeżeli wybierzesz je według hasła „darmowe”, a nie według typu danych, aplikacja zacznie pękać tam, gdzie pojawi się pierwszy realny ruch.

Workers to logika. Kod, routing, walidacja, proxy, JSON, webhooki, autoryzacja, składanie odpowiedzi. Od tego zaczynasz, gdy potrzebujesz backendu bez serwera.

KV to globalny magazyn klucz-wartość. Nadaje się do danych czytanych bardzo często i zmienianych rzadko: konfiguracji, flag funkcji, mapowania krótkich linków, prostych ustawień, cache’owanych odpowiedzi. Cloudflare opisuje KV jako magazyn globalny, niskolatencyjny i dobry dla wysokiego wolumenu odczytów.

Ale KV ma ważne ograniczenie: eventual consistency. Zmiana wykonana w jednym miejscu zwykle jest szybko widoczna lokalnie, ale w innych lokalizacjach może pojawić się po czasie, często do około 60 sekund lub dłużej, zależnie od cache. Dlatego KV nie jest dobrym miejscem na saldo użytkownika, licznik wymagający natychmiastowej spójności, rezerwacje albo dane, przy których świeżo zapisany rekord musi być natychmiast widoczny globalnie.

Limity KV są konkretne: Free daje 100 000 odczytów dziennie, 1000 zapisów dziennie, 1000 usunięć dziennie, 1000 operacji listowania dziennie i 1 GB danych. Plan płatny zawiera między innymi 10 mln odczytów miesięcznie, 1 mln zapisów miesięcznie i 1 GB danych, a nadwyżki kosztują odpowiednio 0,50 USD za mln odczytów, 5 USD za mln zapisów/usunięć/listowań oraz 0,50 USD za GB-miesiąc. Dodatkowo KV ma limit 1 zapisu na sekundę do tego samego klucza, wartość może mieć do 25 MiB, a klucz do 512 bajtów.

R2 wybierasz do plików. Obrazy, dokumenty, eksporty, załączniki, backupy, assety, pliki generowane przez użytkowników. To obiektowy storage zgodny ideowo z podejściem S3. Najważniejszy argument kosztowy: Cloudflare R2 nie nalicza opłat za egress do Internetu, a free tier dla standardowego storage obejmuje 10 GB-month miesięcznie, 1 mln operacji Class A miesięcznie, 10 mln operacji Class B miesięcznie i darmowy egress.

Ceny R2 Standard po przekroczeniu darmowej puli: 0,015 USD za GB-month, 4,50 USD za mln operacji Class A i 0,36 USD za mln operacji Class B. Dla Infrequent Access storage ceny są inne: 0,01 USD za GB-month, 9 USD za mln Class A, 0,90 USD za mln Class B i 0,01 USD za GB retrieval, a free tier nie dotyczy Infrequent Access. Wniosek praktyczny: do małych projektów i typowych uploadów zaczynaj od R2 Standard, a Infrequent Access zostaw dopiero wtedy, gdy naprawdę rozumiesz profil odczytów i minimalny czas przechowywania.

D1 to lekka, serverlessowa baza SQL. Wybierz ją, gdy dane mają relacje: użytkownicy, wpisy, zamówienia, produkty, zgłoszenia, historia formularzy, statusy webhooków. Free daje 5 mln rows read dziennie, 100 000 rows written dziennie i 5 GB storage łącznie. Plan płatny zawiera 25 mld rows read miesięcznie, 50 mln rows written miesięcznie, 5 GB storage, a nadwyżki kosztują 0,001 USD za mln rows read, 1 USD za mln rows written i 0,75 USD za GB-miesiąc.

Tu łatwo o pułapkę. D1 rozlicza odczyty według wierszy przeczytanych, nie tylko zwróconych. Zapytanie po niezindeksowanej kolumnie może zwrócić 10 rekordów, ale przeskanować tysiące. Cloudflare pokazuje wprost, że pełny skan tabeli z 5000 wierszami liczy się jako 5000 rows read. Dlatego przy D1 indeksy nie są optymalizacją „na później”. Są częścią kosztu i stabilności aplikacji.

D1 też nie jest zamiennikiem każdej bazy. Pojedyncza baza ma limit 10 GB, którego nie da się zwiększyć, a pojedyncza baza przetwarza zapytania jednowątkowo, jedno po drugim. Jeżeli projekt ma duże zapisy, rozbudowane transakcje, ciężką analitykę albo jedną wielką bazę o rozmiarze setek gigabajtów, D1 nie powinno być pierwszym wyborem. Wtedy lepiej rozważyć zewnętrznego Postgresa/MySQL i Hyperdrive albo inną architekturę.

Pages zostawiłbym jako frontend. To miejsce na statyczną stronę, landing page, dokumentację, prosty frontend React/Vue/Astro/Svelte. Pages Functions są technicznie blisko Workers, ale rozliczają się jak Workers: requesty do Pages Functions wchodzą w limit Workers Free lub Paid. Statyczne assety na Pages są darmowe i nielimitowane, o ile request nie uruchamia funkcji.

To ważne przy projektowaniu tras. Gdy dodasz Functions do projektu Pages, requesty mogą zacząć wpadać w funkcję, a wtedy przestają być zwykłymi darmowymi requestami do statycznych plików. Cloudflare zaleca kontrolować to przez _routes.json, żeby wykluczyć trasy statyczne i nie płacić funkcją za każdy obrazek, JS czy CSS.

Limity Pages też są konkretne: Free ma 500 buildów miesięcznie, 1 build naraz, timeout buildu po 20 minutach, do 20 000 plików w projekcie i maksymalny rozmiar pojedynczego assetu 25 MiB. Większe pliki Cloudflare sugeruje przenieść do R2.

Najprostsza mapa decyzji:

• Potrzebujesz endpointu /api/*? Wybierz Worker.
• Potrzebujesz zapisać formularze, leady, rekordy, relacje? Wybierz D1.
• Potrzebujesz trzymać pliki? Wybierz R2.
• Potrzebujesz szybkich odczytów prostych wartości, które rzadko się zmieniają? Wybierz KV.
• Potrzebujesz hostować frontend? Wybierz Pages albo statyczne assety na Workers, a logikę trzymaj w Workers.
• Potrzebujesz cache’ować publiczną odpowiedź? Użyj Cache API lub nagłówków cache.
• Potrzebujesz klasycznego, długiego procesu Node.js? Nie wybieraj Workers jako jedynego backendu.

Najzdrowsza architektura dla małej aplikacji wygląda często tak: Pages jako frontend, Worker jako API, D1 jako baza prostych danych, R2 jako storage plików, KV jako szybka konfiguracja lub mapa slugów, a Cache API dla publicznych odpowiedzi, które można bezpiecznie odświeżać po czasie. To nie dubluje tematu „Gdzie hostować Next.js?”, bo tutaj decyzja nie dotyczy hostingu całego frameworka, tylko małej warstwy backendowej dla strony lub aplikacji.

Granica opłacalności pojawia się wtedy, gdy Worker przestaje być cienką warstwą. Jeżeli w jednym requestcie dzieje się autoryzacja, kilka zapytań SQL, kilka fetchy, transformacja dużego JSON-a, zapis plików i generowanie raportu, projekt prosi się o rozbicie. Najpierw usuń ciężką pracę z requestu. Potem dodaj kolejkę albo osobny proces. Dopiero potem myśl o przenoszeniu wszystkiego na większy backend.

FAQ: najczęstsze pytania o Cloudflare Workers

Czy Cloudflare Workers jest naprawdę darmowy?
Tak, ale tylko w ramach limitów. Free daje 100 000 requestów dziennie i 10 ms CPU na wywołanie; po przekroczeniu dziennego limitu requestów Cloudflare może zwrócić błąd 1027.

Czy Workers zastąpi klasyczny backend Node.js?
Nie w każdym projekcie. Workers dobrze obsługują lekkie API, webhooki, proxy i logikę edge, ale nie są klasycznym procesem Node.js. Część API Node działa po włączeniu nodejs_compat, część jest obsługiwana częściowo, a część bibliotek nie pasuje do runtime Cloudflare.

Czy mogę użyć Workers do formularza kontaktowego?
Tak. To jedno z najlepszych zastosowań. Trzeba jednak dodać walidację, ochronę przed spamem, ograniczenie metod, sekrety poza kodem i sensowną obsługę błędów.

Czy KV nadaje się do bazy danych użytkowników?
Tylko dla prostych, rzadko zmienianych danych. KV jest świetne do szybkich odczytów, ale działa w modelu eventual consistency, więc nie nadaje się do danych wymagających natychmiastowej spójności po zapisie.

Kiedy wybrać D1 zamiast KV?
Gdy dane mają strukturę relacyjną i chcesz używać SQL: formularze, zgłoszenia, użytkownicy, produkty, statusy webhooków. Przy D1 od razu projektuj indeksy, bo koszty i limity zależą od liczby przeczytanych oraz zapisanych wierszy.

Kiedy wybrać R2?
Gdy pojawiają się pliki: obrazy, dokumenty, eksporty, backupy, assety większe niż limit Pages. Free tier R2 Standard obejmuje 10 GB-month, 1 mln operacji Class A, 10 mln operacji Class B i darmowy egress miesięcznie.

Czy Cloudflare Pages wystarczy do backendu?
Pages jest najlepsze jako frontend. Logikę backendową lepiej świadomie wydzielić do Workers albo Pages Functions, pamiętając, że requesty do Functions liczą się jak requesty Workers.

Od czego zacząć w małej aplikacji?
Najpierw zrób jeden Worker z jednym endpointem, na przykład formularzem lub proxy. Potem dodaj D1 tylko wtedy, gdy trzeba zapisywać rekordy, R2 tylko wtedy, gdy pojawią się pliki, i KV tylko dla danych często czytanych oraz rzadko zmienianych. Najgorszy pierwszy krok to budowanie całej „platformy” zanim istnieje pierwszy prawdziwy request.