Products · Developer platform

Dynamic Workers

Spin up isolated Workers on demand to execute code

Pricing and limits

Pricing

as of Nov 3, 2026

As of Nov 3, 2026, from Cloudflare's docs, last updated there Jun 11, 2026. Licensed CC BY 4.0; navigation removed.

Dynamic Workers pricing is based on three dimensions: Dynamic Workers created daily, requests, and CPU time.

Dynamic Workers are currently only available on the Workers Paid plan.

Included Additional usage
Dynamic Workers created daily 1,000 unique Dynamic Workers per month +$0.002 per Dynamic Worker per day
Requests ¹ 10 million per month +$0.30 per million requests
CPU time ¹ 30 million CPU milliseconds per month +$0.02 per million CPU milliseconds

¹ Uses Workers Standard rates and will appear as part of your existing Workers bill, not as separate Dynamic Workers charges.

Billing

Starting May 26, 2026, Dynamic Workers created daily are billed as part of Dynamic Workers pricing.

Dynamic Workers requests and CPU time are also billed as part of your Workers plan. They count toward your Workers requests and CPU usage.

Dynamic Workers created daily

You are billed for each unique Dynamic Worker created in a day. A Dynamic Worker is uniquely identified by its Worker ID and code — if either changes, it counts as a new Dynamic Worker. The count resets daily.

Scenario Counted as
Same code, same ID, invoked multiple times 1 Dynamic Worker
Same code, different IDs 1 Dynamic Worker per ID
Same ID, different code versions 1 Dynamic Worker per code version
No ID provided or .load(code) used 1 Dynamic Worker per invocation

Note

If your application sends multiple requests to the same Worker, use .get() with a stable ID to avoid being billed for multiple creations.

View Dynamic Workers usage

To view the number of billable Dynamic Workers invoked during your billing period, go to Workers & Pages > Overview in the Cloudflare dashboard ↗︎.

Dynamic Workers usage data only goes back to June 1, 2026.

You can also query this count through the GraphQL Analytics API by using workersInvocationsByOwnerAndScriptGroups and selecting distinctDynamicWorkerCount:

query getDynamicWorkersCount(
	$accountTag: string!
	$filter: AccountWorkersInvocationsByOwnerAndScriptGroupsFilter_InputObject
) {
	viewer {
		accounts(filter: { accountTag: $accountTag }) {
			workersInvocationsByOwnerAndScriptGroups(limit: 10000, filter: $filter) {
				uniq {
					distinctDynamicWorkerCount
				}
			}
		}
	}
}

Use variables to set the account and billing-period date range:

{
	"accountTag": "<ACCOUNT_ID>",
	"filter": {
		"date_geq": "2026-06-01",
		"date_leq": "2026-06-30"
	}
}

The distinctDynamicWorkerCount field returns the unique Dynamic Workers count for the selected period.

Requests

Dynamic Workers reuse Workers Standard request pricing.

A request is counted each time a Dynamic Worker is invoked:

  • Each fetch() call into a Dynamic Worker
  • Each RPC method call on a Dynamic Worker stub (billed the same way as Durable Objects)

If an RPC method returns a stub (an object that extends RpcTarget), those returned stubs share the same RPC session as the original call. Subsequent calls on the returned stub are not billed as separate requests.

CPU time

CPU time is billed at the same rate as Workers Standard.

Unlike standard Workers (where only execution time is billed), Dynamic Workers bill for two components of CPU time:

  • Startup time: The compute required to initialize the isolate and parse your code.
  • Execution time: The compute time your code spends actively processing logic, excluding time spent waiting on I/O.

Custom resource limits

as of Nov 3, 2026

As of Nov 3, 2026, from Cloudflare's docs, last updated there Oct 12, 2026. Licensed CC BY 4.0; navigation removed.

By default, each Dynamic Worker invocation uses your Workers plan limits for CPU time and subrequests. Custom limits let you programmatically enforce lower limits on the Dynamic Worker's resource usage.

You can set limits for the maximum CPU time and number of subrequests per invocation. If a Dynamic Worker reaches either limit, it immediately throws an exception.

Set custom limits

Specify custom limits as part of the Worker code:

const worker = env.LOADER.get("my-worker", async () => {
  return {
    compatibilityDate: "$today",
    mainModule: "index.js",
    modules: { "index.js": code },
    limits: { cpuMs: 10, subRequests: 5 },
  };
});

You can also specify limits as part of the getEntrypoint() call:

// Get the Worker's default entrypoint with custom limits.
// If limits were already specified as part of the Worker code,
// the lower of the two limits is used.
const entrypoint = worker.getEntrypoint(null, { limits: { cpuMs: 10, subRequests: 5 } });
await entrypoint.fetch(...);

Limits

as of Nov 3, 2026

As of Nov 3, 2026, from Cloudflare's docs, last updated there Aug 27, 2026. Licensed CC BY 4.0; navigation removed.

Cloudflare limits the number of distinct Dynamic Workers with in-flight requests. Multiple in-flight requests to the same Dynamic Worker count as one toward this limit.

Context Concurrent Dynamic Workers
Worker request 4
Durable Object 10 (previously 4)

In a Worker, each request has its own input/output (I/O) context. Each request can therefore have up to four distinct Dynamic Workers with in-flight requests.

A Durable Object shares one I/O context across all concurrent requests to the same object. Those requests can collectively have up to ten distinct Dynamic Workers with in-flight requests. To set lower CPU time or subrequest limits, refer to Custom resource limits.

Timeline

No changelog entries or incidents name Dynamic Workers yet.