Products · Developer platform

Workers

Build, deploy, and scale serverless applications globally with low latency and minimal configuration

Pricing and limits

Pricing

as of Nov 3, 2026

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

By default, users have access to the Workers Free plan. The Workers Free plan includes limited usage of Workers, Pages Functions, Workers KV and Hyperdrive. Read more about the Free plan limits.

The Workers Paid plan includes Workers, Pages Functions, Workers KV, Hyperdrive, and Durable Objects usage for a minimum charge of $5 USD per month for an account. The plan includes increased initial usage allotments, with clear charges for usage that exceeds the base plan. There are no additional charges for data transfer (egress) or throughput (bandwidth).

All included usage is on a monthly basis.

Pages Functions billing

All Pages Functions are billed as Workers. All pricing and inclusions in this document apply to Pages Functions. Refer to Functions Pricing for more information on Pages Functions pricing.

Workers

Users on the Workers Paid plan have access to the Standard usage model. Workers Enterprise accounts are billed based on the usage model specified in their contract. To switch to the Standard usage model, contact your Account Manager.

	Requests^{1, 2, 3, 4}	Duration	CPU time
Free	100,000 per day	No charge for duration	10 milliseconds of CPU time per invocation
Standard	10 million included per month +$0.30 per additional million	No charge or limit for duration	30 million CPU milliseconds included per month +$0.02 per additional million CPU milliseconds Max of 5 minutes of CPU time per invocation (default: 30 seconds) Max of 15 minutes of CPU time per Cron Trigger or Queue Consumer invocation

¹ Inbound requests to your Worker. Cloudflare does not bill for subrequests you make from your Worker.

² WebSocket connections made to a Worker are charged as a request, representing the initial Upgrade connection made to establish the WebSocket. WebSocket messages routed through a Worker do not count as requests.

³ Requests to static assets are free and unlimited.

⁴ When Workers Caching is enabled, requests served from the Worker's cache are billed at the same per-request rate as requests that invoke the Worker. This includes requests to static assets and worker-to-worker invocations. CPU time is only billed when the Worker runs (on a cache miss or bypass).

Example pricing

Example 1

A Worker that serves 15 million requests per month, and uses an average of 7 milliseconds (ms) of CPU time per request, would have the following estimated costs:

	Monthly Costs	Formula
Subscription	$5.00
Requests	$1.50	(15,000,000 requests - 10,000,000 included requests) / 1,000,000 * $0.30
CPU time	$1.50	((7 ms of CPU time per request * 15,000,000 requests) - 30,000,000 included CPU ms) / 1,000,000 * $0.02
Total	$8.00

Example 2

A project that serves 15 million requests per month, with 80% (12 million) requests serving static assets and the remaining invoking dynamic Worker code. The Worker uses an average of 7 milliseconds (ms) of time per request.

Requests to static assets are free and unlimited. This project would have the following estimated costs:

	Monthly Costs	Formula
Subscription	$5.00
Requests to static assets	$0	-
Requests to Worker	$0	-
CPU time	$0	-
Total	$5.00

Example 3

A Worker that runs on a Cron Trigger once an hour to collect data from multiple APIs, process the data and create a report.

720 requests/month
3 minutes (180,000ms) of CPU time per request

In this scenario, the estimated monthly cost would be calculated as:

	Monthly Costs	Formula
Subscription	$5.00
Requests	$0.00	-
CPU time	$1.99	((180,000 ms of CPU time per request * 720 requests) - 30,000,000 included CPU ms) / 1,000,000 * $0.02
Total	$6.99

Example 4

A high traffic Worker that serves 100 million requests per month, and uses an average of 7 milliseconds (ms) of CPU time per request, would have the following estimated costs:

	Monthly Costs	Formula
Subscription	$5.00
Requests	$27.00	(100,000,000 requests - 10,000,000 included requests) / 1,000,000 * $0.30
CPU time	$13.40	((7 ms of CPU time per request * 100,000,000 requests) - 30,000,000 included CPU ms) / 1,000,000 * $0.02
Total	$45.40

Example 5: Worker with caching

The same Worker as Example 4, but with Workers Caching enabled and an 80% cache hit rate. 80 million requests are served from cache and 20 million invoke the Worker. Cache hits count as requests but do not consume CPU time.

	Monthly Costs	Formula
Subscription	$5.00
Requests	$27.00	(100,000,000 requests - 10,000,000 included requests) / 1,000,000 * $0.30
CPU time	$2.20	((7 ms of CPU time per request * 20,000,000 requests) - 30,000,000 included CPU ms) / 1,000,000 * $0.02
Total	$34.20

For details on what is cached and how to enable caching, refer to Cache.

Custom limits

To prevent accidental runaway bills or denial-of-wallet attacks, configure the maximum amount of CPU time that can be used per invocation by defining limits in your Worker's Wrangler file, or via the Cloudflare dashboard (Workers & Pages > Select your Worker > Settings > CPU Limits).

If you had a Worker on the Bundled usage model prior to the migration to Standard pricing on March 1, 2024, Cloudflare has automatically added a 50 ms CPU limit on your Worker.

How to switch usage models

Note

Some Workers Enterprise customers maintain the ability to change usage models.

Users on the Workers Paid plan have access to the Standard usage model. However, some users may still have a legacy usage model configured. Legacy usage models include Workers Unbound and Workers Bundled. Users are advised to move to the Workers Standard usage model. Changing the usage model only affects billable usage, and has no technical implications.

To change your default account-wide usage model:

In the Cloudflare dashboard, go to the Workers & Pages page. Go to Workers & Pages ↗
Find Usage Model on the right-side menu > Change.

Usage models may be changed at the individual Worker level:

In the Cloudflare dashboard, go to the Workers & Pages page. Go to Workers & Pages ↗
In Overview, select your Worker > Settings > Usage Model.

Existing Workers will not be impacted when changing the default usage model. You may change the usage model for individual Workers without affecting your account-wide default usage model.

Workers Logs

Workers Logs is included in both the Free and Paid Workers plans.

	Log Events Written	Retention
Workers Free	200,000 per day	3 Days
Workers Paid	20 million included per month +$0.60 per additional million	7 Days

Pricing change

Beginning December 1, 2026, Workers Logs will use Cloudflare Observability pricing. Until then, the Workers Logs pricing in this table applies.

Workers Logs documentation

For more information and examples of Workers Logs billing, refer to the Workers Logs documentation.

Workers Trace Events Logpush

Workers Logpush is only available on the Workers Paid plan.

	Paid plan
Requests ¹	10 million / month, +$0.05/million

¹ Workers Logpush charges for request logs that reach your end destination after applying filtering or sampling.

Workers KV

Workers KV is included in both the Free and Paid Workers plans.

	Free plan¹	Paid plan
Keys read	100,000 / day	10 million/month, + $0.50/million
Keys written	1,000 / day	1 million/month, + $5.00/million
Keys deleted	1,000 / day	1 million/month, + $5.00/million
List requests	1,000 / day	1 million/month, + $5.00/million
Stored data	1 GB	1 GB, + $0.50/ GB-month
Namespaces	1,000	Unlimited, with a default limit of 1,000. First 1,000 included + $0.10 per additional namespace per month.

Refer to KV limits for namespace creation limits and limit increases.

¹ The Workers Free plan includes limited Workers KV usage. Daily usage limits reset daily at 00:00 UTC. If you exceed any one of these limits, further operations of that type will fail with an error.

Note

Workers KV pricing for read, write and delete operations is on a per-key basis. Bulk read operations are billed by the amount of keys read in a bulk read operation.

KV documentation

To learn more about KV, refer to the KV documentation.

Hyperdrive

Hyperdrive is included in both the Free and Paid Workers plans.

	Free plan¹	Paid plan
Database queries²	100,000 / day	Unlimited

Footnotes

</summary>

1: The Workers Free plan includes limited Hyperdrive usage. All limits reset daily at 00:00 UTC. If you exceed any one of these limits, further operations of that type will fail with an error.

2: Database queries refers to any database statement made via Hyperdrive, whether a query (SELECT), a modification (INSERT,UPDATE, or DELETE) or a schema change (CREATE, ALTER, DROP).

</details>

Footnotes

The Workers Free plan includes limited Hyperdrive usage. All limits reset daily at 00:00 UTC. If you exceed any one of these limits, further operations of that type will fail with an error. ↩
Database queries refers to any database statement made via Hyperdrive, whether a query ( SELECT), a modification ( INSERT, UPDATE, or DELETE) or a schema change ( CREATE, ALTER, DROP). ↩

Hyperdrive documentation

To learn more about Hyperdrive, refer to the Hyperdrive documentation.

Queues

Cloudflare Queues charges for operations and for queues above the included amount on the Workers Paid plan.

An operation is counted for each 64 KB of data that is written, read, or deleted.
Messages larger than 64 KB are charged as if they were multiple messages: for example, a 65 KB message and a 127 KB message would both incur two operation charges when written, read, or deleted.
A KB is defined as 1,000 bytes, and each message includes approximately 100 bytes of internal metadata.
Operations are per message, not per batch. A batch of 10 messages (the default batch size), if processed, would incur 10x write, 10x read, and 10x delete operations: one for each message in the batch.
There are no data transfer (egress) or throughput (bandwidth) charges.

	Workers Free	Workers Paid
Standard operations	10,000 operations/day included	1,000,000 operations/month included + $0.40/million operations
Queues per account	10,000	Unlimited, with a default limit of 10,000. First 10,000 included + $0.10 per additional queue per month.
Message retention	24 hours (non-configurable)	4 days default, configurable up to 14 days

Refer to Queues limits for queue creation limits and how to request a limit increase.

In most cases, it takes 3 operations to deliver a message: 1 write, 1 read, and 1 delete. Therefore, you can use the following formula to estimate your monthly operations charges, excluding charges for additional queues:

((Number of Messages * 3) - 1,000,000) / 1,000,000  * $0.40

Additionally:

