Cloudflare Workers dla biznesu 2026: praktyczny poradnik
Jeśli masz stronę na Cloudflare CDN – jesteś jeden klik od potężnego narzędzia, którego wielu nie używa. Cloudflare Workers to kod, który wykonuje się w ponad 330 lokalizacjach edge na całym świecie, bez własnego serwera. W tym artykule – czym to jest, 5 typowych zastosowań w biznesie, porównanie z AWS Lambda i Vercel, oraz typowe błędy.
Czym są Workers i ekosystem
Cloudflare Workers to serverless edge compute. Piszesz funkcję w JavaScript/TypeScript (lub Rust/Python przez Pyodide), wdrażasz przez CLI lub git, i natychmiast działa w ponad 330 miastach na świecie – Cloudflare sam rozmieszcza ją na najbliższym użytkownikowi serwerze.
lokalizacji edge na świecie do wdrażania kodu
zapytań za darmo na planie free
typowy czas odpowiedzi Workera
plan paid: 10 mln zapytań miesięcznie
Główna różnica względem klasycznych chmur: kod wykonuje się w tej samej sieci co CDN. Nie ma pojęcia „instancja", „region", „dostępność". Zimnego startu praktycznie nie ma – V8 isolate startuje w 5ms.
Wokół Workers Cloudflare zbudował cały ekosystem usług:
- KV (Key-Value) – rozproszony storage dla cache, sesji, feature flag. Za darmo do 100K odczytów dziennie.
- R2 (Object Storage) – storage zgodny z S3 dla plików. Główna zaleta: darmowy egress (w AWS S3 płacisz za każdy oddany bajt).
- D1 (SQL Database) – SQLite na edge. 5 USD/mies za 10GB. Nadaje się do większości aplikacji webowych do 10M zapytań.
- Durable Objects – obiekty ze spójnym stanem. Do pokoi czatu, kolejek, aplikacji WebSocket.
- Queues – kolejki wiadomości do asynchronicznego przetwarzania.
- Workers AI – uruchamianie modeli open-source (Llama, Mistral, embeddings) bezpośrednio na edge. Bez przesyłania danych do osób trzecich.
- Hyperdrive – przyspieszone połączenie z zewnętrznymi PostgreSQL/MySQL/MongoDB.
5 zastosowań dla biznesu
1. Bot Telegram bez własnego serwera
Najczęstszy use-case. Bot Telegram przez webhook to endpoint HTTP, który przyjmuje zapytania POST. Worker świetnie sobie z tym radzi. Stan sesji – w KV (darmowe 100K odczytów/dzień). Integracje z CRM lub OpenAI – przez fetch do ich API. Żadnego VPS, żadnego PM2 czy systemd – wdrożyłeś i zapomniałeś.
2. Obsługa formularzy ze strony
Formularz zgłoszeniowy na statycznym landingu → Worker → wysyłka do czatu Telegram menedżera / e-mail / CRM. Ochrona przed spamem (honeypot, rate-limit) – kilka linijek w Workerze. Jeden Worker może obsługiwać formularze 10 stron równolegle. Plan free starcza z nawiązką dla średniego biznesu.
3. Proxy AI dla bezpieczeństwa kluczy API
Chcesz dać użytkownikom dostęp do ChatGPT/Claude przez własny UI? Bezpośrednio z przeglądarki nie można odwoływać się do OpenAI/Anthropic – klucz API wycieknie. Worker jako proxy: front odwołuje się do Workera, Worker dodaje klucz API ze zmiennych środowiskowych i wywołuje OpenAI. Klucz nigdy nie opuszcza serwera.
4. Optymalizacja obrazów on-the-fly
Cloudflare Images albo własny Worker z biblioteką Polish: optymalizacja obrazków „w locie". Wgrywasz oryginał do R2, Worker robi resize, konwersję do WebP/AVIF, nakładanie znaku wodnego – po parametrach URL. PageSpeed +20-30 punktów na stronach z dużą liczbą obrazków.
5. Geo-routing i testy A/B
Worker widzi kraj, region i język przeglądarki użytkownika. Można kierować Rosjan na `tema.name/`, Niemców na `/de/`, Polaków na `/pl/`. Analogicznie dla testów A/B: różne wersje stron bez osobnej usługi. Wszystkie „eksperyment = druga strona" obsługiwane są na edge, zanim dotrą do origin.
Porównanie z alternatywami
| Parametr | Cloudflare Workers | AWS Lambda | Vercel Functions |
|---|---|---|---|
| Regiony | 330+ lokalizacji edge | Jeden region (wybierasz ręcznie) | Edge + regiony |
| Zimny start | ~5ms | 200-2000ms (Node.js), gorzej w Javie | 50-300ms |
| Języki | JS/TS/Rust/Python (Pyodide) | Node.js/Python/Go/Java/Ruby/.NET | JS/TS, Python |
| Plan free | 100K zapytań/dzień | 1M zapytań/miesiąc | 100K zapytań/mies |
| Koszt 10M zapytań | 5 USD/mies | ~20 USD/mies + GB-seconds | ~20 USD/mies |
| Vendor lock-in | Ekosystem Cloudflare | Ekosystem AWS (S3, DynamoDB...) | Vercel + nacisk na Next.js |
| Idle to first request | Natychmiast | Do 2 sekund (cold start) | Do 300ms |
Moje rekomendacje:
- Jeśli już używasz Cloudflare – Workers są „darmowym rozszerzeniem" tego, za co już płacisz. Mniej rachunków, mniej dostawców.
- Jeśli masz intensywny stack AWS (RDS, DynamoDB, SQS) – Lambda jest wygodniejsza, wszystko w jednym VPC.
- Jeśli front na Next.js / Nuxt / Astro na Vercel – Vercel Functions są wygodniejsze, kod serwerowy w tym samym repo.
- Jeśli globalna grupa odbiorców – Workers wygrywają dzięki lokalizacjom edge (CDN umieszcza kod w najbliższym użytkownikowi DC).
Uruchomienie pierwszego Workera w godzinę
Realistyczny harmonogram uruchomienia pierwszego produkcyjnego Workera od zera:
- Setup10 min
- Kod15 min
- Deploy5 min
- Routes10 min
- Testy20 min
Setup (10 min). Rejestracja konta Cloudflare (jeśli nie ma), instalacja CLI `wrangler` (`npm install -g wrangler`), `wrangler login` – otworzy przeglądarkę do autoryzacji. Na tym etapie masz już działające środowisko.
Kod (15 min). `wrangler init my-worker` tworzy szablon. Podstawowy Worker to 10 linii kodu w TypeScript: przyjmuje zapytanie HTTP, zwraca Response. Dla bota Telegram dodajesz obsługę JSON i wywołanie Telegram API przez fetch.
Deploy (5 min). `wrangler deploy` – Worker jest od razu dostępny pod `*.workers.dev`. Logi przez `wrangler tail`. Bez Dockera, bez CI/CD, bez Kubernetesa.
Routes (10 min). Jeśli masz już domenę na Cloudflare – w panelu Workers dodajesz Route: `api.yourdomain.com/*` → twój Worker. Od tego momentu zapytania na ten URL trafią do Workera.
Testy (20 min). Lokalne testowanie `wrangler dev`. Podłączasz KV/D1/R2 przez bindings w `wrangler.toml`. Edge cases: co zwróci Worker przy pustym zapytaniu, ogromnym, zapytaniu z uszkodzonym JSON. Deploy z `wrangler deploy --env production`.
7 typowych błędów
Te grabie widziałem u klientów i sam na nie nadepnąłem.
- Trzymanie stanu w zmiennej globalnej. Worker jest stateless – każde zapytanie może trafić na inny serwer. Stan – w KV/D1/Durable Objects, nie w zmiennej.
- Ignorowanie limitu CPU. 10ms na free, 50ms na paid. Ciężka kryptografia lub duży JSON.parse mogą nie zdążyć. Profiluj przez `wrangler dev --remote`.
- Nieużywanie Wrangler secrets dla kluczy. Wpisać klucz API OpenAI do kodu = wyląduje w git. Używaj `wrangler secret put` – klucz jest przechowywany zaszyfrowany u Cloudflare.
- Synchroniczne operacje na każde zapytanie. Każdy fetch do zewnętrznego API kosztuje czas. Buforuj w KV lub Cache API powtarzające się dane.
- Zapomnienie o nagłówkach Origin. CORS blokuje zapytania z frontu. Worker musi jawnie zwracać `Access-Control-Allow-Origin` – użytkownik nie zobaczy odpowiedzi, jeśli tego nie ma.
- Deploy bez testów. Worker idzie na produkcję natychmiast. Rób osobny environment dla staging: `wrangler deploy --env staging`.
- Brak analytics. W Cloudflare jest darmowy Workers Analytics – zapytania, błędy, latencja po regionach. Bez niego nie wiadomo, co się dzieje.
Częste pytania
Czym są Cloudflare Workers w prostych słowach?
To kod, który wykonuje się na serwerach Cloudflare na całym świecie, blisko użytkownika. Piszesz funkcję w JavaScript/TypeScript, wdrażasz ją, i działa w ponad 330 miastach na świecie. Nie potrzebujesz własnego serwera, Dockera ani PM2. Zimnego startu praktycznie nie ma – odpowiedź w 5-50ms. Nadaje się do API, formularzy, botów Telegram, proxy, autoryzacji, przetwarzania obrazów.
Ile kosztuje Cloudflare Workers?
Plan Free: 100 000 zapytań dziennie za darmo, do 10ms CPU na zapytanie. To wystarcza dla większości projektów do 100K odwiedzin miesięcznie. Plan Paid: 5 USD miesięcznie za 10 milionów zapytań, do 50ms CPU. To wielokrotnie taniej niż AWS Lambda przy tej samej ilości.
Czym Workers różnią się od AWS Lambda?
Lambda działa w jednym regionie AWS, Workers – w ponad 330 lokalizacjach edge. Lambda ma zimny start 200-2000ms, Workers – poniżej 10ms. Lambda: Node.js/Python/Go/Java/Ruby, Workers: JavaScript/TypeScript/Rust/Python (przez Pyodide). Dla globalnych API i aplikacji webowych Workers są szybsze i prostsze, dla ciężkich zadań (przetwarzanie wideo, inferencja ML) – Lambda jest bardziej elastyczna.
Czy można podłączyć bazę danych do Workers?
Tak. Cloudflare ma własne usługi: D1 (SQLite na edge, 5 USD/mies za 10GB), KV (key-value, dla cache i sesji), R2 (storage zgodny z S3 bez opłat za egress), Durable Objects (spójność stanu). Można też podłączyć zewnętrzne bazy przez Hyperdrive (przyspieszony PostgreSQL) lub bezpośrednio przez connection API.
Czy Workers nadają się do bota Telegram?
Idealnie się nadają. Bot Telegram przez webhook to endpoint HTTP, który przyjmuje zapytania z Telegram API. Workers radzą sobie z takim obciążeniem nawet na planie free do 100K wiadomości dziennie. Stan sesji można trzymać w KV (darmowe 100K odczytów/dzień), integracje z CRM/OpenAI – przez fetch do ich API. Żaden VPS nie jest potrzebny.
Potrzebujesz bota Telegram lub API na Workers?
Zaprojektuję i wdrożę pod twoje zadanie: bot, formularz, proxy AI, image-optimizer. Bezpłatny briefing techniczny w ciągu 24 godzin.