Cloudflare

Full Changelog: https://github.com/cloudflare/workerd/compare/v1.20260606.1...v1.20260607.1

Full Changelog: https://github.com/cloudflare/workerd/compare/v1.20260605.1...v1.20260606.1

Workflows now supports saga-style rollbacks, allowing you to add compensating logic to each step.do() in case of downstream failures. If the instance fails, the rollback handlers will execute in reverse step-start order.

This is useful for multi-step operations that touch external systems, such as inventory reservations, payment authorization, ticket creation, or infrastructure provisioning. Instead of writing all cleanup logic in a top-level catch, you can keep each compensating action next to the step it undoes.

Rollback handlers support their own retry and timeout configuration, and Workflows now exposes rollback outcomes in instance status responses. Workflows analytics also emits rollback lifecycle events, making it easier to distinguish a forward execution failure from a rollback failure when debugging production workflows.

• JavaScript

  <div><div><span>await</span><span> </span><span>step</span><span>.</span><span>do</span><span>(</span></div></div><div><div><span>  </span><span>"provision resource"</span><span>,</span></div></div><div><div><span>  </span><span>async</span><span> </span><span>()</span><span> </span><span>=></span><span> </span><span>{</span></div></div><div><div><span>    </span><span>const</span><span> </span><span>resource</span><span> </span><span>=</span><span> </span><span>await</span><span> </span><span>provisionResource</span><span>()</span><span>;</span></div></div><div><div><span>    </span><span>return</span><span> </span><span>{</span><span> resourceId</span><span>:</span><span> </span><span>resource</span><span>.</span><span>id</span><span> </span><span>};</span></div></div><div><div><span>  </span><span>},</span></div></div><div><div><span>  </span><span>{</span></div></div><div><div><span>    </span><span>rollback</span><span>:</span><span> </span><span>async</span><span> </span><span>({</span><span> </span><span>output</span><span> </span><span>})</span><span> </span><span>=></span><span> </span><span>{</span></div></div><div><div><span>      </span><span>const</span><span> </span><span>{</span><span> </span><span>resourceId</span><span> </span><span>}</span><span> </span><span>=</span><span> </span><span>output</span><span>;</span></div></div><div><div><span>      </span><span>await</span><span> </span><span>deleteResource</span><span>(</span><span>resourceId</span><span>)</span><span>;</span></div></div><div><div><span>    </span><span>},</span></div></div><div><div><span><span>    </span></span><span>rollbackConfig</span><span>:</span><span> </span><span>{</span></div></div><div><div><span><span>      </span></span><span>retries</span><span>:</span><span> </span><span>{</span><span> limit</span><span>:</span><span> </span><span>3</span><span>,</span><span> delay</span><span>:</span><span> </span><span>"15 seconds"</span><span>,</span><span> backoff</span><span>:</span><span> </span><span>"linear"</span><span> </span><span>},</span></div></div><div><div><span><span>      </span></span><span>timeout</span><span>:</span><span> </span><span>"2 minutes"</span><span>,</span></div></div><div><div><span>    </span><span>},</span></div></div><div><div><span>  </span><span>},</span></div></div><div><div><span>)</span><span>;</span></div></div>