Each retry incurs a read operation. A batch of 10 messages that is retried would incur 10 operations for each retry.
Messages that reach the maximum retries and that are written to a Dead Letter Queue incur a write operation for each 64 KB chunk. A message that was retried 3 times (the default), fails delivery on the fourth time and is written to a Dead Letter Queue would incur five (5) read operations.
Messages that are written to a queue, but that reach the maximum persistence duration (or "expire") before they are read, incur only a write and delete operation per 64 KB chunk.

Queues billing examples

To learn more about Queues pricing and review billing examples, refer to Queues Pricing.

Workflows

Unit	Workers Free	Workers Paid
Requests (millions)	100,000 per day (shared with Workers requests)	10 million included per month + $0.30 per additional million
CPU time (ms)	10 milliseconds of CPU time per invocation	30 million CPU milliseconds included per month + $0.02 per additional million CPU milliseconds
Storage (GB-mo)	1 GB-month	1 GB-month included + $0.20/ GB-month
Steps	3,000 per day	500,000 included per month + $0.80/ additional 100,000 per month

Cloudflare will not bill step and storage usage before the start date announced in the Workflows billing changelog.

Workflows pricing

To learn more about Workflows billing, refer to Workflows pricing.

D1

D1 is available on both the Workers Free and Workers Paid plans.

	Workers Free	Workers Paid
Rows read	5 million / day	First 25 billion / month included + $0.001 / million rows
Rows written	100,000 / day	First 50 million / month included + $1.00 / million rows
Storage (per GB stored)	5 GB (total)	First 5 GB included + $0.75 / GB-mo
Databases	10	First 100,000 included + $0.10 per additional database per month.

You pay $0.10 per month for each D1 database above the included amount, even when it is empty or receives no traffic. Usage and storage are billed separately.

Refer to D1 limits for database creation and storage limits.

Track your D1 usage

To accurately track your usage, use the meta object, GraphQL Analytics API, or the Cloudflare dashboard ↗︎. Select your D1 database, then view: Metrics > Row Metrics.

Definitions

Rows read measure how many rows a query reads (scans), regardless of the size of each row. For example, if you have a table with 5000 rows and run a SELECT * FROM table as a full table scan, this would count as 5,000 rows read. A query that filters on an unindexed column may return fewer rows to your Worker, but is still required to read (scan) more rows to determine which subset to return.
Rows written measure how many rows were written to D1 database. Write operations include INSERT, UPDATE, and DELETE. Each of these operations contribute towards rows written. A query that INSERT 10 rows into a users table would count as 10 rows written.
DDL operations (for example, CREATE, ALTER, and DROP) are used to define or modify the structure of a database. They may contribute to a mix of read rows and write rows. Ensure you are accurately tracking your usage through the available tools (meta object, GraphQL Analytics API, or the Cloudflare dashboard ↗︎).
Row size or the number of columns in a row does not impact how rows are counted. A row that is 1 KB and a row that is 100 KB both count as one row.
Defining indexes on your table(s) reduces the number of rows read by a query when filtering on that indexed field. For example, if the users table has an index on a timestamp column created_at, the query SELECT * FROM users WHERE created_at > ?1 would only need to read a subset of the table.
Indexes will add an additional written row when writes include the indexed column, as there are two rows written: one to the table itself, and one to the index. The performance benefit of an index and reduction in rows read will, in nearly all cases, offset this additional write.
Storage is based on gigabytes stored per month, and is based on the sum of all databases in your account. Tables and indexes both count towards storage consumed.
Free daily usage limits reset at 00:00 UTC. Monthly included usage resets based on your monthly subscription renewal date, which is determined by the day you first subscribed.
There are no data transfer (egress) or throughput (bandwidth) charges for data accessed from D1.
Read replication does not charge extra for read replicas. You incur the same usage billing based on rows_read and rows_written by your queries.

D1 billing

Refer to D1 Pricing to learn more about how D1 is billed.

Durable Objects

Note

Durable Objects are available both on Workers Free and Workers Paid plans.

Workers Free plan: Only Durable Objects with SQLite storage backend are available.
Workers Paid plan: Durable Objects with the SQLite storage backend are available. The key-value storage backend is only available to accounts that already have a key-value-backed namespace.

If you wish to downgrade from a Workers Paid plan to a Workers Free plan, you must first ensure that you have deleted all Durable Object namespaces with the key-value storage backend.

Compute billing

Durable Objects are billed for compute duration (wall-clock time) while the Durable Object is actively running or is idle in memory but unable to hibernate. Durable Objects that are idle and eligible for hibernation are not billed for duration, even before the runtime has hibernated them. Requests to a Durable Object keep it active or create the object if it was inactive.

For each metered dimension, billable usage is the amount consumed in excess of the included monthly allocation. This billable usage is rounded up to the next billable unit before the corresponding rate is applied. For example, 500,000 GB-s of billable compute duration is rounded up to 1,000,000 GB-s and billed accordingly.

	Free plan	Paid plan
Requests	100,000 / day	1 million / month, + $0.15/million Includes HTTP requests, RPC sessions¹, WebSocket messages², and alarm invocations
Duration³	13,000 GB-s / day	400,000 GB-s / month, + $12.50/million GB-s^4,5

Footnotes

</summary>

¹ Each <a href="https://developers.cloudflare.com/workers/runtime-apis/rpc/lifecycle/">RPC session</a> is billed as one request to your Durable Object. Every <a href="https://developers.cloudflare.com/durable-objects/best-practices/create-durable-object-stubs-and-send-requests/">RPC method call</a> on a <a href="https://developers.cloudflare.com/durable-objects/">Durable Objects stub</a> is its own RPC session and therefore a single billed request.

RPC method calls can return objects (stubs) extending <a href="https://developers.cloudflare.com/workers/runtime-apis/rpc/lifecycle/#lifetimes-memory-and-resource-management">RpcTarget</a> and invoke calls on those stubs. Subsequent calls on the returned stub are part of the same RPC session and are not billed as separate requests. For example:

let durableObjectStub = OBJECT_NAMESPACE.get(id); // retrieve Durable Object stub
using foo = await durableObjectStub.bar(); // billed as a request
await foo.baz(); // treated as part of the same RPC session created by calling bar(), not billed as a request
await durableObjectStub.cat(); // billed as a request

² A request is needed to create a WebSocket connection. There is no charge for outgoing WebSocket messages, nor for incoming <a href="https://www.rfc-editor.org/rfc/rfc6455#section-5.5.2">WebSocket protocol pings ↗︎</a>. For compute requests billing-only, a 20:1 ratio is applied to incoming WebSocket messages to factor in smaller messages for real-time communication. For example, 100 WebSocket incoming messages would be charged as 5 requests for billing purposes. The 20:1 ratio does not affect Durable Object metrics and analytics, which reflect actual usage.

³ Application level auto-response messages handled by <a href="https://developers.cloudflare.com/durable-objects/best-practices/websockets/">state.setWebSocketAutoResponse()</a> will not incur additional wall-clock time, and so they will not be charged.

⁴ Duration is billed in wall-clock time as long as the Object is active and not eligible for hibernation, but is shared across all requests active on an Object at once. Calling accept() on a WebSocket in an Object will incur duration charges for the entire time the WebSocket is connected. It is recommended to use the WebSocket Hibernation API to avoid incurring duration charges once all event handlers finish running. For a complete explanation, refer to <a href="https://developers.cloudflare.com/durable-objects/platform/pricing/#when-does-a-durable-object-incur-duration-charges">When does a Durable Object incur duration charges?</a>.

⁵ Duration billing charges for the 128 MB of memory your Durable Object is allocated, regardless of actual usage. If your account creates many instances of a single Durable Object class, Durable Objects may run in the same isolate on the same physical machine and share the 128 MB of memory. These Durable Objects are still billed as if they are allocated a full 128 MB of memory.

</details>

Storage billing

The Durable Objects Storage API is only accessible from within Durable Objects. Pricing depends on the storage backend of your Durable Objects.

SQLite-backed Durable Objects (recommended): SQLite storage backend is recommended for all new Durable Object classes. Workers Free plan can only create and access SQLite-backed Durable Objects.
Key-value backed Durable Objects: Key-value storage backend is only available on the Workers Paid plan.

SQLite storage backend

Storage billing on SQLite-backed Durable Objects

Storage billing for SQLite-backed Durable Objects will be enabled in January 2026, with a target date of January 7, 2026 (no earlier). Only SQLite storage usage on and after the billing target date will incur charges. For more information, refer to Billing for SQLite Storage.

	Workers Free plan	Workers Paid plan
Rows reads ^1,2	5 million / day	First 25 billion / month included + $0.001 / million rows
Rows written ^1,2,3,4	100,000 / day	First 50 million / month included + $1.00 / million rows
SQL Stored data ⁵	5 GB (total)	5 GB-month, + $0.20/ GB-month

Footnotes

</summary>

¹ Rows read and rows written included limits and rates match <a href="https://developers.cloudflare.com/d1/platform/pricing/">D1 pricing</a>, Cloudflare's serverless SQL database.

² Key-value methods like get(), put(), delete(), or list() store and query data in a hidden SQLite table and are billed as rows read and rows written.

³ Each setAlarm() is billed as a single row written.

⁴ Deletes are counted as rows written.

⁵ Durable Objects will be billed for stored data until the <a href="https://developers.cloudflare.com/durable-objects/best-practices/access-durable-objects-storage/#remove-a-durable-objects-storage">data is removed</a>. Once the data is removed, the object will be cleaned up automatically by the system.

</details>

Key-value storage backend

	Workers Paid plan
Read request units^1,2	1 million, + $0.20/million
Write request units³	1 million, + $1.00/million
Delete requests⁴	1 million, + $1.00/million
Stored data⁵	1 GB, + $0.20/ GB-month

Footnotes

</summary>

¹ A request unit is defined as 4 KB of data read or written. A request that writes or reads more than 4 KB will consume multiple units, for example, a 9 KB write will consume 3 write request units.

