← Všechny produkty

Workers

Cloudflare Workers spouští kód zákazníků v V8 isolates v síti Cloudflare a využívá bindings k úložištím, databázím, frontám a inferenčním službám. Tato stránka popisuje model spouštění, model bindings, limity platformy, které omezují návrh, a zveřejněné ceny.

Řízení dokumentu

Dana
Technická redaktorka, Integrity Czech Republic s.r.o.

Přehled

Workers je bezserverová výpočetní platforma Cloudflare. Kód se nasazuje do sítě, nikoli do konkrétního regionu, a volání zpracovává datové centrum, které požadavek přijalo. Nemusíte řešit velikost instancí ani opravovat runtime, platforma ale stanovuje jasné limity pro CPU, paměť, počet subrequestů a velikost skriptu, které určují, co na ní lze postavit. Tyto limity jsou popsané v sekci Limits and constraints a měli byste si je přečíst před návrhem řešení, ne až po něm.

Běžné jsou dva způsoby použití. První umísťuje Worker před stávající origin server a řeší směrování, úpravu hlaviček, autentizaci, personalizaci nebo logiku ukládání do mezipaměti, přičemž aplikace zůstává na svém místě. Druhý staví aplikaci zcela na platformě a využívá její úložné a databázové služby bez klasického origin serveru.

O škálování se stará platforma v tom smyslu, že se pro jednotlivá nasazení neprovádí žádné vyhrazování kapacity. To ale neznamená neomezené škálování: platí limity na CPU čas, paměť a počet subrequestů na jedno vyvolání i limity na úrovni jednotlivých služeb a existují také kontroly souběžnosti na úrovni účtu. Navrhujte řešení podle zdokumentovaných limitů, ne podle předpokladu neomezené škálovatelnosti.

Architektura

Worker běží ve V8 izolátu, nikoli v kontejneru nebo virtuálním stroji. Izolát je izolovaný kontext pro spouštění JavaScriptu, přičemž jeden proces hostí mnoho izolátů najednou a spuštění nového izolátu je podstatně levnější než spuštění kontejnerového obrazu. To je základ jak rychlosti startu platformy, tak ekonomiky nasazování stejného kódu do všech lokalit.

Spuštění není ve všech případech zdarma. Doba studeného startu závisí na velikosti skriptu, na množství práce prováděné na úrovni modulu a na tom, zda je nutné vytvořit instanci modulu WebAssembly. Velké balíčky a náročná inicializace vedou k měřitelným studeným startům.

Prostředí pro spouštění implementuje webová platformní API: fetch, Request a Response, URL, Web Crypto, streamy, WebSocket a podmnožinu API Node.js povolenou prostřednictvím nodejs_compat příznak kompatibility. Chování za běhu je zafixováno datem kompatibility a příznaky kompatibility deklarovanými v konfiguraci Workeru, a právě tímto způsobem platforma zavádí změny chování, aniž by narušila již nasazený kód.

Bindings propojují Worker se zdroji platformy. Binding se deklaruje v konfiguraci a za běhu se vloží do objektu prostředí, takže KV namespace, R2 bucket, D1 databáze, queue, Durable Object namespace, AI model nebo jiný Worker se adresují jako schopnost, nikoli prostřednictvím connection stringu nebo vloženého přihlašovacího údaje.

Nasazení přes Wrangler CLI publikuje novou verzi. Postupná nasazení směrují na novou verzi nakonfigurované procento provozu, což znamená, že během postupného nasazení běží současně dvě verze. Nasazení proto v tomto režimu není atomické a kód musí zvládnout provoz obou verzí nad stejnými daty.

V rámci zpracování požadavku Cloudflare probíhají bezpečnostní fáze ještě před spuštěním Workeru, takže požadavek zablokovaný WAF nebo pravidlem DDoS se ke kódu Workeru vůbec nedostane.

Možnosti

Model konfigurace

Worker je definován svým kódem a konfiguračním souborem, wrangler.jsonc nebo wrangler.toml. Konfigurace deklaruje:

• Vstupní bod a nastavení sestavení. Vstupní bod modulu a případný krok sestavení.
• Datum kompatibility a příznaky. Chování runtime prostředí, pro které byl kód napsán. Změna data kompatibility je záměrný krok s pozorovatelnými dopady a měla by být posouzena jako změna kódu.
• Bindings. KV namespaces, R2 buckets, D1 databáze, Durable Object namespaces, queues, service bindings na jiné Workery, AI bindings a obyčejné proměnné prostředí.
• Secrets. Uchovává se mimo konfigurační soubor, nastavuje se přes Wrangler nebo dashboard a za běhu je zpřístupněno v objektu prostředí.
• Triggery. Trasy a vlastní domény pro spuštění přes HTTP, cron výrazy pro plánované spouštění a deklarace queue consumerů.
• Prostředí. Pojmenované varianty konfigurace pro staging a produkci, každá s vlastními bindings a secrets.
• Limity. Tam, kde je to podporováno, explicitní limit CPU pro Worker.