• TypeScript

  <div><div><span>await</span><span> </span><span>step</span><span>.</span><span>do</span><span>(</span></div></div><div><div><span>  </span><span>"provision resource"</span><span>,</span></div></div><div><div><span>  </span><span>async</span><span> </span><span>()</span><span> </span><span>=></span><span> </span><span>{</span></div></div><div><div><span>    </span><span>const</span><span> </span><span>resource</span><span> </span><span>=</span><span> </span><span>await</span><span> </span><span>provisionResource</span><span>()</span><span>;</span></div></div><div><div><span>    </span><span>return</span><span> </span><span>{</span><span> resourceId</span><span>:</span><span> </span><span>resource</span><span>.</span><span>id</span><span> </span><span>};</span></div></div><div><div><span>  </span><span>},</span></div></div><div><div><span>  </span><span>{</span></div></div><div><div><span>    </span><span>rollback</span><span>:</span><span> </span><span>async</span><span> </span><span>({</span><span> </span><span>output</span><span> </span><span>})</span><span> </span><span>=></span><span> </span><span>{</span></div></div><div><div><span>      </span><span>const</span><span> </span><span>{</span><span> </span><span>resourceId</span><span> </span><span>}</span><span> </span><span>=</span><span> </span><span>output</span><span> </span><span>as</span><span> </span><span>{</span><span> </span><span>resourceId</span><span>:</span><span> </span><span>string</span><span><span> </span><span>};</span></span></div></div><div><div><span>      </span><span>await</span><span> </span><span>deleteResource</span><span>(</span><span>resourceId</span><span>)</span><span>;</span></div></div><div><div><span>    </span><span>},</span></div></div><div><div><span><span>    </span></span><span>rollbackConfig</span><span>:</span><span> </span><span>{</span></div></div><div><div><span><span>      </span></span><span>retries</span><span>:</span><span> </span><span>{</span><span> limit</span><span>:</span><span> </span><span>3</span><span>,</span><span> delay</span><span>:</span><span> </span><span>"15 seconds"</span><span>,</span><span> backoff</span><span>:</span><span> </span><span>"linear"</span><span> </span><span>},</span></div></div><div><div><span><span>      </span></span><span>timeout</span><span>:</span><span> </span><span>"2 minutes"</span><span>,</span></div></div><div><div><span>    </span><span>},</span></div></div><div><div><span>  </span><span>},</span></div></div><div><div><span>)</span><span>;</span></div></div>

Refer to rollback options to learn more.

Workers using a VPC Network binding with network_id: "cf1:network" now egress to public Internet destinations through Cloudflare Gateway. This means your existing Zero Trust traffic policies — DNS, HTTP, Network, and egress — extend to traffic that originates from your Workers, the same way they do for WARP users today.

1. Worker

   Calls env.EGRESS.fetch()

2. VPC binding ↓

3. Cloudflare Mesh

   Bind via cf1:network

4. ↓

5. Cloudflare Gateway

   Policies applied:

   DNS HTTP Network

6. ↓

7. ↗ Public Internet

   Any public hostname or IP

Gateway logs DNS HTTP Network

What you get by default:

• Visibility. Worker egress shows up in Gateway DNS, HTTP, and Network logs alongside your other traffic, so you can audit what your Workers are calling and when.

• Enforcement. Any existing Gateway policy whose selectors match a Worker request will apply — including allow / block lists, DNS category filtering, and HTTP destination rules. If you have already blocked a category for your workforce, your Workers inherit that block.

• wrangler.jsonc

  <div><div><span>{</span></div></div><div><div><span>  </span><span>"</span><span>vpc_networks</span><span>"</span><span>:</span><span> </span><span>[</span></div></div><div><div><span>    </span><span>{</span></div></div><div><div><span>      </span><span>"</span><span>binding</span><span>"</span><span>:</span><span> </span><span>"EGRESS"</span><span>,</span></div></div><div><div><span>      </span><span>"</span><span>network_id</span><span>"</span><span>:</span><span> </span><span>"cf1:network"</span><span>,</span></div></div><div><div><span>      </span><span>"</span><span>remote</span><span>"</span><span>:</span><span> </span><span>true</span><span>,</span></div></div><div><div><span>    </span><span>},</span></div></div><div><div><span>  </span><span>],</span></div></div><div><div><span>}</span></div></div>

• wrangler.toml

  <div><div><span>[[</span><span>vpc_networks</span><span>]]</span></div></div><div><div><span>binding</span><span> </span><span>=</span><span> </span><span>"EGRESS"</span></div></div><div><div><span>network_id</span><span> </span><span>=</span><span> </span><span>"cf1:network"</span></div></div><div><div><span>remote</span><span> </span><span>=</span><span> </span><span>true</span></div></div>