² List operations are billed by read request units, based on the amount of data examined. For example, a list request that returns a combined 80 KB of keys and values will be billed 20 read request units. A list request that does not return anything is billed for 1 read request unit.

³ Each setAlarm is billed as a single write request unit.

⁴ Delete requests are unmetered. For example, deleting a 100 KB value will be charged one delete request.

⁵ Durable Objects will be billed for stored data until the data is removed. Once the data is removed, the object will be cleaned up automatically by the system.

Requests that hit the <a href="https://developers.cloudflare.com/durable-objects/reference/in-memory-state/">Durable Objects in-memory cache</a> or that use the <a href="https://developers.cloudflare.com/durable-objects/api/sqlite-storage-api/">multi-key versions of get()/put()/delete() methods</a> are billed the same as if they were a normal, individual request for each key.

</details>

Durable Objects billing examples

For more information and examples of Durable Objects billing, refer to Durable Objects Pricing.

Vectorize

Vectorize is currently only available on the Workers paid plan.

	Workers Free	Workers Paid
Total queried vector dimensions	30 million queried vector dimensions / month	First 50 million queried vector dimensions / month included + $0.01 per million
Total stored vector dimensions	5 million stored vector dimensions	First 10 million stored vector dimensions + $0.05 per 100 million
Indexes	100	Unlimited, with a default limit of 50,000. First 50,000 included + $0.10 per additional index per month.

Calculating vector dimensions

To calculate your potential usage, calculate the queried vector dimensions and the stored vector dimensions, and multiply by the unit price. The formula is defined as ((queried vectors + stored vectors) * dimensions * ($0.01 / 1,000,000)) + (stored vectors * dimensions * ($0.05 / 100,000,000))

For example, inserting 10,000 vectors of 768 dimensions each, and querying those 1,000 times per day (30,000 times per month) would be calculated as ((30,000 + 10,000) * 768) = 30,720,000 queried dimensions and (10,000 * 768) = 7,680,000 stored dimensions (within the included monthly allocation)
Separately, and excluding the included monthly allocation, this would be calculated as (30,000 + 10,000) * 768 * ($0.01 / 1,000,000) + (10,000 * 768 * ($0.05 / 100,000,000)) and sum to $0.31 per month.

R2

R2 charges based on the total volume of data stored, along with two classes of operations on that data:

Class A operations which are more expensive and tend to mutate state.
Class B operations which tend to read existing state.

There are no charges for egress bandwidth.

	Free	Standard storage	Infrequent Access storage
Storage	10 GB-month / month	$0.015 / GB-month	$0.01 / GB-month
Class A Operations	1 million requests / month	$4.50 / million requests	$9.00 / million requests
Class B Operations	10 million requests / month	$0.36 / million requests	$0.90 / million requests
Data Retrieval (processing)	None	None	$0.01 / GB
Egress (data transfer to Internet)	Free	Free	Free

R2 documentation

To learn more about R2 pricing, including billing examples, refer to R2 Pricing.

Containers

Containers are billed for every 10ms that they are actively running at the following rates, with included monthly usage as part of the $5 USD per month Workers Paid plan:

	Memory	CPU	Disk
Free	N/A	N/A	N/A
Workers Paid	25 GiB-hours/month included +$0.0000025 per additional GiB-second	375 vCPU-minutes/month + $0.000020 per additional vCPU-second	200 GB-hours/month +$0.00000007 per additional GB-second

You only pay for what you use — charges start when a request is sent to the container or when it is manually started. Charges stop after the container instance goes to sleep, which can happen automatically after a timeout.

Network Egress

Egress from Containers is priced at the following rates:

Region	Price per GB	Included Allotment per month
North America & Europe	$0.025	1 TB
Oceania, Korea, Taiwan	$0.05	500 GB
Everywhere Else	$0.04	500 GB

Containers documentation

To learn more about Containers pricing, refer to Containers Pricing.

Service bindings

Requests made from your Worker to another worker via a Service Binding do not incur additional request fees. This allows you to split apart functionality into multiple Workers, without incurring additional costs.

For example, if Worker A makes a subrequest to Worker B via a Service Binding, or calls an RPC method provided by Worker B via a Service Binding, this is billed as:

One request (for the initial invocation of Worker A)
The total amount of CPU time used across both Worker A and Worker B

Only available on Workers Standard pricing

If your Worker is on the deprecated Bundled or Unbound pricing plans, incoming requests from Service Bindings are charged the same as requests from the Internet. In the example above, you would be charged for two requests, one to Worker A, and one to Worker B.

Fine Print

Workers Paid plan is separate from any other Cloudflare plan (Free, Professional, Business) you may have. If you are an Enterprise customer, reach out to your account team to confirm pricing details.

Only requests that hit a Worker will count against your limits and your bill. Since Cloudflare Workers runs before the Cloudflare cache, the caching of a request still incurs costs. Refer to Limits to review definitions and behavior after a limit is hit.

Limits

as of Nov 3, 2026

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

Account plan limits

Feature	Workers Free	Workers Paid
Requests	100,000/day	No limit
CPU time	10 ms	5 min
Memory	128 MB	128 MB
Subrequests	50/request	10,000/request
Simultaneous outgoing connections/request	6	6
Environment variables	64/Worker	128/Worker
Environment variable size	5 KB	5 KB
Worker size	64 MiB	64 MiB
Worker startup time	1 second	1 second
Number of Workers	100	500¹
Number of Cron Triggers per account	5	250
Number of Static Asset files per Worker version	20,000	100,000
Individual Static Asset file size	25 MiB	25 MiB

Need a higher limit?

To request an adjustment to a limit, complete the Limit Increase Request Form ↗︎. If the limit can be increased, Cloudflare will contact you with next steps.

Request and response limits

Limit	Value
URL size	16 KB
Request header size	128 KB (total)
Response header size	128 KB (total)
Response body size	No enforced limit

For incoming requests to a Worker on your domain, request body size limits depend on the domain's Cloudflare plan, not your Workers plan. Requests exceeding these limits return a 413 Request entity too large error.

Cloudflare Plan	Maximum request body size
Free	100 MB
Pro	100 MB
Business	200 MB
Enterprise	Up to 5 GB (self-serve)

Enterprise customers can adjust the maximum request body size up to 5 GB themselves from the zone's Network page (Maximum Upload Size). For limits above 5 GB, contact your account team or Cloudflare Support.

Cloudflare limits each HTTP request body sent to an external service by a Durable Object or through a Container outbound handler to 100 MiB by default. Increasing Maximum Upload Size for your domain does not increase this limit. Refer to the product limits for upload guidance and how to request an increase.

Cloudflare does not enforce response body size limits. CDN cache limits apply: 512 MB for Free, Pro, and Business plans, and 5 GB for Enterprise.

CPU time

CPU time measures how long the CPU spends executing your Worker code. Waiting on network requests (such as fetch() calls, KV reads, or database queries) does not count toward CPU time.

Limit	Workers Free	Workers Paid
CPU time per HTTP request	10 ms	5 min (default: 30 seconds)
CPU time per Cron Trigger	10 ms	30 seconds (< 1 hour interval) 15 min (>= 1 hour interval)

Most Workers consume very little CPU time. The average Worker uses approximately 2.2 ms per request. Heavier workloads that handle authentication, server-side rendering, or parse large payloads typically use 10-20 ms.

Each isolate has some built-in flexibility to allow for cases where your Worker infrequently runs over the configured limit. If your Worker starts hitting the limit consistently, its execution will be terminated according to the limit configured.

Error: exceeded CPU time limit

When a Worker exceeds its CPU time limit, Cloudflare returns Error 1102 to the client with the message Worker exceeded resource limits. In the dashboard, this appears as Exceeded CPU Time Limits under Metrics > Errors > Invocation Statuses. In analytics and Logpush, the invocation outcome is exceededCpu.

To resolve a CPU time limit error:

Increase the CPU time limit — On the Workers Paid plan, you can raise the limit from the default 30 seconds up to 5 minutes (300,000 ms). Set this in your Wrangler configuration or in the dashboard.
Optimize your code — Use CPU profiling with DevTools to identify CPU-intensive sections of your code.
Offload work — Move expensive computation to Durable Objects or process data in smaller chunks across multiple requests.

Increasing the CPU time limit

On the Workers Paid plan, you can increase the maximum CPU time from the default 30 seconds to 5 minutes (300,000 ms).

{
	// ...rest of your configuration...
	"limits": {
		"cpu_ms": 300000, // default is 30000 (30 seconds)
	},
	// ...rest of your configuration...
}

[limits]
cpu_ms = 300_000

You can also change this in the dashboard: go to Workers & Pages > select your Worker > Settings > adjust the CPU time limit.

Monitoring CPU usage

Workers Logs — CPU time and wall time appear in the invocation log.
Tail Workers / Logpush — CPU time and wall time appear at the top level of the Workers Trace Events object.
DevTools — Use CPU profiling with DevTools locally to identify CPU-intensive sections of your code.

Memory

Limit	Value
Memory per isolate	128 MB

Each isolate can consume up to 128 MB of memory, including the JavaScript heap and WebAssembly allocations. This limit is per-isolate, not per-invocation. A single isolate can handle many concurrent requests.

When an isolate exceeds 128 MB, the Workers runtime lets in-flight requests complete and creates a new isolate for subsequent requests. During extremely high load, the runtime may cancel some incoming requests to maintain stability.

Error: exceeded memory limit

When a Worker exceeds its memory limit, Cloudflare returns Error 1102 to the client with the message Worker exceeded resource limits. In the dashboard, this appears as Exceeded Memory under Metrics > Errors > Invocation Statuses. In analytics and Logpush, the invocation outcome is exceededMemory.

You may also see the runtime error Memory limit would be exceeded before EOF when attempting to buffer a response body that exceeds the limit.

To resolve a memory limit error:

Stream request and response bodies — Use TransformStream or node:stream instead of buffering entire payloads in memory.
Avoid large in-memory objects — Store large data in KV, R2, or D1 instead of holding it in Worker memory.
Update Zod — If your Worker uses Zod, use version 4.5.0 or later ↗︎. Earlier versions use substantially more memory per schema.
Profile memory usage — Use memory profiling with DevTools locally to identify leaks and high-memory allocations.

