Gradually deploy changes to Workers and Durable Objects

1. The current version of your application runs in production.
2. You deploy the new version of your application to production, but only route a small percentage of traffic to this new version, and wait for it to “soak” in production, monitoring for regressions and bugs. If something bad happens, you’ve caught it early at a small percentage (e.g. 1%) of traffic and can revert quickly.
3. You gradually increment the percentage of traffic until the new version receives 100%, at which point it is fully rolled out.

• You can filter analytics in the Workers dashboard and via the GraphQL Analytics API by version.
• Workers Trace Events and Tail Worker events include the version ID of your Worker, along with optional version message and version tag fields.
• When using wrangler tail to view live logs, you can view logs for a specific version.
• You can access version ID, message, and tag from within your Worker’s code, by configuring the Version Metadata binding.

• Version Overrides. Invoke a specific version of your Worker in order to test before it serves any production traffic. This will allow you to create Blue-Green Deployments.
• Cloudflare Pages. Let the CI/CD system in Pages automatically progress the deployments on your behalf.
• Automatic rollbacks. Roll back deployments automatically when the error rate spikes for a new version of your Worker.

Source mapped stack traces in Tail Workers

Unexpected input value: null
  at parseBytes (src/down.ts:30:8)
  at down_default (src/down.ts:10:19)
  at Object.fetch (src/index.ts:11:12)

1. When you set upload_source_maps = true in your wrangler.toml, Wrangler will automatically generate and upload any source map files when you run wrangler deploy or wrangler versions upload.
2. When your Worker throws an uncaught exception, we fetch the source map and use it to map the stack trace of the exception back to lines of your Worker’s original source code.
3. You can then view this deobfuscated stack trace in real-time logs or in Tail Workers.

New Rate Limiting API in Workers

[[unsafe.bindings]]
name = "RATE_LIMITER"
type = "ratelimit"
namespace_id = "1001" # An identifier unique to your Cloudflare account

# Limit: the number of tokens allowed within a given period, in a single Cloudflare location
# Period: the duration of the period, in seconds. Must be either 60 or 10
simple = { limit = 100, period = 60 } 

export default {
  async fetch(request, env) {
    const { pathname } = new URL(request.url)

    const { success } = await env.RATE_LIMITER.limit({ key: pathname })
    if (!success) {
      return new Response(`429 Failure – rate limit exceeded for ${pathname}`, { status: 429 })
    }

    return new Response(`Success!`)
  }
}

New auto-generated SDKs for Cloudflare’s API

// Typescript
npm install cloudflare

// Python
pip install --pre cloudflare

// Go
go get -u github.com/cloudflare/cloudflare-go/v2

Durable Object namespace analytics and WebSocket Hibernation GA

One of our new capabilities is Confluence whiteboards, which provides a freeform way to capture unstructured work like brainstorming and early planning before teams document it more formally. The team considered many options for real-time collaboration and ultimately decided to use Cloudflare’s Durable Objects. Durable Objects have proven to be a fantastic fit for this problem space, with a unique combination of functionalities that has allowed us to greatly simplify our infrastructure and easily scale to a large number of users. - Atlassian

Production ready, without production complexity