← 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. Popisuje je sekce Limity a omezení; přečtěte si ji 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 cachování a aplikace přitom zůstává, kde je. Druhý staví aplikaci zcela na platformě a využívá její úložné a databázové služby bez klasického origin serveru.

Škálování řeší platforma v tom smyslu, že pro jednotlivá nasazení nevyhrazujete kapacitu. To ale neznamená neomezené škálování: platí limity na CPU čas, paměť a počet subrequestů na jedno volá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. Na tom stojí rychlý start platformy i to, že se vyplatí nasazovat stejný kód do všech lokalit.

Spuštění není ve všech případech zdarma. Doba cold 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 cold start měřitelně prodlužují.

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, kterou zapíná příznak kompatibility nodejs_compat. Chování runtime určuje datum kompatibility a příznaky kompatibility v konfiguraci Workeru. Právě takto platforma zavádí změny chování, aniž by rozbila už 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 tvoří kód a konfigurační soubor, 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 viditelnými dopady; posuzujte ji jako změnu 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. Ukládají se mimo konfigurační soubor, nastavují se přes Wrangler nebo dashboard a za běhu jsou dostupné 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 bindings 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í, proto je před návrhem znovu ověřte.

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 volání.

Limity úložišť (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. Objekty nad limitem pro jeden požadavek vyžadují multipart upload a platí limity 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. D1 nenahrazuje 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í příznak kompatibility python_workers. Kdo na nich plánuje produkční úlohu, přijímá jejich beta status i možné 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 starty úplně nezmizely. Velké bundly, rozsáhlá inicializace na úrovni modulu a instanciace WebAssembly spuštění měřitelně prodlužují.
• 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 příznaku nodejs_compat a datu 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 čekáte extrémní nárazovou souběžnost, ověřte si ji ve smlouvě, nepředpokládejte ji.

Dostupnost podle tarifu

Nasazení

Předpoklady.

• Určete úlohu, kterou chcete na Workers provozovat, a zařaďte ji do kategorie: edge logika před stávajícím origin serverem, API, plánovaná úloha nebo celá aplikace.
• Úlohu 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 úlohu 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 návrh počítá s Pythonem, poznamenejte si, že Python Workers jsou v otevřené beta verzi, a nechte si schválit, že tento stav přijímáte.
• 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í. Úlohu nejdřív nasaďte do stagingu s vlastními bindings a 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. Než pustíte jakýkoli produkční provoz, ověřte, že výstup observability dochází tam, kam má.

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. Nastavte oddělená prostředí pro staging a produkci, každé s vlastními úložišti, aby chyba při nasazení nemohla zapsat do produkčních dat.
4. Nastavte CI tak, aby nasazovala pipeline s omezeným API tokenem, ne vývojář ze své pracovní stanice.
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 převádějte postupně, pomocí gradual deployments nebo trasy, která pokrývá jen část 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 projeví jako občasná 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. Pokud se změnilo schéma nebo formát dat, před vrácením 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ů. U návrhu s několika operacemi KV nebo D1 na jeden požadavek určují náklady hlavně tyto operace a změna cachování může fakturu výrazně posunout 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á 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í příznak kompatibility. Kdo je bere jako rovnocenné s obecně dostupnými runtime, může omylem naplánovat produkční nasazení 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 starty existují. U kompaktních JavaScriptových bundlů jsou krátké, u velkých bundlů a při instanciaci WebAssembly delší.
• Gradual Deployments záměrně nejsou atomické. Současně běží dvě verze, takže data musí být kompatibilní s oběma.
• KV je eventuálně konzistentní a má limit zápisů na jeden klíč. Pokud ho použijete jako primární úložiště rychle se měnícího stavu, vzniknou chyby, 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í se 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ějí 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.

Přes service bindings může jeden Worker volat druhý bez síťového round tripu. Aplikaci tak lze rozdělit na samostatně nasazované části a latence volání mezi nimi zůstane nízká.

Token Turnstile lze ověřit přímo ve Workeru, tedy na edge, a ne až v backendu aplikace.

Před trasu Workeru lze předřadit Access: požadavky se ověří a autorizují ještě před voláním Workeru, který pak autentizaci nemusí řešit sám.

Časté dotazy

Je pro přechod na Workers nutná migrace celé aplikace? Ne. Obvykle se Worker umístí na trasu (route) před stávající origin server a řeší 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.

Kam ukládat stav relace nebo koordinace? Do Durable Objects, pokud potřebujete silnou konzistenci nebo koordinaci na úrovni jednotlivých entit. KV je eventuálně konzistentní a má omezenou rychlost požadavků na jeden klíč, takže se na rychle se měnící stav jednoho klíče nehodí.

Které části aplikace Workers lze přenést na jinou platformu? Kód, který používá standardní webová API, data v R2 přes API kompatibilní se S3 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