To view memory errors in the dashboard:

Go to Workers & Pages. Go to Workers & Pages ↗
Select the Worker you want to investigate.
Under Metrics, select Errors > Invocation Statuses and examine Exceeded Memory.

Duration

Duration measures wall-clock time from start to end of a Worker invocation.

Trigger type	Duration limit
HTTP request	No limit
Cron Trigger	15 min
Durable Object Alarm	15 min
Queue Consumer	15 min

There is no hard limit on duration for HTTP-triggered Workers. As long as the client remains connected, the Worker can continue processing, making subrequests, and streaming a response body. When the client disconnects or the response is complete, tasks associated with that request may be canceled. Use ctx.waitUntil() to perform work after returning a response. waitUntil() can extend execution for up to 30 seconds after the response is sent or the client disconnects.

Runtime updates

Cloudflare regularly updates the Workers runtime. During routine updates, processes running the previous version of the Workers runtime give existing Workers requests and connections up to 20 minutes to finish. This includes streaming HTTP responses and WebSocket connections.

Once the updated version of the Workers runtime is ready, it handles new incoming HTTP requests. Processes running the previous version stop accepting these requests and drain existing work during their grace period.

The grace period applies to each process running the previous version, not to each request. When it ends, that process terminates its remaining requests and connections.

Crashes, resource pressure, and shutdowns can interrupt work earlier. Design long-running applications to handle disconnections and safely retry interrupted work.

Daily requests

Workers scale automatically across the Cloudflare global network. There is no general limit on requests per second.

Accounts on the Workers Free plan have a daily request limit of 100,000 requests, resetting at midnight UTC. When a Worker exceeds this limit, Cloudflare returns Error 1027.

Route mode	Behavior
Fail open	Bypasses the Worker. Requests behave as if no Worker is configured.
Fail closed	Returns a Cloudflare `1027` error page. Use this for security-critical Workers.

You can configure the fail mode by toggling the corresponding route.

Subrequests

A subrequest is any request a Worker makes using the Fetch API or to Cloudflare services like R2, KV, or D1.

Limit	Workers Free	Workers Paid
Subrequests per invocation	50	10,000 (up to 10M)
Subrequests to internal services	1,000	Matches configured limit (default 10,000)

Each subrequest in a redirect chain counts against this limit. The total number of subrequests may exceed the number of fetch() calls in your code. You can change the subrequest limit per Worker using the limits configuration in your Wrangler configuration file.

There is no set time limit on individual subrequests. As long as the client remains connected, the Worker can continue making subrequests. When the client disconnects or the response is complete, outstanding work may be canceled unless it is passed to ctx.waitUntil(), which can extend execution for up to 30 seconds.

Worker-to-Worker subrequests

Use Service Bindings to send requests from one Worker to another on your account without going over the Internet.

Using global fetch() to call another Worker on the same zone without service bindings fails. Workers accept requests sent to a Custom Domain.

Simultaneous open connections

Each Worker invocation can have up to six connections simultaneously waiting for response headers. The following API calls count toward this limit while the initial connection is being established and the server has not yet responded:

fetch() method of the Fetch API
get(), put(), list(), and delete() methods of Workers KV namespace objects
put(), match(), and delete() methods of Cache objects
list(), get(), put(), delete(), and head() methods of R2
send() and sendBatch() methods of Queues
Opening a TCP socket using the connect() API

Outbound WebSocket connections also count toward this limit.

Once response headers arrive for a connection, it no longer counts toward the six-connection limit. This means a Worker can have many connections open simultaneously, as long as no more than six are in the initial "waiting for headers" phase at the same time. If a seventh connection is attempted while six are already waiting for headers, it is queued until one of the existing connections receives its response headers.

If you use fetch() but do not need the response body, calling response.body.cancel() is still good practice to free memory:

src/index.jsjs

const response = await fetch(url);

// Only read the response body for successful responses
if (response.status <= 299) {
	// Call response.json(), response.text() or otherwise process the body
} else {
	// Explicitly cancel it
	response.body.cancel();
}

src/index.tsts

const response = await fetch(url);

// Only read the response body for successful responses
if (response.status <= 299) {
	// Call response.json(), response.text() or otherwise process the body
} else {
	// Explicitly cancel it
	response.body.cancel();
}

Note

The runtime measures simultaneous open connections from the top-level request. Workers triggered via Service bindings share the same connection limit.

Environment variables

Limit	Workers Free	Workers Paid
Variables per Worker (secrets + text)	64	128
Variable size	5 KB	5 KB
Variables per account	No limit	No limit

Worker size

Limit	Workers Free	Workers Paid
Worker size (uncompressed)	64 MiB	64 MiB

There is no compressed size limit. Only the uncompressed bundle size counts.

Larger Worker bundles can impact startup time. To check your Worker bundle size:

wrangler deploy --outdir bundled/ --dry-run

Total Upload: 259.61 KiB / gzip: 47.23 KiB

The Total Upload value is your uncompressed bundle size. The gzip value is shown for reference but is not a limit.

To reduce Worker size:

Remove unnecessary dependencies and packages.
Store configuration files, static assets, and binary data in KV, R2, D1, or Workers Static Assets instead of bundling them.
Split functionality across multiple Workers using Service bindings.

Worker startup time

Limit	Value
Startup time	1 second

A Worker must parse and execute its global scope (top-level code outside of handlers) within 1 second. Larger bundles and expensive initialization code in global scope increase startup time.

When the platform rejects a deployment because the Worker exceeds the startup time limit, the validation returns the error Script startup exceeded CPU time limit (error code 10021). Wrangler automatically generates a CPU profile that you can import into Chrome DevTools or open in VS Code. Refer to wrangler check startup for more details.

To measure startup time, run npx wrangler@latest deploy or npx wrangler@latest versions upload. Wrangler reports startup_time_ms in the output.

To reduce startup time, avoid expensive work in global scope. Move initialization logic into your handler or to build time. For example, generating or consuming a large schema at the top level is a common cause of exceeding this limit.

Need a higher limit?

To request an adjustment to a limit, complete the Limit Increase Request Form ↗︎. If the limit can be increased, Cloudflare will contact you with next steps.

Number of Workers

Limit	Workers Free	Workers Paid
Workers per account	100	500¹

If you are building a platform where your end customers deploy their own sites or applications, use Workers for Platforms, which runs an unlimited number of user Workers.

Routes and domains

Limit	Value
Routes per zone	1,000
Routes per zone (`wrangler dev --remote`)	50
Custom domains per zone	100
Routed zones per Worker	1,000

Routes with `wrangler dev --remote`

When you run a remote development session using the --remote flag, Cloudflare enforces a limit of 50 routes per zone. The Quick Editor in the Cloudflare dashboard also uses wrangler dev --remote, so the same limit applies.

If your zone has more than 50 routes, you cannot run a remote session until you remove routes to get under the limit.

If you require more than 1,000 routes or 1,000 routed zones per Worker, consider using Workers for Platforms. If you require more than 100 custom domains per zone, consider using a wildcard route.

Cache API limits

Feature	Workers Free	Workers Paid
Maximum object size	512 MB	512 MB
Calls per request	50	1,000

Calls per request is the number of put(), match(), or delete() Cache API calls per request. This shares the same quota as subrequests (fetch()).

Note

The size of chunked response bodies (Transfer-Encoding: chunked) is not known in advance. Calling .put() with such a response blocks subsequent .put() calls until the current one completes.

Log size

Limit	Value
Log data per request	256 KB

This limit covers all data emitted via console.log() statements, exceptions, request metadata, and headers for a single request. After exceeding this limit, the system does not record additional context for that request in logs, tail logs, or Tail Workers.

Refer to the Workers Trace Event Logpush documentation for limits on fields sent to Logpush destinations.

Image Resizing with Workers

Refer to the Image Resizing documentation for limits that apply when using Image Resizing with Workers.

Static Assets

Limit	Workers Free	Workers Paid
Files per Worker version	20,000	100,000
Individual file size	25 MiB	25 MiB
`_headers` rules	100	100
`_headers` characters per line	2,000	2,000
`_redirects` static redirects	2,000	2,000
`_redirects` dynamic redirects	100	100
`_redirects` total	2,100	2,100
`_redirects` characters per rule	1,000	1,000

Note

To use the increased file count limits in Wrangler, you must use version 4.34.0 or higher.

Unbound and Bundled plan limits

Note

Unbound and Bundled plans have been deprecated and are no longer available for new accounts.

If your Worker is on an Unbound plan, limits match the Workers Paid plan.

If your Worker is on a Bundled plan, limits match the Workers Paid plan with these exceptions:

Feature	Bundled plan limit
Subrequests	50/request
CPU time (HTTP requests)	50 ms
CPU time (Cron Triggers)	50 ms
Cache API calls/request	50

Bundled plan Workers have no duration limits for Cron Triggers, Durable Object Alarms, or Queue Consumers.

Wall time limits by invocation type

Wall time (also called wall-clock time) is the total elapsed time from the start to end of an invocation, including time spent waiting on network requests, I/O, and other asynchronous operations. This is distinct from CPU time, which only measures time the CPU spends actively executing your code.

The following table summarizes the wall time limits for different types of Worker invocations across the developer platform:

Invocation type	Wall time limit	Details
Incoming HTTP request	Unlimited	No hard limit while the client remains connected. Workers requests are subject to the grace period for runtime updates. A Worker that is still streaming a response body remains active. `waitUntil()` extends execution for up to 30 seconds after the response or disconnect.
Cron Triggers	15 minutes	Scheduled Workers have a maximum wall time of 15 minutes per invocation.
Queue consumers	15 minutes	Each consumer invocation has a maximum wall time of 15 minutes.
Durable Object alarm handlers	15 minutes	Alarm handler invocations have a maximum wall time of 15 minutes.
Durable Objects (RPC / HTTP)	Unlimited	No hard limit while the caller stays connected to the Durable Object. Durable Objects remain active while a request, RPC call, response stream, WebSocket, or pending I/O is in flight.
Workflows (per step)	Unlimited	Each step can run for an unlimited wall time. Individual steps are subject to the configured CPU time limit.