• JavaScript

  <div><div><span>// Egress to a public destination — subject to your Gateway policies and logged</span></div></div><div><div><span>const</span><span> </span><span>response</span><span> </span><span>=</span><span> </span><span>await</span><span> </span><span>env</span><span>.</span><span>EGRESS</span><span>.</span><span>fetch</span><span>(</span><span>"https://api.example.com/data"</span><span>)</span><span>;</span></div></div>

• TypeScript

  <div><div><span>// Egress to a public destination — subject to your Gateway policies and logged</span></div></div><div><div><span>const</span><span> </span><span>response</span><span> </span><span>=</span><span> </span><span>await</span><span> </span><span>env</span><span>.</span><span>EGRESS</span><span>.</span><span>fetch</span><span>(</span><span>"https://api.example.com/data"</span><span>)</span><span>;</span></div></div>

For configuration options, refer to VPC Networks. For policy authoring, refer to Cloudflare Gateway traffic policies.

Radar now provides finer-grained traffic charts for longer time ranges. Previously, selecting a 1-3 month view on HTTP and NetFlows charts defaulted to weekly aggregation, which was too coarse to surface meaningful trends. Views longer than 3 months defaulted to monthly aggregation, returning as few as 7 data points for a 6-month range.

The new defaults are:

• 1-3 months: daily granularity (7x more data points)
• Longer than 3 months (HTTP and NetFlows): weekly granularity (4x more data points)

For example, a 12-week traffic view previously showed weekly data:

The same view now shows daily data:

Similarly, a 1-year HTTP traffic view that previously showed just 12 monthly data points now provides 52 weekly data points.

Visit Cloudflare Radar to explore the new granular views.

AI Gateway now supports spend limits — cost-based budgets that track cumulative dollar spend and block requests when the budget is exceeded. Unlike rate limiting, which caps the number of requests, spend limits track actual cost based on token usage and model pricing.

You can scope limits by model, provider, or custom metadata dimensions. For example, give each user a $200/day budget, cap total gateway spend at $10,000/day, or limit a specific model to $50/day per user. Each rule uses a configurable time window with fixed or sliding enforcement.

Spend limits work with both Unified Billing and BYOK requests for models with known pricing.

For more details, refer to the Spend limits documentation.

Cloudflare Access now supports IdP federation, which allows organizations to share a single identity provider across multiple Cloudflare accounts.

Instead of configuring the same IdP (for example, Okta or Entra ID) separately in every account, you configure it once in a source account and share it with the other accounts in your organization. Each recipient account gets a read-only IdP connection that routes authentication back to the source account through a bridge — a hidden application in the source account that brokers the cross-account login. End users sign in with their existing IdP credentials, and each account's Access policies evaluate the resulting identity just like any other IdP login.

Key capabilities:

• One IdP, many accounts — Configure your IdP once and share it with all accounts in your organization.
• Lifecycle management — As accounts join or leave your Cloudflare organization, their IdP connections are provisioned and removed automatically — no manual cleanup required.
• Immutable recipient connections — IdP connections in recipient accounts cannot be accidentally modified or deleted.

To get started, refer to IdP federation.

Pay-as-you-go customers can now view billable usage and create budget alerts directly from the product overview pages for Workers & Pages, D1, R2, Workers KV, Queues, Vectorize, Durable Objects, and Containers. A new sidebar widget shows current-period spend and the billing cycle date range, alongside a button to create a budget alert.

The widget pulls from the same data as the Billable Usage dashboard and aligns to your billing cycle (or the current day on Free plans), so the numbers match your invoice. Enterprise contract accounts are not yet supported.

Selecting Create budget alert opens the budget alert flow inline so you can set a dollar threshold in the same place you are reviewing usage. Budget alerts apply to your total account-level spend across all products, not just the product page you create them from.

For more information, refer to the Usage-based billing documentation.