Volba úložiště je hlavním architektonickým rozhodnutím a řídí se požadovanou konzistencí a vzorem přístupu: KV pro časté čtení dat, u kterých stačí eventuální konzistence, D1 pro relační dotazy, R2 pro objekty, Durable Objects tam, kde je potřeba silná konzistence nebo koordinace na úrovni jednotlivé entity, a Queues tam, kde má být zpracování odděleno od požadavku.

Konfiguraci uchovávejte ve verzovacím systému spolu s kódem, protože vazby a nastavení kompatibility ovlivňují chování za běhu stejnou měrou jako samotný zdrojový kód.

Limity a omezení

Níže uvedené hodnoty pocházejí z dokumentace limitů platformy Cloudflare, ověřeno 2026-08-31 (https://developers.cloudflare.com/workers/platform/limits/). Mění se bez upozornění, a než na nich návrh začne záviset, měly by se znovu ověřit.

Subrequest je jakýkoli požadavek, který Worker odešle přes Fetch API nebo na službu Cloudflare přes binding, takže volání fetch i volání přes binding čerpají ze stejného rozpočtu na jedno vyvolání.

Omezení služby úložiště, staženo 2026-08-28:

• Workers KV. Velikost klíče 512 bajtů, velikost hodnoty 25 MiB a zdokumentovaný limit přibližně jednoho zápisu za sekundu na stejný klíč. KV je eventuálně konzistentní: zápis nemusí být okamžitě viditelný při čtení v jiné lokalitě.
• R2. Nad limitem velikosti objektu pro jeden požadavek je vyžadován multipart upload a platí omezení velikosti jednotlivých částí. Odchozí provoz do internetu se neúčtuje, operace se účtují podle třídy.
• D1. Platí maximální velikost databáze a omezení na jednotlivý dotaz. Databáze D1 není náhradou za horizontálně škálovaný relační cluster; před plánováním objemu dat si ověřte aktuální maximum.
• Durable Objects. Objekt je jednovláknový, propustnost na jeden objekt je proto omezená a vzorům hot-key je nutné se vyhnout již při návrhu. Platí limity úložiště na jeden objekt, které se liší mezi key-value a SQLite backendem.

Další omezení:

• Python Workers jsou v otevřené beta verzi a vyžadují python_workers příznak kompatibility. Plánování produkční úlohy na nich znamená přijmout jejich beta status a možnost změny chování.
• Čas CPU měří dobu strávenou prováděním kódu, nikoli reálný čas. Čekání na subrequest čas CPU nespotřebovává, ale celková doba trvání požadavku i tak podléhá časovým limitům HTTP a chování klienta.
• Cold starts nejsou zcela odstraněny. Velké bundly, rozsáhlá inicializace na úrovni modulu a instanciace WebAssembly prodlužují dobu spuštění o měřitelnou hodnotu.
• Gradual Deployments spouštějí dvě verze současně, proto musí být změny schématu a formátu dat po celou dobu postupného nasazování zpětně kompatibilní.
• Kompatibilita s Node.js je částečná a závisí na nodejs_compat příznak a datum kompatibility. Knihovny vyžadující nepodporovaná Node.js API, nativní moduly nebo dlouhotrvající syrová TCP spojení nemusí fungovat.
• Existují limity souběžnosti a rychlosti na úrovni účtu. Pokud zátěž očekává extrémní nárazovou souběžnost, je potřeba si to ověřit podle smlouvy, nikoli to jen předpokládat.

Dostupnost podle tarifu

Nasazení

Předpoklady.

• Určete kandidátskou zátěž a zařaďte ji do kategorie: edge logika před stávajícím origin serverem, API, plánovaná úloha nebo celá aplikace.
• Zátěž namapujte na primitiva platformy a u každé části stavu zaznamenejte požadavek na konzistenci, protože právě ten určuje volbu úložiště.
• Před psaním kódu porovnejte zátěž s dokumentovanými limity: špičkové využití CPU na požadavek, špičková paměť, počet odchozích volání na požadavek, velikost bundlu a případné závislosti vyžadující nepodporované Node.js API.
• Ověřte runtime prostředí. Pokud je navržen Python, zaznamenejte, že Python Workers jsou v otevřené beta verzi, a získejte rozhodnutí o přijetí tohoto stavu.
• Zaznamenejte, kde se aktuálně nacházejí secrets a jak budou dodány jako Worker secrets.
• Zaznamenejte aktuální cestu provozu a cestu zpět pro rollback.

Postupné ověřování. Implementujte zátěž proti staging prostředí s vlastními bindings a vlastními daty a otestujte ji na reprezentativním provozu. Měřte čas CPU na jedno volání, využití paměti a počet subrequestů vůči limitům dané úrovně a chování cold startu měřte na produkční velikosti balíčku, nikoli na zmenšené verzi. Před nasměrováním jakéhokoli produkčního provozu ověřte, že výstup observability dorazí na zamýšlené místo určení.

Konfigurace.

1. Deklarujte bindings a explicitně nastavte datum kompatibility. Nespoléhejte na výchozí hodnotu.
2. Přesuňte všechny přihlašovací údaje do Worker secrets a ověřte, že žádné nezůstaly v repozitáři ani v konfiguračním souboru.
3. Nakonfigurujte oddělená staging a produkční prostředí s odlišnými úložnými prostředky, aby chyba při nasazení nemohla zapsat do produkčních dat.
4. Nastavte CI tak, aby nasazení prováděl pipeline pomocí omezeného API tokenu, a ne z pracovní stanice vývojáře.
5. Před veřejně dostupné trasy Workeru zařaďte omezování počtu požadavků a tam, kde to odpověď dovoluje, přidejte cachování, aby byl objem požadavků, a tedy i náklady, omezený.
6. Namodelujte náklady podle očekávaného provozu pomocí cenových stránek jednotlivých služeb, včetně tříd operací úložiště, a nastavte upozornění na fakturaci.

Přepnutí provozu. Provoz do produkce směrujte postupně pomocí postupných nasazení (gradual deployments) nebo trasy pokrývající podmnožinu cest. Protože při postupném nasazení běží obě verze současně, ověřte, že nová verze je kompatibilní s daty zapsanými předchozí verzí a s daty, která bude předchozí verze zapisovat i během tohoto přechodu.

Ověření.

• Před navýšením podílu provozu ověřte, že chybovost a latence při každém procentu provozu odpovídají zaznamenané výchozí hodnotě (baseline).
• Ověřte, že doba CPU na jedno volání zůstává v rámci nastaveného limitu při produkčním mixu provozu, protože překročení limitu pod zátěží se projevuje jako přerušované selhání.
• Ověřte, že se logy a metriky vytvářejí a uchovávají podle očekávání.
• Ověřte, že operace s úložištěm odpovídají očekávanému objemu, protože v mnoha návrzích náklady určuje spíše počet operací než počet požadavků.
• Ověřte, že předchozí cesta stále funguje, aby byl k dispozici rollback.

Vrácení změn. Vraťte provoz na předchozí verzi pomocí rozhraní pro nasazení, nebo odstraňte trasu, aby požadavky směřovaly přímo na origin. Předchozí verzi ponechte nasazenou, dokud nová verze neprojde celým cyklem provozu, místo abyste ji hned odstranili. Pokud se změnilo schéma nebo formát dat, před vrácením zpět ověřte, že předchozí verze dokáže přečíst data zapsaná novou verzí.

Provozní hlediska

Měřte čas CPU, chybovost a počet subrequestů podle jednotlivých tras, nejen celkový objem požadavků. Chyby související s limity se projeví až při zátěži a v testovacím prostředí s nízkým provozem zůstávají neviditelné.

Datum kompatibility průběžně kontrolujte. Pokud jej ponecháte natrvalo beze změny, Worker poběží podle stále staršího chování runtime; jeho posunutí bez otestování změní chování. Každý posun berte jako změnu, která vyžaduje vlastní ověření.

Sledujte počty operací s úložištěm spolu s počty požadavků. Návrh, který provádí několik operací KV nebo D1 na jeden požadavek, má nákladový profil určovaný právě těmito operacemi, a změna cachování tak může výslednou fakturu výrazně změnit oběma směry.

Rotujte tajné klíče Workeru podle plánu a uchovávejte je pouze v platformním úložišti tajných klíčů. Protože bindings nahrazují connection stringy, uniklý tajný klíč bývá obvykle přihlašovacím údajem aplikace, nikoli platformy, ale povinnost rotace zůstává stejná.

Navrhněte klíče Durable Object tak, aby se zátěž rozložila mezi jednotlivé objekty. Pokud jeden objekt zpracovává nepřiměřeně velký podíl provozu, stává se stropem propustnosti, který žádné škálování platformy nevyřeší.

Režimy selhání, se kterými je třeba počítat: aktualizace závislosti, která posune balíček nad limit velikosti, cesta v kódu, jež u velkých vstupů občas překročí limit CPU, kolize při zápisu do KV na jediném klíči, upstream služba natolik pomalá, že drží subrequesty otevřené, a postupné nasazení ponechané částečně rozpracované.

Známá úskalí

• Python Workers jsou v otevřené beta verzi a vyžadují compatibility flag. Uvedete-li je vedle obecně dostupných runtime prostředí bez tohoto upřesnění, architekt může omylem naplánovat nasazení do produkce na beta runtime.
• Platforma nemá neomezenou kapacitu. To, co dokáže jedno volání, omezují čas CPU, paměť, velikost balíčku, subrequesty a kvóty pro jednotlivé služby.
• Cold starts existují. U kompaktních JavaScript bundlů jsou malé, u velkých bundlů a instanciace WebAssembly jsou větší.
• Funkce Gradual Deployments není záměrně atomická. Současně běží dvě verze, což je požadavek na kompatibilitu dat, nikoli pouhý detail.
• KV je eventuálně konzistentní a má limit zápisů na jeden klíč. Jeho použití jako primárního úložiště pro rychle se měnící stav způsobuje problémy se správností, které se projeví až při souběžném přístupu.
• Durable Object je jednovláknový. Propustnost na jeden objekt je omezena záměrně, nikoli úrovní účtu.
• Kompatibilita s Node.js je částečná. Strom závislostí, který se lokálně sestaví bez problémů, může za běhu selhat na nepodporovaném API.
• Přenositelnost je částečná. Standardní webová API, rozhraní R2 API kompatibilní s S3 a dialekt SQLite v D1 umožňují přenést velkou část logiky aplikace, zatímco Durable Objects a další služby specifické pro platformu by při přesunu vyžadovaly změnu architektury. Při návrhu si poznamenejte, do které kategorie jednotlivé komponenty patří.

Interoperabilita

Workers se spouští až po bezpečnostních fázích zpracování požadavků v Cloudflare, takže rozhodnutí WAF, DDoS a Bot Management se uplatní ještě předtím, než se spustí kód Workeru. Blokovaný požadavek se k Workeru vůbec nedostane.

Workers komunikují s CDN prostřednictvím Cache API a Cache Rules. Pokud na stejný požadavek působí zároveň Cache Rule i logika mezipaměti Workeru, přednost určuje zdokumentované pořadí zpracování provozu.

R2 může fungovat jako origin pro CDN a je základem Cache Reserve, takže objektové úložiště, cachování a výpočetní služby fungují společně bez tradičního origin serveru.

Service bindings umožňují jednomu Workeru vyvolat druhý bez zpáteční síťové cesty, což umožňuje rozdělit aplikaci na samostatně nasazované jednotky a zároveň udržet nízkou latenci volání.

Ověření Turnstile lze provádět z Workeru, což umožňuje ověřování výzvy na edge namísto v backendu aplikace.

Access je možné umístit před trasu Workeru tak, aby byly požadavky před vyvoláním ověřeny a autorizovány, aniž by Worker musel autentizaci implementovat sám.

Časté dotazy

Je pro přechod na Workers nutná migrace celé aplikace? Ne. Běžný způsob zavedení umístí Worker na route před stávající origin server, aby řešil přesměrování, logiku cache, autentizaci nebo personalizaci, zatímco aplikace zůstává tam, kde je. Migrace samotné aplikace je samostatné rozhodnutí.

Co vlastně limit CPU měří? Čas strávený prováděním kódu, nikoli celková doba trvání požadavku. Čekání na subrequest nespotřebovává čas CPU, takže požadavek může trvat déle než limit CPU, aniž by ho překročil.

Která úložná služba by měla uchovávat stav relace nebo koordinace? Durable Objects, pokud je vyžadována silná konzistence nebo koordinace na úrovni jednotlivých entit. KV je eventuálně konzistentní a má omezenou rychlost požadavků na jeden klíč, což jej činí nevhodným pro rychle se měnící stav jednoho klíče.

Které části aplikace Workers lze přenést na jinou platformu? Kód napsaný proti standardním webovým API, data v R2 přes S3 kompatibilní API a schémata a dotazy D1 v dialektu SQLite jsou z velké části přenositelné. Durable Objects a další služby specifické pro platformu vyžadují změnu architektury.

Zdroje

• https://developers.cloudflare.com/workers/, staženo 2026-08-28.
• https://developers.cloudflare.com/workers/platform/limits/, staženo 2026-08-28.
• https://developers.cloudflare.com/workers/platform/pricing/, staženo 2026-08-28.
• https://developers.cloudflare.com/workers/languages/python/, staženo 2026-08-28.
• https://developers.cloudflare.com/workers/configuration/compatibility-dates/, staženo 2026-08-28.
• https://developers.cloudflare.com/workers/configuration/versions-and-deployments/gradual-deployments/, staženo 2026-08-28.
• https://developers.cloudflare.com/kv/, staženo 2026-08-28.
• https://developers.cloudflare.com/r2/, staženo 2026-08-28.
• https://developers.cloudflare.com/d1/, staženo 2026-08-28.
• https://developers.cloudflare.com/durable-objects/, staženo 2026-08-28.

Snímek obsahu: 2026-08-28.

Changelog