Related resources

Footnotes

If you need a higher Worker limit, use Workers for Platforms. ↩ ↩²

Timeline

285 entries since February 2024, the latest 100 shown.

November 2026

Nov 2
Worker Deployments Delayed Incident
Minor impact. Resolved Nov 2, 2026, 17:30 UTC.
Nov 2
Workers will use the new module registry by default on November 17
Starting November 17, 2026, JavaScript Workers with a compatibility date of 2026-11-17 or later will use the new module registry by default. You will no longer need the new_module_registry flag for these dates. Python Workers keep using the legacy registry. The module registry finds and loads JavaScript modules in your Worker. We announced the new registry in September 2026 ↗︎. It improves compat…
Nov 2
Request.signal will be enabled by default in Workers on November 17
Starting November 17, 2026, Workers with a compatibility date of 2026-11-17 or later will receive client disconnection events through request.signal by default. Use these events to stop unnecessary work when a client leaves. You will no longer need the enable_request_signal compatibility flag for these dates. We introduced this feature in May 2025. You can log cancellations, clean up resources, o…

October 2026

Oct 30
Workers subrequests now preserve context for BYOIP destinations
Cloudflare now preserves Workers context when a subrequest targets a Cloudflare-proxied hostname using Bring Your Own IP (BYOIP). These requests are identified as Cloudflare-to-Cloudflare traffic instead of external Internet traffic. Previously, some BYOIP subrequests could lose Workers context and original client signals. This could cause security rules to behave unexpectedly, Bot Management to…
Oct 30
Durable Objects now defer code updates by default
Durable Objects can stay active across requests, allowing you to run long-running agents, maintain long-lived WebSocket connections and coordinate state across many clients. This is possible because each Durable Object is globally unique, and this means it must run only one version of your code at a time. Previously, when you deployed a change to your Durable Objects code, that change would be ap…
Oct 28
Serve Workers Static Assets from a URL path prefix
Workers Static Assets can now serve assets from a URL path prefix without changing their directory structure. Set assets.base_path in Wrangler, or worker.assets.basePath in cloudflare.config.ts. Use Wrangler 4.148.0 ↗︎ or later. With cloudflare.config.ts, use cf 1.0.0-beta.13 ↗︎ or later. For example, this configuration serves your built assets from /blog/: Select your preferred CLI WranglerCF Ch…
Oct 28
Workers Builds now retains builds and build logs for 90 days
Workers Builds now retains each build and its build logs for 90 days after the build finishes. You can find them under View build history in your Worker's Deployments tab, or through the Workers Builds API. After 90 days, a build and its logs are removed. The versions and deployments it created stay in your Worker's version history, so you can still roll back to them. If you need a build's logs f…
Oct 27
Restrict Workflows to a jurisdiction
You can now restrict a Workflow to a jurisdiction. Its instances only run and store data within that jurisdiction, which helps you comply with data localization regulations such as GDPR ↗︎ or FedRAMP ↗︎. Set jurisdiction on a workflows binding, or on a Workflow declared in exports: { "workflows": [ { "name": "my-workflow", "binding": "MY_WORKFLOW", "class_name": "MyWorkflow", "jurisdiction": "eu"…
Oct 26
Delayed, missed, and duplicated Workers Cron Triggers Incident
Minor impact. Resolved Oct 27, 2026, 01:15 UTC.
Oct 26
Cloudflare Computer now helps agents recover from interruptions and wait for approval
@cloudflare/computer ↗︎ gives your agent a workspace to run code in. From v0.7.0, that code can resume after a deploy or crash, and pause on an external action, for example to approve a tool call. Resume interrupted runs Set onInterrupt: "replay" on WorkerJavaScriptBackend, or on a single run. import { DurableObject } from "cloudflare:workers"; import { Workspace } from "@cloudflare/computer"; im…
Oct 26
Workers tracing — new spanContext(), setStatus(), and updateName() APIs
Custom spans in Workers now support three more methods from the OpenTelemetry span API. span.spanContext() returns the span's traceId, spanId, and traceFlags. The IDs match the trace and span IDs in Workers Observability and in exported traces, so you can log them or return them to clients to correlate a request with its trace. span.setStatus(status) sets the span status to "unset", "ok", or "err…
Oct 23
Delayed, missed, and duplicated Workers Cron Triggers Incident
Minor impact. Resolved Oct 23, 2026, 20:37 UTC.
Oct 23
Workers Builds and Pages build images reject compromised eMudhra certificates
The private keys of eight eMudhra intermediate certificate authorities ↗︎ can be recovered, so anyone can forge a certificate for any hostname that chains to them. The Workers Builds and Pages build images now reject these certificates when your build clones your repository, installs dependencies, or makes HTTPS requests. The updated images include patched CA certificates, Node.js 22.23.4 and 24.…
Oct 23
Pin your npm version in Workers Builds with packageManager
You can now choose the npm version that Workers Builds uses by setting the packageManager field in your package.json. Before the build installs dependencies, it installs the npm version you set, so a lockfile written by a newer npm version installs the same way in your build as it does locally. package.jsonjson{ "packageManager": "npm@11.19.1" } The packageManager field also sets the version of Y…
Oct 22
Elevated errors for some requests in Ashburn, Virginia Incident
Minor impact. Resolved Oct 22, 2026, 17:31 UTC.
Oct 22
Cloudflare Workers API Latency Incident
Minor impact. Resolved Oct 22, 2026, 16:15 UTC.
Oct 20
Think agents now use a @cloudflare/computer workspace
Think and Agent Skills now use the workspace from @cloudflare/computer ↗︎ as well as the filesystem tools. A JavaScript execution environment can be configured by adding the WorkerJavaScriptBackend. @cloudflare/shell is deprecated, and so is Think's createExecuteTool. These will no longer be developed nor supported from today onwards. import { Think } from "@cloudflare/think"; import { Workspace…
Oct 20
Wrangler and cf now upload source maps by default
From Wrangler 4.150.0, wrangler deploy, wrangler versions upload, and wrangler preview generate and upload source maps by default. You no longer need to set upload_source_maps to get stack traces with your original file names and line numbers. cf deploy also uploads source maps by default. With the Cloudflare Vite plugin 1.64.0 or later, Worker builds generate source maps by default, and cf deplo…
Oct 17
Test Cron Triggers with Local Explorer
Local Explorer can now send one-off Cron Trigger invocations to a Worker's scheduled() handler during local development. This removes the need to construct request URLs when testing handler behavior. Start your local development server with cf dev, wrangler dev, or the Cloudflare Vite plugin. Open /cdn-cgi/local/explorer on the server URL and select Cron Triggers. The browser interface supports t…
Oct 16
Search Cloudflare documentation with the Cloudflare CLI
Cloudflare CLI 1.0.0-beta.16 includes cf docs search, so you and your coding agent can find Cloudflare documentation without leaving the terminal. Search for guides, tutorials, and examples across Cloudflare products. To install or update to the latest release: npmyarnpnpmbun npm install --global cf@latest yarn global add cf@latest pnpm add --global cf@latest bun add --global cf@latest Describe w…
Oct 15
Gateway and Workers integration is now in public beta
Cloudflare Gateway now integrates with Cloudflare Workers in public beta on all Zero Trust plans. You can use the Forward action in Gateway HTTP policies to run your own code on matching, permitted traffic without managing a separate proxy. The Forward action lets you transform HTTP requests and responses, return a coaching page, or run background tasks such as Slack notifications and R2 captures…
Oct 14
Workers Builds now uses newer versions of Node.js, Python, Go, Bun, and more
Your builds now run on newer versions of Node.js, Python, Ruby, Go, Bun, Yarn, and Python package managers by default, so you get the latest fixes and features without changing your build configuration. Runtimes Runtime Previous version New version Override with Node.js 24.18.0 24.21.0 NODE_VERSION Python 3.13.3 3.14.8 PYTHON_VERSION Ruby 3.4.7 3.4.11 RUBY_VERSION Go 1.24.3 1.27.2 GO_VERSION Tool…
Oct 13
Cloudflare API MCP server sends Workers Issues as MCP Events
Workers Issues provides built-in error monitoring for Cloudflare Workers. It detects production failures and groups related failures into issues without an SDK or application wrapper. The Cloudflare API MCP server now sends these issues as MCP Events ↗︎, the first event it exposes. MCP clients discover cloudflare.alert.workers_observability_real_time_issue with events/list and subscribe with even…
Oct 12
Run OpenCode 2.0 on Cloudflare with the Agents SDK
The Agents SDK now supports OpenCode 2.0 ↗︎ through the experimental OpenCodeHarness. Run OpenCode inside a plain Durable Object, with sessions stored in SQLite and Lifecycle jobs that wake interrupted work after eviction. The agents/models/opencode provider connects OpenCode to Workers AI through the AI binding. OpenCode plugins extend the harness with custom tools, remote MCP servers, and skill…
Oct 12
Workers Builds now posts preview URLs in seconds
Workers Builds now consistently posts preview URLs to GitHub pull requests and GitLab merge requests within a few seconds of a build completing, so you can start testing and reviewing your changes sooner. Previously, posting preview URLs could often take minutes. For details, refer to Workers Builds GitHub integration and Workers Builds GitLab integration.
Oct 12
More time for requests to finish during Workers runtime updates
Pending requests and connections to Workers now have a grace period of up to 20 minutes during Workers runtime updates. Previously, the grace period was up to 30 seconds. This gives long-running HTTP requests, streamed AI responses, and live WebSocket sessions more time to continue before an update interrupts them. New incoming HTTP requests go to the updated version of the Workers runtime once i…
Oct 8
Create Workflow instance batches by count or list
createBatch() now accepts an options object that creates up to 100 Workflow instances in one call. The result lists the created instances and explains why any others were not created. To use this form in local development and get its types from wrangler types, use Wrangler 4.148.0 or later. To create instances that share the same options, pass count. Each instance receives a generated ID: const r…
Oct 2
Run the Pi Durable harness on Cloudflare with the Agents SDK
The Agents SDK now provides first-class support for building agents using the Pi harness. You can build long-running agents using the combination of Pi 1.0 ↗︎, Pi Durable ↗︎, and the new PiHarness class that the Cloudflare Agents SDK provides, ensuring your agent's work is durably persisted, even if interrupted mid-turn. Built with Earendil ↗︎, this integration is our first step toward first-clas…
Oct 1
The best way to do MCP auth just got better: Workers OAuth Provider goes v1, with a new split API and full support for MCP 2026-07-28
@cloudflare/workers-oauth-provider ↗︎ is now v1, with a new split API. One Worker acts as the authorization server: it signs users in and issues tokens. Your MCP server acts as the resource server, and can run in another Worker. It validates each token with the authorization server over a Service Binding, without crossing the public Internet. It supports the MCP 2026-07-28 authorization specifica…
Oct 1
Artifacts is now in open beta
Artifacts, Cloudflare's versioned file system that speaks Git, is now in open beta. Artifacts is built for scale, so you can create a repository per project, user, session, or task. With Artifacts, you can: Deploy repositories to Workers — Connect an Artifacts repository through Workers Builds. Pushes to the production branch deploy the updated Worker, while other branches create or update Worker…
Oct 1
Web Crypto adds ML-KEM and ML-DSA support
The Workers Web Crypto API now supports ML-KEM-768, ML-KEM-1024, ML-DSA-44, ML-DSA-65, and ML-DSA-87. ML-KEM establishes shared secrets, while ML-DSA signs and verifies data. The opt-in API also adds key encapsulation and decapsulation methods, getPublicKey(), SubtleCrypto.supports(), and JSON Web Keys (JWKs) with the AKP key type. Turn on the webcrypto_modern_algorithms compatibility flag to use…

September 2026

Sep 29
Workers Cache — mark cached responses stale with invalidate()
Workers Cache now supports invalidate(), the soft counterpart of purge(). purge() deletes matching cached responses, so the next request is a cache miss. invalidate() keeps them but marks them stale, so the cache revalidates them with your Worker instead. To revalidate a response, the cache sends your Worker a conditional request built from the validators stored with it — for example, If-None-Mat…
Sep 28
Cloudflare CLI is now in beta
The Cloudflare CLI, cf, is now in beta. cf is one command-line interface for the public Cloudflare API and for Workers projects. Use it to manage zones, DNS, storage, and security settings, and to create, develop, and deploy Workers, without switching between tools. Install cf globally, then sign in: npmyarnpnpmbun npm install --global cf yarn global add cf pnpm add --global cf bun add --global c…
Sep 27
Call Workflows declared in `exports` through `ctx.exports`
A Worker can now call the Workflows it declares in the exports field of its Wrangler configuration through ctx.exports. You no longer need a workflows binding to call a Workflow from the Worker that defines it. Each Workflow is keyed by class name, and has the same API as a Workflow binding: src/index.jsjsexport default { async fetch(request, env, ctx) { const instance = await ctx.exports.MyWorkf…
Sep 25
Workers tracing — new getActiveSpan(), recordException(), startSpan(), and setAttributes() APIs
Custom spans in Workers now support more of the OpenTelemetry span API, so you can instrument more of your code and record errors directly on your spans. tracing.startSpan(name) creates a span without making it the active span, and returns it. Other spans do not nest under it. Call span.end() when the operation is complete. tracing.getActiveSpan() returns the currently active span. Use it to anno…
Sep 25
See every release and gradual deployment on Workers Metrics charts
Workers Metrics charts now show every release in the selected time range, including the full progression of gradual deployments. This makes it easier to correlate changes in memory, CPU time, errors, or latency with the code that was serving traffic. A gradual deployment appears as a single rollout across the chart, with shading that increases as more traffic moves to the new version. Hover over…
Sep 24
Declare Workflows in the `exports` configuration
You can now declare the Workflows a Worker defines in the exports field of your Wrangler configuration file. Previously, a Worker could only define a Workflow through a workflows binding, even when the Worker never called the Workflow itself. Key each entry by the name of the class that extends WorkflowEntrypoint: { "exports": { "MyWorkflow": { "type": "workflow", "name": "my-workflow", "limits":…
Sep 22
Workers Builds now supports Cursor Origin
Workers Builds now supports repositories hosted in Cursor Origin. Connect a Cursor Origin repository to automatically build and deploy production changes, preview non-production branches, and see build status in pull requests. Pushes to your production branch automatically build and deploy your Worker. When you enable non-production branch builds, each branch receives a version-specific preview U…
Sep 22
Test every pull request in an isolated environment with Worker Previews
You can now test every change you make in an isolated, production-like environment with Worker Previews ↗︎. Each Preview runs under the same Worker with its own code, configuration, URL, and observability, isolated from production and every other Preview. Configure each Preview Define the variables, bindings, and settings that new Previews start with in the previews block of your Wrangler configu…
Sep 21
Give teammates access to specific Workers directly from the dashboard
You can now grant teammates scoped access to specific Workers directly from the Workers dashboard. Go to your Worker and click Invite. Enter the teammate's email address, choose the appropriate access level, and click Invite. You can grant a user one of the following access levels: Metadata Read-Only: View settings, metrics, logs, and traces without access to Worker code or the ability to make ch…
Sep 17
Delete Workflow instances individually or in batches
You can now delete one or up to 100 Workflow instances and their stored state via the Workflows API or Wrangler 4.125.0 and later. Deleting an instance frees its stored state and stops its current execution. Storage billing is based on the average daily peak. Delete one instance by calling delete() on its handle: const instance = await env.MY_WORKFLOW.get("instance-abc"); await instance.delete();…
Sep 17
Workers traces now automatically include JavaScript RPC session spans
Workers traces can now follow JavaScript RPC calls across Worker boundaries and into Durable Objects. Previously, a trace stopped at the caller's RPC boundary. The dashboard now shows the caller-side session and method calls alongside the callee invocation, nested calls, and callbacks into another Worker. A session span covers the lifetime of a caller-side session and groups calls that reuse it.…
Sep 16
Hyperdrive support for Python Workers
Python Workers can now connect to PostgreSQL and MySQL through Hyperdrive. For setup, code examples, and limitations, refer to Use Hyperdrive from Python Workers.
Sep 15
Stream Workflow instance events in your Worker or via the API with .subscribe()
You can now stream Workflow instance events via WorkflowInstance.subscribe() and the GET /subscribe API endpoint. Workers and HTTP clients can react to workflow and step events, including attempts, sleeps, waits, and rollbacks, without polling for instance status. A subscription first streams the entire event history of the Workflow instance. After streaming past events, the subscription waits fo…
Sep 15
Grant teammates and agents access to specific Workers
You can now grant access to specific Workers and choose from four roles to control the level of access you give teammates, agents, and CI/CD workflows. Choose from four roles to control the level of access: Metadata Read-Only: View settings, metrics, logs, and traces without access to Worker code or the ability to make changes. Content Read-Only: Read Worker code, settings, and observability data…
Sep 8
Miniflare v5 prepares local development for the cf CLI
Miniflare v5 prepares Cloudflare local development tooling for the upcoming cf CLI. Miniflare powers local Workers development behind wrangler dev, the Cloudflare Vite plugin, and @cloudflare/vitest-plugin. Most projects should use those tools instead of depending on Miniflare directly, and Miniflare v5 will not require any action. The most significant change is a new configuration shape which al…
Sep 8
Python 3.14 for Python Workers
Python workers now use Python 3.14 by default. This change applies to all new Python workers using compatibility date 2026-09-08 or later. Internally, this change updates the Pyodide runtime to 314.0.6.
Sep 4
Manage Email Routing rules with Wrangler
You can now manage Email Routing rules that route emails to Workers from your Wrangler configuration. Add literal addresses or a catch-all address to the top-level addresses field: { "$schema": "./node_modules/wrangler/config-schema.json", "name": "invoice-handler", "main": "src/index.ts", // Set this to today's date "compatibility_date": "2026-10-30", "addresses": [ "invoice@yourdomain.com" ] }…
Sep 4
Enterprise customers can self-serve CDN upload limits up to 5 GB
Enterprise customers can now configure a zone's CDN Maximum Upload Size up to 5 GB directly from the Network page in the Cloudflare dashboard. This removes the need to contact your account team or Cloudflare Support when applications need to accept request bodies larger than 500 MB and no greater than 5 GB. The default maximum upload size remains 500 MB. Upload limits above 5 GB still require add…
Sep 4
Deploy larger Workers — up to 64 MiB for both free and paid plans
You can now deploy Workers with larger dependencies, heavier frameworks, and more code without hitting size limits. When you deploy a Worker, Wrangler bundles your code and compresses it before uploading. Previously, Cloudflare checked that compressed size and rejected deploys over 3 MB (Free) or 10 MB (Paid). That limit has been removed. Cloudflare now only checks the uncompressed size of your b…
Sep 2
Python Workers now support WSGI web frameworks like Django and Flask
Python web frameworks following the Web Server Gateway Interface (WSGI) ↗︎ or Asynchronous Server Gateway Interface (ASGI) ↗︎ specification can now be used in Python Workers. Using web frameworks with Python Workers Based on the web framework you are using, you can use either wsgi or asgi from the workers module. WSGI frameworks For WSGI frameworks like Django or Flask: from workers import wsgi f…

August 2026

Aug 28
Durable Objects can use up to ten Dynamic Workers concurrently
Durable Objects can have up to ten distinct Dynamic Workers with in-flight requests, increased from four. This limit applies across all concurrent requests to the same Durable Object because they share an input/output (I/O) context. Other Workers can have up to four distinct Dynamic Workers with in-flight requests per request. Multiple in-flight requests to the same Dynamic Worker count as one to…
Aug 24
Preserve exception details in console logs
Console methods now preserve exception details in your Worker's logs. When your Worker logs an exception, the corresponding log entry includes the exception name, message, and stack. For example, your Worker can catch and log an exception: try { throw new Error("Deliberately created exception"); } catch (error) { console.error("caught exception:", error); } try { throw new Error("Deliberately cre…
Aug 22
Choose OAuth scopes for Wrangler and the Cloudflare API MCP server
Wrangler and the Cloudflare API MCP server now use optional OAuth scopes. During authorization, you can choose which optional scopes to grant instead of approving every scope requested by each client. The consent dialog now includes the option to edit the permissions you grant to Wrangler or the Cloudflare API MCP server: You can then choose which specific permissions to grant: Required scopes re…
Aug 20
View deployments for Durable Objects in the dashboard
Durable Object namespaces now have a Deployments tab in the Cloudflare dashboard, showing the versions of the backing Worker that are currently live and the traffic split between them. Go to Durable Objects ↗ A Durable Object namespace is backed by a Worker script, so its deployments are the same as that Worker's deployments. Previously, checking on a gradual deployment in progress for a Durable…
Aug 19
AbortController and AbortSignal can be created at global scope
new AbortController(), AbortSignal.abort(), new WritableStream(), and request.signal no longer throw when used during module evaluation (that is, at the top level of your Worker module, outside of a request handler). Previously, these APIs required an active request context and would throw if called at the top level. // This now works — no error during module startup const controller = new AbortC…
Aug 19
Event and EventTarget spec compliance improvements
Several improvements bring the Workers runtime's Event, EventTarget, and related APIs closer to their web platform specifications. isTrusted is now correct for user-constructed events User-constructed event subclasses (new MessageEvent(...), new CustomEvent(...), new ErrorEvent(...), new CloseEvent(...)) now correctly report isTrusted as false. Previously, these incorrectly reported isTrusted as…
Aug 19
Spec-compliant dispatchEvent() exception handling
A new compatibility flag, spec_compliant_dispatch_exceptions, aligns the Workers runtime's event dispatch behavior with the DOM specification ↗︎. This flag becomes the default for all Workers with a compatibility date of 2026-09-15 or later. Previously, when an event listener threw an exception during dispatchEvent(), the runtime propagated the exception immediately and skipped all remaining list…
Aug 19
@cloudflare/vitest-pool-workers is now @cloudflare/vitest-plugin
Version 1 of the Workers Vitest integration is published as @cloudflare/vitest-plugin ↗︎. The package was formerly named @cloudflare/vitest-pool-workers. The Vitest configuration API is unchanged. Existing projects must update the dependency name, package imports, and TypeScript types entries. To migrate automatically, run: npmyarnpnpm npx @cloudflare/codemods vitest:pool-workers-to-vitest-plugin…
Aug 18
Connect handler no longer requires an experimental flag
Workers can now export a connect() handler without enabling any compatibility flag. Previously, using a connect() handler required the experimental compatibility flag, which cannot be enabled in production. A connect() handler lets a Worker accept a TCP connection forwarded from another Worker over a service binding, and read and write raw bytes on it using a Socket object: backend-worker.jsjsexp…
Aug 14
You can now enable Access on a Worker or all Workers at once
You now have two new ways to protect your Workers with Cloudflare Access. Protect an application across all its domains at once Until now, if a Worker was reachable on a route, a Custom Domain, and a workers.dev URL, you had to manually add each one to an Access application and keep the list in sync whenever routes or domains changed. Now, Access attaches the policy to the Worker itself, so every…
Aug 4
Cloudflare Agents: trace every model call, tool run, and decision
Cloudflare Agents ↗︎ now has a dedicated home in the Cloudflare dashboard that lists your traced agents and subagents. Select an agent to inspect its traces in two ways: Replay a session assembles the full conversation for a turn: system instructions, user messages, model reasoning, tool calls with arguments and results, and the final response. View a trace shows the execution timeline, connectin…
Aug 4
AI agents can debug Workers with local tracing
wrangler dev and vite dev automatically capture structured OpenTelemetry traces and correlated console logs during local Worker invocations. Debug with AI agents When the tooling detects an AI agent session, it prints a terminal hint pointing to the Local Explorer API at /cdn-cgi/local/explorer/api. The API serves an OpenAPI schema and exposes a read-only observability query endpoint for discover…
Aug 4
Node.js compatibility is now enabled by default
Workers now enable the nodejs_compat and nodejs_compat_v2 compatibility flags by default for compatibility dates of 2026-08-04 or later. These flags are not used for these compatibility dates because the compatibility date enables the same behavior. This means all Node.js built-in APIs supported by the Workers runtime are available by default, including node:crypto, node:buffer, node:stream, node…
Aug 4
Log in to Wrangler without a local callback server
wrangler login now supports the OAuth 2.0 Device Authorization Grant ↗︎. Pass --device to authenticate without starting a temporary callback server on localhost:8976: npx wrangler login --device Wrangler prints a verification URL and a short user code, opens the URL in your default browser with the code already filled in, and polls Cloudflare for an access token while you approve the request: ⛅️…
Aug 3
Preview: @cloudflare/computer agent runtime
We're releasing an early preview of @cloudflare/computer ↗︎, an open-source agent runtime that gives every agent its own computer. The runtime dynamically orchestrates between fast, efficient isolates and full Linux containers, so the agent always runs on the right compute primitive for the task at hand. @cloudflare/computer provides a virtual filesystem backed by SQLite, which you can populate f…
Aug 3
Python and JavaScript Workers can now call each other via RPC
You can now call methods between Python and JavaScript Workers using Workers RPC. This works through Service bindings without extra dependencies, schema definitions, or serialization code. Cross-language RPC calls behave like ordinary function calls. Exceptions propagate to the call site. You can pass structured cloneable types ↗︎ as parameters or return values, and Pyodide Foreign Function Inter…

July 2026

Jul 31
Inspect Worker startup performance with Wrangler
wrangler check startup now reports your Worker's raw and compressed bundle sizes. It also summarizes local CPU activity during startup directly in your terminal. Large bundles and costly startup work can introduce cold-start latency, so use this command to find code and large dependencies that slow your Worker before it handles requests. The summary includes sampled, active, garbage collection, a…
Jul 30
Node.js 24 is now the default for Workers Builds
Workers Builds now uses Node.js 24.18.0 by default. The build image preinstalls Node.js 22.23.2 and 24.18.0. You can continue to override the default with the NODE_VERSION environment variable, an .nvmrc file, or a .node-version file. For more information, refer to Override default versions.
Jul 28
Cloudflare MCP servers support the new MCP 2026-07-28 Specification
Cloudflare's product-specific MCP servers now support the new MCP 2026-07-28 Specification. Each request runs on a fresh stateless server without an MCP protocol session or protocol-specific Durable Object. The /mcp endpoint also accepts stateless requests from 2025 Streamable HTTP clients. Most clients can reconnect without configuration changes. Use /mcp for new connections. Historical /sse URL…
Jul 28
Workers tracing — write custom spans with new startActiveSpan() and span.end() runtime APIs
The Workers runtime now provides built-in tracing.startActiveSpan() and span.end() APIs, allowing you to write custom spans for operations that last beyond a single callback — for example, instrumenting a stream pipeline where the span should stay open until the stream is fully consumed. This augments the existing API for writing custom spans, tracing.enterSpan(), which automatically ends a span…
Jul 27
Agents SDK adds MCP Specification 2026-07-28 support
Agents SDK v0.20.0 adds client and server support for the MCP 2026-07-28 release candidate ↗︎. Workers can serve tools, prompts, resources, and elicitation without an MCP transport session or Durable Object. Agents can connect to both MCP 2026-07-28 servers and existing legacy servers. Client support The MCP client manager now uses @modelcontextprotocol/client. For each connection, it probes for…
Jul 27
Run integration tests against your Worker's production build
Wrangler now provides createTestHarness(), an API for running integration tests against Workers built with Wrangler or the Cloudflare Vite plugin from any Node.js test runner. The test harness starts a local Worker server with helpers for dispatching requests, resetting storage, and inspecting runtime logs. This is useful for tests that need to: Route requests across multiple Workers Mock outboun…
Jul 24
Filter Durable Object logs and traces by instance ID
Workers Logs and OpenTelemetry spans for Durable Object requests include the Durable Object instance ID. Use $workers.durableObjectId to filter logs for a specific instance. Root and child spans include the same ID in cloudflare.durable_object.id. Use these fields to isolate a specific instance and correlate its logs and traces. For more information, refer to Durable Objects metrics and analytics…
Jul 24
Workers Builds now skips superseded queued builds
Workers Builds now automatically skips a queued build when a newer build for the same build trigger is also queued.
Jul 22
Agents SDK reduces MCP schema conversion, adds exposure controls for MCP in Think and Code Mode SDK adds direct host APIs
This release reduces repeated MCP schema conversion and adds an opt-out for Think's automatic MCP tool exposure. It also lets non-AI-SDK hosts invoke the durable Code Mode runtime directly. Control direct MCP tool exposure in Think Agents SDK MCP clients now reuse converted input and output schemas while a live connection keeps the same tool catalog. This avoids converting every MCP JSON Schema t…
Jul 20
Budget alerts now on by default for Pay-as-you-go accounts
We are turning on budget alerts by default for eligible Pay-as-you-go accounts. If your account does not already have a budget alert, Cloudflare will create one for you with a $10 account-level threshold. Your default alert will enable at the turn of your next billing cycle, so it will not fire based on usage you have already incurred. We are rolling this out in cohorts over the coming weeks, so…
Jul 20
View total SQLite storage for Durable Object namespaces
You can now monitor the total SQLite storage used by a Durable Object namespace over time in the Cloudflare dashboard. The new Total storage chart shows the maximum storage reported during each hour. This helps you identify storage growth, validate data cleanup, and investigate unexpected usage. Go to Durable Objects ↗ The chart appears only for SQLite-backed Durable Object namespaces. It does no…
Jul 14
Platforms can now create Temporary Accounts via the Cloudflare API
Platforms can now create temporary preview accounts through the Cloudflare REST API. This lets your platform deploy a live Worker before the user signs in to Cloudflare. With the Temporary Accounts API, coding agents, AI app builders, and other platforms can build a similar flow for generated Workers and supported resources. Your platform can keep users in its onboarding flow while they generate,…
Jul 13
Agents can respond to MCP elicitation requests
Agents connected to Model Context Protocol (MCP) servers with addMcpServer can now handle elicitation ↗︎ requests. Elicitation lets an MCP server request user input while it handles a tool call. Form mode collects structured, non-sensitive data. URL mode asks for consent before opening an out-of-band flow, such as third-party authorization or payment. sequenceDiagram participant User participant…
Jul 9
New Durable Object namespaces must use the SQLite storage backend
If your account does not already have a key-value (KV) backed Durable Object namespace, you can no longer create new ones. New Durable Object namespaces must use the SQLite storage backend, which has been recommended for all new Durable Objects since it became generally available ↗︎ in 2024. Create a new class with a new_sqlite_classes migration: { "$schema": "./node_modules/wrangler/config-schem…
Jul 9
Send npm package dependency metadata with Worker uploads
Wrangler now collects npm package dependency information from your project's package.json during wrangler deploy and wrangler versions upload, and includes it in the upload metadata sent to the Cloudflare API. This data, each dependency's name, declared version range, and exact installed version, enables dependency analytics and future supply chain security features such as vulnerability alerting…
Jul 8
Cloudflare Drop
Cloudflare Drop ↗︎ lets you deploy a static site to Cloudflare without requiring a Cloudflare account to get started. Upload a folder or zip file of static assets (static HTML, CSS, JavaScript, images, and fonts) and get a temporary live preview that stays live for 1 hour. During that window, you can test the site, share the preview URL, or claim the deployment to keep it. When you are ready to m…
Jul 7
Workers Observability now surfaces warning attributes on spans for non-fatal errors
Workers Observability now attaches warning attributes to spans for non-fatal telemetry issues. These attributes help you identify instrumentation issues. When a warning is present, both attributes are set together: cloudflare.warning.type — An identifier indicating the type of warning condition. cloudflare.warning.message — A free-form, human-readable explanation of the warning condition. For exa…
Jul 4
Declare Durable Object class lifecycle with `exports`
A new declarative exports field in your Wrangler configuration file replaces the imperative migrations array for managing Durable Object class lifecycle. Instead of writing an ordered list of migration steps with unique tags, you declare each Durable Object class your Worker exports and Cloudflare compares that against what's already deployed to determine what Durable Object state needs to be cre…
Jul 3
Simpler runtime types with @cloudflare/workers-types v5
We have released version 5 of @cloudflare/workers-types ↗︎. This release simplifies the package to expose only the latest runtime types. We still recommend that you generate types for your Worker using wrangler types, but if you want to use the package directly, you can install it with your package manager of choice: npmyarnpnpmbun npm i -D @cloudflare/workers-types@latest yarn add -D @cloudflare…
Jul 2
Work across multiple accounts with Wrangler auth profiles
Wrangler CLI now supports auth profiles: named logins that you scope to specific Cloudflare accounts and switch between automatically, based on the directory you are working in. A profile is a named OAuth login bound to a directory. Commands run in that directory, and its subdirectories, use the matching account — so you can move between accounts without re-running wrangler login. Use profiles to…

June 2026

Jun 30
Track memory usage for Workers and Durable Objects in the dashboard
You can now monitor how much memory your Workers and Durable Objects consume across invocations with the new Memory Usage chart in the Workers Metrics tab, broken down by P50, P90, P99, and P999 percentiles. Memory usage measures the V8 isolate memory at the time of each invocation, subject to the 128 MB per-isolate limit — a single isolate can handle many concurrent requests and shares memory ac…
Jun 28
Workers fetch requests now support cf.vary
Workers fetch() requests now support the cf.vary request option. Use cf.vary to control how Cloudflare caches origin responses with a Vary header for a single subrequest. src/index.jsjsexport default { async fetch(request) { return fetch(request, { cf: { vary: { default: { action: "bypass" }, headers: { accept: { action: "normalize", media_types: ["text/html", "application/json"], }, "accept-lang…
Jun 26
Agents SDK adds background sub-agents and a unified turn entry point
The latest release of the Agents SDK ↗︎ makes it easier to run long work in the background, drive turns through one entry point, and keep chat agents working through deploys, evictions, and reconnects. This release adds first-class detached (background) sub-agent runs with live progress and durable milestones, a single runTurn turn-admission entry point, and a large round of recovery and reliabil…
Jun 26
New `us` jurisdiction for Durable Objects
Durable Objects now supports a us jurisdiction, letting you create Durable Objects that only run and store data within the United States. Use the us jurisdiction when you need to keep a Durable Object's compute and storage inside the United States to meet data residency requirements. Create a namespace restricted to the us jurisdiction the same way as any other jurisdiction: // Worker export defa…
Jun 25
Test Durable Object eviction with new cloudflare:test helpers
The @cloudflare/vitest-pool-workers package now includes evictDurableObject and evictAllDurableObjects test helpers, exported from cloudflare:test. These helpers let you test how a Durable Object behaves across evictions, simulating the production lifecycle where an idle Durable Object can be evicted from memory. For more context, refer to Lifecycle of a Durable Object. import { evictDurableObjec…
Jun 19
New Asia-Pacific location hints: apac-ne and apac-se
Durable Objects now supports two new location hints for Asia-Pacific: apac-ne (Northeast Asia-Pacific) and apac-se (Southeast Asia-Pacific). Use apac-ne or apac-se when you want finer-grained placement within Asia-Pacific rather than the broader apac hint. Use the new hints the same way as any other locationHint: // Northeast Asia-Pacific (Japan, Korea, etc.) const stubNE = env.MY_DURABLE_OBJECT.…
Jun 19
Temporary accounts for AI agent deployments
AI agents can now deploy Workers to Cloudflare without first requiring a user to sign up, open a browser-based OAuth flow, click through the dashboard, or create an API token. When an agent tries to deploy without Cloudflare credentials, Wrangler can tell it to rerun with --temporary, then deploy the Worker to a temporary preview account. To try this with your agent, update to Wrangler 4.102.0 or…
Jun 18
Create PlanetScale Postgres and MySQL databases, billed to your Cloudflare account
You can create PlanetScale Postgres and MySQL databases from Cloudflare and bill PlanetScale database usage through your Cloudflare account as a pay-as-you-go customer. Cloudflare contract customers will be able to add PlanetScale usage to their contract in July so reach out to your Cloudflare account team if interested. Create a PlanetScale database from the Cloudflare dashboard to check out glo…
Jun 16
Agents SDK improves browser automation, code execution, and recovery
The latest release of the Agents SDK ↗︎ makes it easier to build agents that can safely interact with real systems and keep working through interruptions. Agents can now browse websites through Browser Run, write code against external tools through Code Mode, use client-provided tools when delegating to Think sub-agents, and recover more reliably from deploys, Durable Object evictions, and connec…
Jun 16
Introducing GLM-5.2 on Workers AI
We are excited to announce GLM-5.2 on Workers AI, Z.ai's flagship agentic coding model. @cf/zai-org/glm-5.2 is a text generation model built for agentic coding workflows. With function calling and reasoning support, it can handle long codebases, multi-step planning, and tool-augmented agents. Key features and use cases: Agentic coding: Designed for autonomous coding tasks, long-horizon planning,…
Jun 16
Workers tracing now supports custom spans
You can now create custom trace spans in your Workers code using tracing.enterSpan(). Custom spans appear alongside the automatic platform instrumentation (fetch calls, KV reads, D1 queries, and other platform operations) in your traces and OpenTelemetry exports, with correct parent-child nesting. The API is available via import { tracing } from "cloudflare:workers" or through the handler context…
Jun 12
Filter Durable Objects metrics by object ID or name
You can now filter the Metrics tab for a Durable Objects namespace by an individual Durable Object's ID or name in the Cloudflare dashboard. Previously, metrics charts only showed aggregate, namespace-level data, making it difficult to isolate the behavior of a specific object. Go to Durable Objects ↗ Start typing an ID or name into the filter and select a match from the autocomplete dropdown. Th…
Jun 11
Track Dynamic Workers usage from the dashboard and GraphQL API
Customers can now view the number of Dynamic Workers invoked during their billing period from the Workers overview page in the Cloudflare dashboard. This count reflects the number of Dynamic Workers that Cloudflare would bill for during the selected billing period. Dynamic Workers usage data only goes back to June 1, 2026. You can also query this count through the GraphQL Analytics API by using w…

Workers

Pricing and limits

Pricing

Workers

Example pricing

Example 1

Example 2

Example 3

Example 4

Example 5: Worker with caching

How to switch usage models

Workers Logs

Workers Trace Events Logpush

Workers KV

Hyperdrive

Footnotes

Queues

Workflows

D1

Definitions

Durable Objects

Compute billing

Storage billing

SQLite storage backend

Key-value storage backend

Vectorize

Calculating vector dimensions

R2

Containers

Network Egress

Service bindings

Fine Print

Limits

Account plan limits

Request and response limits

CPU time

Error: exceeded CPU time limit

Increasing the CPU time limit

Monitoring CPU usage

Memory

Error: exceeded memory limit

Duration

Runtime updates

Daily requests

Subrequests

Worker-to-Worker subrequests

Simultaneous open connections

Environment variables

Worker size

Worker startup time

Number of Workers

Routes and domains

Routes with wrangler dev --remote

Cache API limits

Log size

Image Resizing with Workers

Static Assets

Unbound and Bundled plan limits

Wall time limits by invocation type

Related resources

Footnotes

Timeline

November 2026

October 2026

September 2026

August 2026

July 2026

June 2026

Routes with `wrangler dev --remote`