Last week was Cloudflare’s Agents Week, a marathon of announcements focused on the Agentic Era. I covered the news daily, but there was a lot to track. I’ve condensed those 5,500 words across the week into this 6-minute guide. Let’s dive in.

🏗️ The Agentic Backbone

Durable Object Facets
Durable Object Facets allow any Durable Object to create child Durable Objects on-the-fly using Dynamic Workers, with each Facet having its own isolated storage.

This allows novel use cases like AI agents writing their own tools that can store data related to that tool’s use.

Project Think
Project Think provides a new base class in Cloudflare’s Agents SDK that gives you a highly opinionated agent harness to use out of the box. It implements the agentic loop, message persistence, streaming, tool execution, stream resumption, and extensions.

You get all of this with 3 lines of code with customization possible.

There’s several new primitives in the Agents SDK too:

• Fibers allow you to recover from failure for long-running tasks that may take hours or even days.

• Subagents using Durable Objects Facets.

• Sessions change how conversations are stored from a flat list to a tree structure with full-text search across conversation history via FTS5.

• ExtensionManager allows an AI agent to self-author its own extensions. Define the extensions and the agent will write its own tools, which will be executed in a Dynamic Worker.

Voice Agents
Agents SDK now has a VoiceAgent class, which handles speech-to-text (STT), text-to-speech (TTS), conversation persistence and support for React as well as a framework-agnostic client.

It includes everything you’d expect from a voice agent, such as real-time audio, persistence for audio, output audio streaming, utterance detection and hooks to intercept and transform text during a conversation.

Agent Memory
Agent Memory from Cloudflare will be a fully managed solution to give AI agents long term memory, with an opinionated approach and API.

Agent Memory will then handle:

• Ingestion of messages that belong to a conversation

• Classification of memories (facts, events, instructions or tasks)

• Explicit storage of key information

• Recall, with Agent Memory determining the most useful results

Containers & Sandboxes are Generally Available
Dynamic Workers are incredibly lightweight, with start up times in single-digit milliseconds. They don’t work for all sandboxing use cases though, and that’s where Sandboxes and Containers come in.

They have a ton of features, such as PTY support, filesystem watching, snapshots and persistent code interpreters. Additionally, you can keep your secrets from ever being visible to your AI agent by using Outbound Workers in conjunction with a sandbox, which acts as an egress proxy.

🛡️ AI Agent Connectivity & Security

CodeMode for MCP Server Portals
Code Mode is an approach to MCP that replaces every tool in an MCP server with just two: search and execute. The client then searches for what endpoints it needs, and writes typed code against those endpoints, which it can then execute in a sandbox safely.

Code Mode is now available with Cloudflare’s MCP Server Portals, significantly reducing the cost when integrating with multiple MCP servers.

A Unified AI Gateway
You can now call pretty much any LLM provider using the same Workers AI binding that natively-hosted Cloudflare models use - without needing an API key for individual providers.

Cloudflare will bill you for the usage directly. There are 70+ models across 12+ providers available right now from all the names you’d expect.

Additionally, in the future, you’ll be able to run AI models directly on Cloudflare that you have built using Replicate’s Cog technology.

Cloudflare Mesh
Imagine you have a bunch of devices, some are servers in data centers, plus your laptops and phones. You want all of them to communicate with each other privately and securely, like they’re all on the same home Wi-Fi network, even though they’re scattered across the world.

That’s what Cloudflare Mesh does - no VPN required. For an extra layer of security, everything is post-quantum encrypted.

With the introduction of Mesh comes support for Workers VPC bindings. You can connect any Worker or Durable Object to a Mesh node via the binding using its IP address, or to a Cloudflare Tunnel with a tunnel ID.

Managed OAuth for Cloudflare Access
Cloudflare Access is a product from Cloudflare that allows you to control who can access your internal company applications and services.

Managed OAuth is built for AI agent auth. Enable it on any Access app, and Cloudflare Access becomes an OAuth authorization server. Agents can automatically discover how to authenticate, send the human through a PKCE flow, then the AI agent receives a scoped token to make requests on the user’s behalf.

🛠️ Agent Toolbox & Developer Platform

Artifacts: Git-compatible Versioned Storage
Artifacts is a brand new product from Cloudflare that allows you to create an unlimited number of repos to store your code, versioned and Git-compatible.

You can create, fork and import a repo, interact with Artifacts via binding or API and connect to a repo using a Git client.

Email Service Public Beta
Email Sending is now available to send transactional emails, both via a new binding as well as REST API.

Setup is easy, you just onboard a domain in the dashboard, add the email binding, then you can send emails with a single line of code. Keep in mind that only transactional use cases are allowed.

Domain Registrar API Beta + MCP
The Registrar API makes it possible to search for domains, check availability, and register them programmatically. There’s three endpoints at launch:

• Search, to find domain names with or without an extension

• Check, to determine availability and pricing for a search result

• Register, to actually register a domain as yours

Domain Registrar is also available via the Cloudflare MCP server.

Flagship
Feature flags are now available on Cloudflare, underpinned by OpenFeature. It supports all you’d expect from a feature flagging solution, and it’s in private beta currently.

PlanetScale <> Workers Integration
Users can now create and manage PlanetScale Postgres and MySQL databases directly through the Cloudflare dashboard and API.

Starting next month, billing will be unified, allowing self-serve and enterprise customers to pay for their databases via their Cloudflare account.

Live View + Chrome DevTools Protocol for Browser Rendering Run
Browser Rendering is now called Browser Run, and received a bunch of updates:

• Live View allows a human to jump into a browser session to help an AI agent out.

• Browser Run now supports Chrome DevTools Protocol (CDP), a remote debugging protocol that allows you to instrument, inspect, debug, and profile Chromium-based browsers.

• MCP client support, such as Claude Desktop, Cursor, and OpenCode.

• WebMCP support, enabling websites to declare what actions are available for agents

• Session recordings to aid debugging, including DOM changes, user interactions, and page navigation.

• Limit increases to allow you to run up to 120 concurrent browsers

AI Search Improvements
AI Search allows you to create knowledge bases for your AI agents to use.

You can now ingest data directly using the new Items API. There’s also a new ai_search_namespaces binding that allows you to create, modify and delete AI search indexes programmatically.

New on the search side, Hybrid search combines vector search with BM25 keyword search. Relevance boosting allows you to modify how a search is handled based on document metadata.

Workflows Capacity Increases
The limits associated with Workflows have increased massively since it was first introduced at the end of 2024, and they are going even higher now:

• Max concurrent instances raised to 50,000 from 10,000

• Instance creation rate increased to 300/second per account & 100/second per workflow, up from 100/second per account

• Ability to queue 2 million instances per workflow, up from 1 million

Agent Lee
The Cloudflare Dashboard now has an AI assistant for everyone to use that can undertake tasks and answer any questions you have.

For example, if you’re like me and worry each time you make a DNS change, you can ask Agent Lee to sense-check the DNS change and even action it directly from the chat.

🌎 Improving the Web for Agents

Agent Readiness Checker
Cloudflare has introduced a new website to check if your website is well suited for agents to discover and use.

Simply enter your domain and it will be assessed across 4 key areas, and present you with a final score - think Lighthouse for AI agents.

Shared Dictionaries
Over time, web pages have grown in size - roughly 6-9% per year. With agents arriving on the scene, the amount of web traffic is growing at an astonishing rate, making this bloat slow everything down for everyone.

A compression dictionary is a shared reference between server and client that works like a cheat sheet. Instead of compressing a response from scratch, the server says “you already know this part of the file because you’ve cached it before” and only sends what’s new.

Redirects for AI Training
AI crawlers aren’t particularly intelligent - they can’t tell what information is outdated, even if the page explicitly says so.

To solve for this, Cloudflare is introducing Redirects for AI Training, which lets you enforce redirects for verified crawlers to the most up to date content. This transforms your existing canonical tags to become 301 redirects automatically with a single toggle.

Unweight
Large language models are huge, often into the 100s of GBs largely made up of numbers. They present unique challenges to run at scale.

Cloudflare focused on shrinking those numbers (model weights) without changing what the model actually does. They built a system called Unweight that compresses the model’s data so it takes up less space, but still gives exactly the same answers.

Network Performance Update
At regular intervals, Cloudflare provides updates on its network performance. Here’s the highlights from this review:

• Number 1 in 40% of networks to number 1 in 60% of networks in 3 months

• Gained the fastest status in an additional 40 countries

• Now number 1 in 54 more US ASNs

• 6ms faster than competitors on average in December

That’s everything, hope you enjoyed Agents Week. I’ll be back for the next innovation week too, as well as my daily musings and insights all related to Cloudflare.

Want to read all the blog posts yourself? Check them out here.

On 24th February 2026, Cloudflare announced vinext, a complete rewrite of Next.js built on Vite, deployable to Cloudflare with a single command.

For years, Cloudflare has worked to support Next.js on its platform, but the framework’s bespoke build output made that difficult. Running Next.js outside its intended environment requires reshaping that output for each platform.

This pain point led to vinext. By rebuilding Next.js on top of Vite, deployment becomes considerably simpler.

That alone would be an interesting story. But what if I told you that vinext was created in one week, by a single engineer, Steve Faulkner, using AI and around $1,100 in tokens.

I sat down with Steve to understand how vinext came together, and what it tells us about the future of AI-assisted development.

Ashley: Hi Steve, and thank you for agreeing to be interviewed today! Can you briefly introduce yourself and your role at Cloudflare?

Steve: Hey everyone, I'm Steve Faulkner, Director of Engineering for Workers at Cloudflare. I run a roughly 90-person org that covers Workers, Containers, Agents SDK, Sandboxes, Wrangler, Frameworks, and several other teams.

Ashley: vinext is a pretty radical idea. How did it actually come about?

Steve: We’re constantly trying to figure out how to best support Next.js on Cloudflare. We’ve invested heavily in OpenNext and we’re still involved in that project, but OpenNext is fundamentally built on top of Next.js and its Turbopack-based output, which constrains what we can do.

There was always this idea of reimplementing the Next.js API to get a higher ceiling on performance and better output. We actually tried it twice with human engineers.

Then the models got dramatically better last December and January, and I started wondering if AI could just do it. Next.js has a massive test suite. I used that as the spec, started on a Friday night with Opus, and woke up Saturday morning to an app router demo that was kind of working. That kicked this whole project into gear.

Ashley: Rewriting Next.js is no small undertaking, even for AI. How did you structure your workflow with AI on this project?

Steve: Almost all of it was OpenCode with Opus 4.5 and 4.6. I also do a lot of voice-to-text via SuperWhisper. A few markdown files for planning and context: an agents.md file generated and maintained by the agent, a discoveries.md that logged ecosystem gotchas to avoid repeat mistakes, and tracking documents for ported Next.js tests. I didn’t use special sub-agents or custom MCP servers.

Closer to launch I started using context7 and Exa search MCP for better library lookups. I also made use of agent-browser, which was critical for actual debugging in a live browser.

I asked OpenCode to analyze its own sessions and they were surprisingly barbell-shaped: either two-to-three-minute corrections or one-to-two-hour deep dives. My peak token usage was at 3 AM, when I’m sleeping, so I was clearly setting up task lists before bed and letting it run overnight.

This was not a fancy or complex setup. No Ralph Wiggum loops. Just giving OpenCode a list of tasks I thought would keep it busy for a few hours.

Ashley: It’s refreshing to see a relatively simple workflow be so effective, especially when all the discourse online is often buzzword soup. I’m sure it wasn’t all plain sailing though.

Which parts of vinext did AI handle well, and which parts still needed deep human expertise?

Steve: AI excelled at the boring, systemic work: porting tests from the Next.js suite, implementing next module shims against a known API surface, and grinding through compatibility issues. If you give it a failing test and a clear target, it iterates well.

The big human contribution was setting overall direction, such as:

• Deciding this should be a Vite plugin rather than a custom bundler

• Choosing to port tests rather than run the Next.js harness

• Prioritizing which features to tackle first. And finding bugs

I had to do manual QA many times, but AI would surprise me here too. It would get really far on its own with agent-browser.

Ashley: That definitely resonates with how I’m working with AI too, it can churn out code but it still lacks some critical thinking in my experience, especially when given a larger task.

I’d say recreating Next.js qualifies as a pretty large task, so how did you break down such a large framework into tasks that AI could reliably execute?

Steve: The agent helped a ton. We focused mostly on the test suite, but rather than trying to run their test harness directly, I had the agent port tests one by one into our Vitest and Playwright setup, then implement the code to make them pass. A tracking document helped the AI keep track along the way.

Ashley: There’s a long-standing idea that test suites are the best form of documentation, and this seems to prove it.

No matter the model, AI isn’t perfect though and I find it often gets things wrong or gets stuck.

What were the biggest failure points of AI during the project? What was the hardest technical problem in vinext where AI struggled the most?

Steve: There were definitely times where the AI just got stuck and I had to open a browser, click around, look at logs, and figure out what was actually going on. That manual debugging loop never fully went away.

I’ve also noticed it struggles with larger files. We have some that are two to three thousand lines, and I suspect smaller, more focused files work better for AI. That’s something we’re actively refactoring toward right now.

The other recurring issue was getting the AI to match Next.js behavior exactly. It would implement something that seemed reasonable but was subtly different from how Next.js actually works.

I’d point out the discrepancy and it would immediately agree and fix it, but it wouldn’t catch it on its own. A lot of iterating on our agents.md file went into teaching it to look at the Next.js implementation first before writing anything, so it was informed by how Next.js actually does things rather than guessing.

Ashley: I’ve been playing around with agents.md files a lot more lately, so I can definitely see how that would help. The one that Cloudflare ships with any new project created by npm create is quite good, I noticed the AI often tries to validate its work because it’s very aware of the tools to do so.

Another common discussion point online is the quality of code in the era of AI.

How would you rate the code quality of vinext, considering it was entirely written by AI which can often be sloppy or overly verbose in some cases?

Steve: It’s not amazing code. It’s verbose, and there are patterns I don’t love, like heavy use of template strings for code generation. However, this project was fundamentally about trusting the tests. If it passes the 2,700+ tests across Vitest and Playwright, it works.

We’re embracing that philosophy in maintenance too. We have AI reviewing code, and if we’re confident it’s the right direction and the AI approves it, we merge it.

This project was born from AI, and I think it will succeed because of AI. We’re trying to embrace that mindset rather than fight it. Almost all activity in the repo is driven by AI, including from the community.

Ashley: If nothing else, it’s a fascinating way to test how far AI can be pushed, along with how well it can maintain a project of considerable size.

In the vinext blog post, it mentions 94% coverage of Next.js’ test suite, so what big gaps remain in vinext vs Next.js?

Steve: There are still gaps and they’re well documented in the README. Static pre-rendering was called out in the blog post when we initially released it, but we just merged a PR with the first version of that, so it’s already being tackled.

One thing that’s surprised me is how few reported issues are about actual behavioral differences with Next.js. If you look at our issue tracker, the problems are mostly general JavaScript ecosystem issues: CommonJS versus ESM, bundling and module resolution differences between Vite and Turbopack.

Vite has a very ESM-first view of the world where Turbopack/Webpack are more lax about what they will accept especially around CommonJS.

Ashley: It’s great to see vinext being iterated on and maintained, as there was some concern online that this would be pushed out and then abandoned as a PR piece.

Looking forward, what’s the plan for vinext in the future? Is the plan to maintain it and continue working on it?

Steve: We are continuing to work on it. It started as an experiment but it’s clearly something people want.

In four weeks we’ve merged over 350 PRs, shipped 19 releases, and have 50+ contributors from the community. The repo has nearly 7,000 stars.

If you’re using Next.js and want to try it, you should. The more people who try it, the better it gets. The most valuable thing you can do is point your agent of choice at the repo, have it use the migration skill, and file issues for anything it hits along the way.

Ashley: That’s an incredible number of PRs for such a new project! The fact that other engineers are contributing shows there is value in the project, and that there’s a real desire to more easily run Next.js in places that were previously difficult.

Something that came to my mind immediately when I read the blog post was how vinext would co-exist with Next.js.

What does maintenance look like? How do you see updates in Next.js flowing into vinext, or will they diverge in future?

Steve: This project was born from AI and it’s going to be maintained by AI. We’ve gone all-in on AI development in this repo.

We have a strong bias toward merging AI-written PRs, we actively encourage contributors to use AI, and we spend a lot of time on our agents.md files to make sure the AI has the context it needs.

We have AI doing code review, AI doing security scanning, and AI keeping up with Next.js commits. That’s been the philosophy from day one.

Our primary focus right now is maintaining feature parity with Next.js. But I’m open to a future where we introduce small divergences. We’ve already shipped one feature that Next.js lacks (traffic-aware pre-rendering), and we’ll continue to look for similar opportunities.

We’re also getting requests to address Next.js bugs or implement behavioral modifications. We’re not actively pursuing those today, but I’m open to it depending on how the project grows.

Ashley: That’s really exciting, and I’m looking forward to seeing what happens with vinext in the future. Given the popularity of Vite, and the ability for AI to migrate from one framework to another at pace, it’ll be interesting to see how much it grows.

I know there are lots of engineers out there that are grappling with AI, some are embracing it, others are resistant, and everything in-between.

What skills do you think matter most for engineers working in this new world with heavy AI assisted coding?

Steve: You still need to know what to build and why. Recognize when AI output is structurally flawed, even if the tests pass, and understand your problem space deeply enough to steer effectively.

That ability to clearly articulate what’s right and course-correct is becoming one of the most valuable engineering skills.

Agents are remarkably good at taking feedback - often better than humans.

Ashley: There’s a lot to be said for taste in this new world we are in, and I think it’s even more important than it was before.

You’ve stated that you want to be as AI-pilled as possible with this project, so do you think AI will eventually be able to maintain a project like vinext without a human in the loop?

Steve: We're close, but not quite there yet.

For me, the truly interesting part of this project isn't Next.js; it's the potential of AI and pushing its limits. If the models improve just a bit more, and if we can establish a few more robust workflows (like Ralph Wiggum loops and leveraging the emerging auto-research techniques), I believe we can reach a point where AI can maintain projects like this without human intervention.

Given the current trajectory of these tools, that's where I think we’ll end up.

Ashley: Thank you so much for doing this interview with me, it’s been incredibly enlightening, answering a number of questions I had when I read the blog post - and I’m sure that others had too.

Good luck with vinext in the future, and I’ll be watching with eagerness to see how the project develops!

Is there anything you’d like to sign off with?

Steve: Go try vinext! It works everywhere, not just Cloudflare.

Running outside Cloudflare is as simple as vite start and you’re up on any Node server. The more feedback we get, the faster we can move.

And please, use AI to do the migration and have AI file issues. We’ve had really good luck with this kind of AI-first migration surfacing what problems people hit in the wild.

Durable Objects allow you to create very novel architectures that at the same time, considerably simplify the development effort required. When combined with Cloudflare’s growing list of primitives, you can offload a sizeable amount of complexity to the platform itself. This leaves you to focus on the things that make your application unique.

To demonstrate this, I built an application that notifies users when Eurostar Snap tickets become available for sale for your desired date and time. I never knew this website existed until recently, but effectively you can buy last minute Eurostar tickets very cheaply - some as cheap as £35 ($50) one way!

High-level Architecture

From the user’s point of view, the flow is really quite simple. A user selects the details of their trip such as from/to and the date, and if tickets become available, they receive an email notifying them.

On the technical side, we need the following:

• A way to serve assets to the frontend

• An API to handle form submissions & unsubscribes

• Be able to store the trips we need to track that users select

• Periodically check for ticket availability (we’ll do it every 20 minutes)

• Scrape the website for tickets using a headless browser (there’s no API)

• Send notification emails

We can map all these directly onto Cloudflare primitives like so:

It’s really quite simple, as the platform is handling so much for us.

The Cloudflare Worker is responsible for serving the frontend using static assets, and also implements the backend APIs for form submissions and unsubscribes.

Durable Objects Are The Real MVP

We use Durable Objects to track the trips, with one created per unique trip combination using a simple key for each Durable Object (e.g. london-paris-2027-01-01).

If no Durable Object exists for a trip, we simply create one and store the user’s email. For all future submissions for that same trip, we just add the new email to the existing Durable Object.

For anyone not familiar with Durable Objects, they combine compute and storage into one primitive, so the storage for each trip lives inside each Durable Object instance.

The Durable Object does more for us than that though, as it uses the alarm functionality to wake up every 20 minutes to check if tickets are available. More on that later.

There’s A Primitive For Everything

In order to check availability, we need a headless browser, so the application makes use of Browser Rendering - effectively headless browsers as a service, with support for Puppeteer.

If tickets are found, we need to send an email to let users know. For that, the application uses Email Sending via Cloudflare, which is currently in closed beta at this time.

Is Cloudflare’s offering as vast as AWS or GCP? Nope, but it has all the key building blocks that the majority of applications need these days.

Durable Objects Are Just Code

Let’s take a look at what the Durable Object looks like. Best of all, it’s just code, with the underlying infrastructure handled by Cloudflare.

Before sharing the code, this is by no means glorious code - it was absolutely vibe-coded as it’s just a demo app.

Here’s how we initialize the Durable Object:

import { DurableObject } from "cloudflare:workers";
import * as puppeteer from "@cloudflare/puppeteer";
import { TripDetails } from "./shared";
import { sendNotificationEmail } from "./email";
import { checkAvailability } from "./scraper";

const FOURTEEN_DAYS_MS = 14 * 24 * 60 * 60 * 1000;
const TWENTY_MINUTES_MS = 20 * 60 * 1000;
const FIVE_MINUTES_MS = 5 * 60 * 1000;

function firstRow<T>(cursor: { toArray(): T[] }): T | undefined {
    return cursor.toArray()[0];
}

export class SnapNotifier extends DurableObject<Env> {
    constructor(ctx: DurableObjectState, env: Env) {
        super(ctx, env);
        this.ctx.storage.sql.exec(`
            CREATE TABLE IF NOT EXISTS trip (
                origin TEXT NOT NULL,
                destination TEXT NOT NULL,
                date TEXT NOT NULL,
                time_slot TEXT NOT NULL
            );
            CREATE TABLE IF NOT EXISTS subscribers (
                email TEXT NOT NULL UNIQUE,
                token TEXT PRIMARY KEY
            );
            CREATE TABLE IF NOT EXISTS availability_state (
                id INTEGER PRIMARY KEY CHECK (id = 1),
                last_seen_available INTEGER NOT NULL
            );
        `);
    }
]

As each Durable Object has its own SQLite database, and it sits on the same machine that runs your Durable Object, the majority of queries run in 0ms - that’s not a typo. We can then add a method that’s called via RPC to handle subscribes on form submission from the Worker:

async subscribe(email: string, trip: TripDetails): Promise<void> {
  const existing = firstRow(this.ctx.storage.sql.exec("SELECT 1 FROM trip LIMIT 1"));

  if (!existing) {
    this.ctx.storage.sql.exec(
      "INSERT INTO trip (origin, destination, date, time_slot) VALUES (?, ?, ?, ?)",
      trip.origin,
      trip.destination,
      trip.date,
      trip.timeSlot,
    );
  }

  const alreadySubscribed = firstRow(
    this.ctx.storage.sql.exec("SELECT token FROM subscribers WHERE email = ?", email),
  );

  if (!alreadySubscribed) {
    const token = crypto.randomUUID();
    this.ctx.storage.sql.exec(
      "INSERT INTO subscribers (email, token) VALUES (?, ?)",
      email,
      token,
    );
  }

  await this.scheduleAlarm(trip.date);
}

If you’re curious how the Worker and the Durable Object interact, there’s great information in the docs that cover it. This is what interaction with a Durable Object looks like though:

const outboundKey = buildDoKey(origin, destination, outboundDate, outboundTimeSlot); //london-paris-2027-01-01

const outboundStub = env.SNAP_NOTIFIER.get(
  env.SNAP_NOTIFIER.idFromName(outboundKey),
) as DurableObjectStub<SnapNotifier>;

await outboundStub.subscribe(email, {
  origin,
  destination,
  date: outboundDate,
  timeSlot: outboundTimeSlot as TripDetails["timeSlot"],
});

Once subscribed, we handle the alarms in code too:

private async scheduleAlarm(tripDate: string): Promise<void> {
  const tripMs = new Date(tripDate + "T00:00:00Z").getTime();
  const now = Date.now();

  const targetMs = tripMs - FOURTEEN_DAYS_MS;
  const alarmTime = targetMs > now ? targetMs : now + 1000;

  const currentAlarm = await this.ctx.storage.getAlarm();
  if (currentAlarm === null || currentAlarm > alarmTime) {
    await this.ctx.storage.setAlarm(alarmTime);
  }
}

async alarm(): Promise<void> {
  const tripRow = firstRow(
    this.ctx.storage.sql.exec("SELECT origin, destination, date, time_slot FROM trip LIMIT 1"),
  );

  if (!tripRow) return;

  const trip: TripDetails = {
    origin: tripRow.origin as string,
    destination: tripRow.destination as string,
    date: tripRow.date as string,
    timeSlot: tripRow.time_slot as TripDetails["timeSlot"],
  };

  const tripMs = new Date(trip.date + "T23:59:59Z").getTime();
  if (Date.now() > tripMs) {
    this.ctx.storage.deleteAll();
    return;
  }

  let browser: Awaited<ReturnType<typeof puppeteer.launch>> | null = null;
  try {
    browser = await puppeteer.launch(this.env.BROWSER);
    const result = await checkAvailability(browser, trip);
    const lastSeenAvailable = this.getLastSeenAvailability();

    if (result.available) {
      await this.sendNotifications(trip);
    }
    
    await this.ctx.storage.setAlarm(Date.now() + TWENTY_MINUTES_MS);
  } catch (err) {
    console.error("Availability check failed, retrying in 5 minutes:", err);
    await this.ctx.storage.setAlarm(Date.now() + FIVE_MINUTES_MS);
  } finally {
    if (browser) {
      await browser.close();
    }
  }
}

Note that an alarm is run once by default, but will retry on error automatically with exponential backoff. You’ll see in the alarm method, we set the alarm again at the end of the flow and control retries ourselves in this instance.

To optimise cost, once the trip date for a given Durable Object passes, we can just call deleteAll() and no longer trigger the alarm to remove any cost associated with that Durable Object.

Lastly, if tickets are found, we send the email from the Durable Object too:

private async sendNotifications(trip: TripDetails): Promise<void> {
  const rows = this.ctx.storage.sql
    .exec("SELECT email, token FROM subscribers")
    .toArray();

  if (rows.length === 0) return;

  const doId = this.ctx.id.toString();

  for (const row of rows) {
    const unsubscribeUrl = `${this.env.WORKER_URL}/api/unsubscribe?id=${doId}&token=${row.token as string}`;
    await sendNotificationEmail({
      trip,
      email: row.email as string,
      unsubscribeUrl,
    });
  }
}

There’s a little more code in the full application, but I omitted some as it’s not showing anything unique (e.g. unsubscribes, avoiding re-sending emails on repeat).

If you’ve not used the Cloudflare developer platform before, it’s also worth reading about bindings, as the code above makes use of them for interacting with both Browser Rendering and Email Sending. In short, they provide access to resources with an SDK injected at runtime for you to use - a bit like platform-level dependency injection.

Cloudflare Does The Undifferentiated Heavy Lifting

The big takeaway from this is the platform is doing all of the heavy lifting. TThe frontend is served globally, as is the backend API. There are no regions when deploying to Cloudflare, and both will scale based on demand.

We’re sharding by trip date, and each Durable Object can store up to 10GB of data - there’s no way we ever store so many email addresses we hit that limit. Alarms run independently on each Durable Object, so if one encounters an error, no others are impacted, and we don’t have to worry about crons or anything like that.

You’re only charged when a Durable Object is running too, so when it’s asleep between checking for ticket availability, there’s no runtime cost incurred.

Lastly, we offload the responsibility of handling the headless browsers to Browser Rendering and just interact with it using a simple API via Puppeteer, and it’s a one-liner to send an email with Cloudflare too once Email Sending becomes publicly available.

Both are charged in a serverless manner, with Browser Rendering charging $0.09 per browser hour, and Email Sending pricing TBC but fully expect it to be based on usage. There’s pricing available for Durable Objects too.

The speed at which you can move with Cloudflare is unmatched in my experience, and by no means is it perfect, but I’ll accept some of the warts if the platform is doing so much for me, and I highly recommend you give it a go too.

Unless you’ve been living under a rock, you’ve undoubtedly heard that Cloudflare is going to be offering support for container-based workloads starting this year.

During Birthday Week 2024, Cloudflare announced that they will be providing access to the container platform they have been using in production to run existing products such as Workers AI and Browser Rendering.

No definitive date was set for public access, but I’m excited that the time has come for all of you to take the container platform for a spin. I’ve had access during closed beta, so I’m here to tell you all about Cloudflare Containers: what are they? How do they work? And how can you get started?

This post assumes some basic understanding of Docker and containers.

What are Cloudflare Containers?

If you’ve used containers before, you’ll feel right at home with Cloudflare Containers. I use containers on a daily basis as part of my day job, and it was simple to get started with Cloudflare’s offering.

You can literally take a Dockerfile you have for an existing service and run that on Cloudflare, because it uses the things you likely already use. I’d say containers on Cloudflare are positioned as lightweight, ephemeral containers that are globally-distributed automatically, and will have auto-scaling built-in.

I’ve not used it myself, but my understanding is it’s pretty similar to Google Cloud Run based on some conversations with others. In effect, you create your container, and Cloudflare handles deploying and provisioning that container when needed. As I’ve come to expect with Cloudflare, the developer experience is incredibly simple, allowing you to offload as much as possible to Cloudflare’s platform.

Whether you’ve used Google Cloud Run, or deployed containers to EC2 instances via ECS on AWS, there are some key differences to keep in mind.

For starters, there’s no persistent storage at launch. With ECS for example, you can attach EBS storage that survives the container being restarted. With Cloudflare, you do have access to the file system, but any data will be lost when the container is stopped.

On the plus side, containers are deployed globally automatically by Cloudflare, ensuring they are spun up close to the end user, which reduces latency compared to single-region deploys of Cloud Run and EC2. You can deploy to multiple regions, but you'd need to handle orchestration yourself.

Cloud Run has recently released multi-region deploys in beta, but you then need to setup load balancing too, so it’s not as effortless as with Cloudflare

This isn’t the only benefit, as it also prevents your containers being taken out by a single region going down. If that were to happen, Cloudflare would just spin up your containers in another region, a big win for fault tolerance and disaster recovery.

Enjoying the article and want to get a head start developing with Cloudflare? I’ve published a book, Serverless Apps on Cloudflare, that introduces you to all of the platform’s key offerings by guiding you through building a series of applications on Cloudflare.

Buy now: eBook | Paperback

Cloudflare Containers Use Cases

As with all pieces of technology, they are often targeted at certain use cases, and Cloudflare Containers are no different. Cloudflare already has Workers, Durable Objects, SQLite databases in the form of D1, blob storage with R2 and much more.

If you want to build a standard SaaS application that primarily handles CRUD operations, host a blog or build an API, you’re going to want to reach for the existing tools, as they excel at that task and similarly globally distribute your application.

However, due to the runtime that Workers operate in, which is limited to 128MB of memory, and only offers a Node-like environment, there are workloads that simply don’t fit with a Worker.

For example, let’s say your application allows users to upload videos that are then served to other users. You want to serve different formats based on the end user’s device, so you need to re-encode the uploaded video. The most common library for video encoding is FFmpeg, but it’s written in C, and naturally won’t run on Workers. Even if it did, 128MB of memory isn’t enough for such a task.

This is a perfect use case to reach for a container on Cloudflare. You can deploy containers running FFmpeg, spin up the containers as needed to handle demand, and let Cloudflare worry about deploying and provisioning them.

Besides that use case, Workers only run natively with JavaScript, TypeScript and Python. You can deploy other languages using WASM, but this requires a little more setup and you’re ultimately relying on WASM compatibility with your chosen language.

With containers, you can simply use a base image for your language of choice, install any dependencies you need (e.g. Gems in Ruby, Crates in Rust), copy the code across, and off you go, with all of this being orchestrated by a standard Dockerfile.

One of my favourite use cases for this, in the world of vibe coding, is the ability to run user-generated code in a sandbox for any language. Take bolt.new or v0, which allow you to create an app using AI, each time the AI makes changes, it needs to be run in a safe, sandbox environment so the end-user can see the outcome. This would work perfectly with containers, and again is not something you would be able to do with Workers.

Being able to support any language in the world naturally opens up another use case: porting existing applications from the likes of AWS, GCP and Azure. If you’re using containers already, you can lift-and-shift existing applications right over to Cloudflare, and get access to their highly performant, global network.

That’s the high-level view of what Cloudflare’s Containers are, but how do they work under the hood?

How do Cloudflare Containers Work?

This post will talk about Durable Objects a lot, which I’ve covered extensively before, so if you’re not sure what one is, I recommend reading at least the intro here before continuing!

The typical flow for deploying a container to most cloud platforms tends to follow the pattern of:

1. Create your Dockerfile

2. Build your container

3. Push to a registry

4. Deploy those containers to instances from the registry

5. Start the containers

So you’ll be pleased to know that’s the exact same pattern that Cloudflare has adopted. As I’ve come to enjoy with Cloudflare, it’s all wrapped up nicely for you by Wrangler, which I’ll go through later on when we go through the guide to deploying a container.

There’s actually a few pieces that combine to power containers on Cloudflare, and in terms of flow, this is how a typical request will look.

At least for now, containers on Cloudflare are only accessible via a Durable Object. Therefore, you need a Worker to front any user-facing requests that you want to hit a container.

That Worker can then request a specialised Durable Object that acts as a sidecar to a container, providing an interface to interact with that container. In the same way you can create multiple instances of a regular Durable Object, you can do the same with the specialised container-focussed Durable Objects.

This mechanism enables the dynamic scaling of containers by associating one container per Durable Object instance.

Once you’ve retrieved the Durable Object for a container, behind the scenes the container will be started, ready to serve requests. The start-up time will depend entirely on what the container needs to do to start, but a simple Node.js Express app started in around 1.5 seconds on average when I tried. Subsequent requests were then served in around 100ms to the client.

Additionally, you can define how long a container stays in memory after it serves a request. In the future, you’ll be able to enable auto-scaling, but for now, the only way to spin up containers is when they are requested, with requests being queued if necessary.

In terms of the interface the Durable Object provides, it’s relatively minimal right now but contains what you’d probably expect:

• Start a container (you can opt to manually start containers, rather than have them auto-start when the Durable Object is requested)

• Stop a container

• Destroy a container

• Exec against a container (e.g. run a Bash script)

• Schedule (and unschedule) a task within the container

• Hit the container with a request (using fetch)

Besides HTTP, containers are also able to handle WebSockets. The docs are pretty light on detail, but it looks like the Worker effectively forwards the request to the container.

If you want to connect from your container to outside resources, such as a database, it’s possible to pass environment variables to the container. As each container has an associated Durable Object, which has access to your bindings, you can retrieve any secrets (from Worker Secrets or Secrets Store) and pass them as environment variables.

You can define callbacks when certain things happen to your container too. For now, there’s onStart, onStop and onError.

That rounds how containers on Cloudflare work, and goes over the functionality they provide. I find it helps to see things in action to really understand how you might use containers, so I’ll go over exactly how containers work in your code next.

Get Started with Cloudflare Containers

Let’s get your first container deployed to Cloudflare. We will use a simple Express application to get started, and then you can iterate from there. If you don’t want to use Node, it will be simple enough to update the Dockerfile to the runtime of your choice.

Before you can get started, you’ll need to make sure you have two things:

1. A free Cloudflare account

2. Docker desktop installed on your machine, make sure it’s running too!

If you want to skip understanding how all the pieces fit together, the quickest way to deploy something right now using Containers is by running one simple command:

npm create cloudflare@latest -- --template=--template=cloudflare/templates/containers-template

This will use a template from Mike Nomitch (Product Manager at Cloudflare for Containers) and create a project all set to deploy a container. Simply run npm run deploy after and you’ll be all set.

If you want to understand the pieces that contribute to a container-based application on Cloudflare, read on. It’s honestly pretty simple, as I’ve come to expect with Cloudflare’s developer experience.

Create a New Project

You’re not going to do everything from scratch, that would be madness. You’ll start with a basic Worker, and then bolt containers onto that project. Keep in mind containers are not publicly accessible to the internet, so you need the Worker to act as the proxy for any request you want to route to a container.

Bootstrapping a project is easy with Cloudflare, simply run the following:

npm create cloudflare@latest containers-hello-world

Select “Hello World” from the first menu, then “Worker only” and finally “TypeScript”. You can opt to use Git if you wish, but don’t deploy your application.

Once this finishes, you’ll have a new folder named containers-hello-world containing a single Worker.

Setup an Express App

Before you can route any requests to a container, you need the actual code that will run inside the container. I picked Express purely because it’s incredibly simple to setup, and it’s fast - ensuring your cold starts are as minimal as possible.

Create a new folder at src/container and create two new files in it:

server.js

const express = require('express');
const app = express();
const port = 8080;
const host = '0.0.0.0';

app.get('/', (req, res) => {
  res.status(200).send('Hello World');
});

app.listen(port, host, () => {
  console.log(`Server is running on http://${host}:${port}`);
});

package.json

{
  "name": "hello-world-container",
  "version": "1.0.0",
  "description": "A hello world container",
  "main": "server.js",
  "scripts": {
    "start": "node server.js"
  },
  "dependencies": {
    "express": "^4.18.2"
  }
}

These two files create a simple Express application, running on Node, that will simply respond to any request with the classic Hello World message.

That’s the bootstrapping out of the way, let’s get onto the fun stuff: the containers.

Create a Dockerfile

When working with containers, the most common approach to build one is using a Dockerfile. If you’re not familiar, it’s effectively a set of instructions on how to build a container ready to serve your application - install dependencies, generate assets, and of course run your application.

Create a file named Dockerfile in the root of your project and insert the following content:

# syntax=docker/dockerfile:1

FROM node:20-alpine

# Set working directory
WORKDIR /app

# Copy package files
COPY container/package*.json ./

# Install Node.js dependencies
RUN npm install

# Copy Node.js source code
COPY container/ ./

# Expose port
EXPOSE 8080

# Run the server
CMD ["node", "server.js"]

The contents of this file will vary depending on what runtime and framework you use. In this case, we’re using an existing Docker image from Node that runs a lightweight version of Alpine Linux.

In short, someone else has done all the work necessary to prepare the environment to run Node applications, so you can just focus on the specifics of an application.

Since the application is simple, there isn’t much setup required. You simply install dependencies with npm, copy the code into the container, expose port 8080 (this is important!) and then lastly run the Express application.

You could do exactly the same with Ruby on Rails, just with a different base image, and then bundle your gems and run bundle exec rails s at the end.

As this is just a standard Dockerfile, you can build and run this container to make sure it’s working in isolation. To do so, run the following:

docker build -t containers-hw . && docker run -p 8080:8080 containers-hw

This will build your container, tag it with the name containers-hw and then run it on port 8080. Once the command has finished running, you can go to localhost:8080 in your browser and you’ll see the Hello World text on your screen.

Deploying a Container to Cloudflare

With the groundwork set, you can move onto the really fun stuff: diving into the specifics of how you can integrate containers into your Cloudflare applications and deployments.

As we’ve covered, each container deployed to Cloudflare has an associated Durable Object. Additionally, in order for Cloudflare to know about your container, that needs to be configured in the same way you would bindings in your Wrangler configuration.

Open up wrangler.jsonc in the root of your project and update it to the following:

{
  "$schema": "node_modules/wrangler/config-schema.json",
  "name": "containers-hello-world",
  "main": "src/index.ts",
  "compatibility_date": "2025-05-23",
  "compatibility_flags": [
    "nodejs_compat"
  ],
  "observability": {
    "enabled": true
  },
  "containers": [
    {
      "class_name": "NodeContainer",
      "image": "./Dockerfile",
      "max_instances": 1,
      "name": "hello-world-container"
    }
  ],
  "durable_objects": {
    "bindings": [
      {
        "class_name": "NodeContainer",
        "name": "CONTAINER"
      }
    ]
  },
  "migrations": [
    {
      "new_sqlite_classes": [
        "NodeContainer"
      ],
      "tag": "v1"
    }
  ]
}

If you’re not familiar with bindings, I highly recommend reading the documentation. In short though, bindings allow your Worker to connect to a number of resources - storage (R2), databases (D1), caches (KV) and in this case, Durable Objects.

To deploy a container to Cloudflare, you need to create a Durable Object that will map to a class that will manage your container - you’ll create that class shortly.

Additionally, you’ll notice the containers key defines the configuration for your container. As it’s an array, you can have multiple containers configured within a single project.

The important part here is that the class name is the same as what’s defined in your Durable Object binding, and of course that it points to the location of your Dockerfile.

I’ve set max_instances to 1 just so it reduces the cost, but you can set it higher if you wish. Keep in mind that this will mean all your requests route to a single container, so latency will be high from locations that are far away from your container. For a production-grade application, you’ll want to ensure this number is much higher so your containers can be spun up across the globe.

With Wrangler understanding where your container configuration is, and that you need a Durable Object, let’s create the Durable Object class that will be responsible for managing your containers.

Open up src/index.ts and update it to the following:

import { Container, getContainer } from '@cloudflare/containers';

export class NodeContainer extends Container {
  defaultPort = 8080;
  sleepAfter = '10s';

  override onStart() {
    console.log('Container successfully started');
  }

  override onStop() {
    console.log('Container successfully shut down');
  }

  override onError(error: unknown) {
    console.log('Container error:', error);
  }
}

export default {
  async fetch(request, env, ctx): Promise<Response> {
    return new Response('Hello World!');
  },
} satisfies ExportedHandler<Env>;

There’s a surprisingly small amount of code needed to interact with your containers. By adding this class, that extends a specialised type of Durable Object aptly named Container, you’ve now effectively got a sidecar for your container.

The code itself is pretty self-explanatory, with the key part being you need to make sure the port listed here matches what’s in your Dockerfile. As the name suggests, sleepAfter defines how long your containers stay in memory after handling a request. Lastly, there are a bunch of hooks you can use to handle lifecycle events of your container, such as when it starts and stops.

There’s a separate npm package for containers, so you need to add that to our application too:

npm install @cloudflare/containers

You’ll also need to update the Env interface to include your Durable Object, which you can do by simply running:

wrangler types

This will update worker-configuration.d.ts in the root to contain the definition for your Durable Object.

With the Durable Object created, there’s just one step left: route requests from your Worker to your container!

To do so, update the fetch method in src/index.ts to the following:

export default {
  async fetch(request, env, ctx): Promise<Response> {
    const container = await getContainer(env.CONTAINER);

    return container.fetch(request);
  },
} satisfies ExportedHandler<Env>;

Once again, there’s a surprisingly small amount of code to achieve this. As someone who definitely isn’t an expert when it comes to containers, I love that all the details have been abstracted away, and the platform is doing the heavy lifting for me.

All the code needs to do is fetch an instance of your container, which is the first line, and then return the response returned from the container, which is called using fetch.

The getContainer function is a handy wrapper that effectively gets the nearest available container that’s ready to serve requests. Should no containers be available, or perhaps the nearest container might be overloaded, the request will be potentially routed further away to another location.

Because access to a container is via a Durable Object, you can also manually scale containers yourself in the same way you would a Durable Object.

Let’s say you wanted to create 3 unique container instances every time a request is handled, you could do that with the following:

env.CONTAINER.get(idOne)
env.CONTAINER.get(idTwo)
env.CONTAINER.get(idThree)

You could then call fetch on each one, and you’d have 3 requests routed to 3 unique containers. This is perfect if you want to isolate code for specific users, for example, but for traditional application traffic, you likely want to use getContainer.

There’s one more helper method that allows you to load balance, but it has some pretty severe downsides at launch. Rather than calling getContainer, you can do the following:

const containerInstance = loadBalance(env.CONTAINER, 5)
return containerInstance.fetch(request);

Here are the downsides from the docs:

We have provided the loadBalance function as a stopgap solution to route to multiple stateless container instances. It will randomly select one of N instances for each request and route to it. Unfortunately, it has two major downsides:

• It requires that the user set a fixed number of instances to route to.

• It will randomly select each instance, regardless of location.

We plan to fix these issues with built-in autoscaling and routing features in the near future.

Keep in mind this is an early beta, so everything isn’t perfect yet.

Okay, enough information, it’s time to deploy your container to Cloudflare’s platform. There’s no crazy commands needed, just the same command as always:

npm run deploy

This will build your container, push to to Cloudflare’s registry, prepare it to serve requests and of course deploy the associated Worker and Durable Object.

Once deployed, you can go to your Cloudflare dashboard, click Containers under the Compute menu and you’ll see your list of containers.

An important note: your Worker is deployed immediately, but the containers will gradually rollout, so you’ll need to ensure any code is compatible with both versions of your new container code.

Clicking into one shows you an overview of that container

The UI will show the status of your containers, as they need to be distributed across the platform before they can be used. Initially it will show your container as provisioning, once that moves to Ready you can hit your Worker.

Hit the URL that was output in your terminal for your Worker, and watch as Hello World is served from your container 🎉

Early on in the beta, local development wasn’t possible. However, right before release, local development now works. You can try by running npm run dev, which will build your container and then serve your Worker locally as usual.

Enjoyed the article and want to get a head start developing with Cloudflare? I’ve published a book, Serverless Apps on Cloudflare, that introduces you to all of the platform’s key offerings by guiding you through building a series of applications on Cloudflare.

Buy now: eBook | Paperback

How much does a Cloudflare Container cost?

By this point, you’re probably itching to spin up some containers - I know I was when I first got access. Before you do though, let’s quickly cover the pricing for containers so you don’t wake up to a surprising bill when you throw 100 containers at it on day one.

I won’t go over the pricing for Workers and Durable Objects, but you can naturally expect to billed for those at the normal rates when interacting with containers via these products. Keep in mind, both have a generous free tier.

At launch, there will be three types of instances to choose from, that come with pre-configured memory, CPU and disk:

• dev provides 256MB of memory, 1/16 vCPU and 2GB of disk space.

• basic provides 1GB of memory, 1/4 vCPU and 4GB of disk space.

• standard provides 4 GB of memory, 1/2 vCPU and 4GB of disk space.

You can pick which instance type you want in your Wrangler configuration.

In terms of what you pay, you’re charged for every 10ms your container runs at the following rates:

• Memory: $0.0000025 per GB-second

• CPU: $0.000020 per vCPU-second

• Disk $0.00000007 per GB-second

This can be hard to grok in terms of how much you’ll actually end up paying. To give you a better idea, let’s say a container is running for 24 hours, you’d pay:

• $0.174096 for dev

• $0.672192 for basic

• $1.752192 for standard

What’s Coming Next?

This is just the beta, and while containers been in development for a while, it’s a sizeable undertaking to introduce, and there will be further features added.

Here’s a quick list of what’s missing on day 1, and what to expect in the near future:

• Logs from the container itself. You can’t see them in the dashboard nor Wrangler, but you can export them via Logpush if you’re an enterprise customer.

• As we’ve touched on, autoscaling and proper load balancing is not available yet.

• The Durable Object associated with a container is not co-located in the same location at present. They will be co-located in the future.

• There’s a disconnect between Worker deploys and container deploys, they are not in sync. The Worker code will be updated immediately, but the container rollouts are slower. Again, this will be addressed in the future.

• The limits are pretty low, these will be raised in the future.

Wrapping Up

That rounds out the introduction to containers on Cloudflare, hopefully you now have all the information needed to get started hacking away with your own containers.

It’s pretty early for this offering, but the developer experience and ease of getting started is really notable. It’s lacking some key features - such as autoscaling - but that’s coming in the future, alongside a bunch of other updates.

If you’ve enjoyed the article and found it useful, I’d really appreciate you giving it a share, or dropping me a comment!

If you’ve clicked into this post and wondered “what on earth is a Durable Object?”, then you’re in the right place - and trust me, you’re not alone, the vast majority of the tech community haven’t heard of them either.

And that’s a huge shame, because they are incredibly powerful and, as far as I know, unique to the Cloudflare developer platform. They do take some getting used to, and the aim of this post is to get you familiar with them, in the hope you can unlock the power they can bring.

Introduction

What are Durable Objects?

Let’s start out with the easy question, or so you would think, right? Well, I’ve been working with Cloudflare’s developer platform for many years, and used Durable Objects frequently, and for a long time, I struggled to explain what one was.

However, I feel like I’ve now settled on a consistent definition for them.

It’s incredibly difficult to write a one-liner to encapsulate everything a Durable Object can do, but this is the best I’ve come up with. As a teaser for later, they can also:

• Provide coordination in multiplayer scenarios (each instance of a Durable Object that you create has a unique ID, and only one instance can exist with that ID globally at any one time)

• Built-in WebSocket capabilities (a few lines of code to get going!)

• Able to wake up outside of HTTP requests (these are called alarms)

• Manage the entire lifecycle of the key entities in your domain, in a way that feels very organic and natural

• More recently, are the perfect mechanism to create and expose AI Agents

At its core, a Durable Object looks like just like any other class you define in your code in terms of appearance - more on that later. That’s part of the beauty: you can write what’s effectively “normal” code, and the platform will handle the rest in terms of maintaining any Durable Objects you create, and the networking required to interact with them.

Why Durable Objects Matter

The Cloudflare developer platform is entirely serverless, and Durable Objects are no different, effectively giving you stateful serverless applications. This is actually incredibly rare, when you consider similar (but not really) technologies such as Lambda, that have to use external data storage and retrieve any state when needed.

To fully understand why Durable Objects are revolutionary, we need to take a step back and understand a little more about the Cloudflare developer platform. It’s a global platform, with no region restrictions - when you deploy, you deploy to the entire world.

That might sound unrealistic, but it’s genuinely what happens. If you deploy a Cloudflare Worker, which is the underlying technology that powers Durable Objects, it can be spun up in any of the 300 cities where Cloudflare has data centres. As you can imagine, this will significantly reduce latency to the end user, and give you more redundancy and failover than you could ever need.

The same is true for Durable Objects, but with a twist. With Cloudflare Workers, they can be spun up in as many locations as needed. If you’re handling requests simultaneously from New York, London, Sydney and South Korea, you’ll likely end up with 4 instances of that Worker in each location.

With each instance of a Durable Object, as there can only be one instance of that Durable Object with a given ID, it will be created (by default) close to the location of where the first request originates. It will then live there indefinitely, but it can be moved around depending on availability of servers and other factors, as Cloudflare will maintain the state of your Durable Objects in numerous locations worldwide in case it’s “home” server is down.

This is all very cool, but why does it matter? For the same reasons it matters that a Cloudflare Worker is deployed globally - your Durable Objects can be spun up across the world instantly, and recover from failures in specific data centres. Being able to horizontally scale your application with zero effort is a pretty big win too, if you ask me.

Compare that with a platform like AWS, where your resources are typically confined to a single region, you then have to worry a lot more about that region going down, alongside larger latency when requests come in from afar.

I think this all comes to life a bit more if we look at some use cases, so let’s dive into that next.

Common Use Cases for Durable Objects

This won’t be an exhaustive list, but it should hopefully give you an idea of what’s possible with Durable Objects, and highlight their versatility. Let’s tackle the obvious one first, that is the go-to use case for Durable Objects: multiplayer.

Yes, this could mean some sort of multiplayer game, but these days lots of things in the business world are “multiplayer”. Google Docs for example, or Miro, where changes made by numerous people working on a single document are all synchronised across clients in real-time.

The reason Durable Objects shine at multiplayer is two-fold. Firstly, they come with built-in WebSockets, which are the most common way to implement real-time applications on the web. I always thought WebSockets were difficult to setup, and they can be if you manage the infrastructure yourself, but with Durable Objects, you can have WebSockets working in a few lines of code.

Secondly, because new instances of a Durable Object are created dynamically at runtime, you can create as many as you need on-demand. If a user creates a new document, or a new game lobby, you simply create a new Durable Object, connect all the clients and then you’ve effortlessly sharded your application that will scale horizontally almost to infinity.

That second point is actually another use case on its own, and not tied to multiplayer. Multi-tenancy is an incredibly common pattern in today’s SaaS world, where a large number of users all use the same website or application.

How do you segregate the data safely and ensure your application can scale to meet demand? You got it: Durable Objects.

No matter what the SaaS is, you can likely use Durable Objects to represent the key resources that your users can create. Whether it’s an AI Agent, a hotel reservation system like Booking.com, or data storage like Dropbox - the underlying things that users create can be individual Durable Objects.

We’ll touch on it more later, but in the example of the hotel reservation system, you’d want to avoid double booking when two users submit a reservation at the same time. Durable Objects can prevent this being an issue, as each one is single-threaded and queues up requests without interweaving them. With the state being held within the Durable Object, the first request would secure the booking, and the second request would return an error to the user when the availability was checked.

Let’s cover one more, and this could be a very typical application that has no multi-tenancy, no real-time - just your regular CRUD application.

Enjoying the article and want to get a head start developing with Cloudflare? I’ve published a book, Serverless Apps on Cloudflare, that introduces you to all of the platform’s key offerings by guiding you through building a series of applications on Cloudflare.

Buy now: eBook | Paperback

Getting Started with Durable Objects

Cover Prerequisites (Cloudflare Account, Wrangler, etc.) (now free!)

To help you better understand Durable Objects, let’s take a look at how to create and deploy one. Because I mentioned that they are like mini servers before, you might be imagining we’ll need to provision something, but we absolutely do not.

Before you can create and deploy Durable Objects, you’ll need a free Cloudflare account. You’ll also need to install Wrangler, Cloudflare’s CLI. Once you’ve got both, let’s get creating!

Creating a Durable Object

The best way to start pretty much any Cloudflare project, is by using npm create, and Durable Objects are no exception. Run the following to create the scaffolding required to use Durable Objects:

npm create cloudflare@latest -- durable-object-starter

You can choose whatever name you like for your project. When you run the command, you’ll effectively get a menu of options to choose from. Select the following:

• Hello World example

• Worker + Durable Objects

• TypeScript (you can use JS if you prefer)

• Yes to using Git

• No to deploying, we’ll do that later

If you want to try out other Cloudflare products, feel free to poke around the other menu options and see what’s available.

All of the code that’s related to Durable Objects will be in src/index.ts. The Durable Object definition is pure code, and looks just like any other JavaScript or TypeScript class.

export class MyDurableObject extends DurableObject<Env> {
  constructor(ctx: DurableObjectState, env: Env) {
    super(ctx, env);
  }

  async sayHello(name: string): Promise<string> {
    return `Hello, ${name}!`;
  }
}

This is what will allow you to effortlessly spin up as many Durable Objects as you need, because you create Durable Objects on-the-fly with code. That makes them scale to the moon, and I also really like that everything is code and you interact with a Durable Object as if it were a regular JavaScript class. We’ll get into how to create instances and how the communication works later on.

For now, looking at the Durable Object class definition, there’s a few things to callout. First, there’s the constructor, which has two parameters:

• ctx (short for context) is where you’ll find some of the bells and whistles that come built-in to a Durable Object. For example, there are methods to interact with WebSockets, and methods to interact with storage (both key-value and SQLite are supported!)

• env is a common parameter across Durable Objects and Workers, and you can think of this as like the environment your Durable Object has access to. There are things you’d expect from other programming languages, like environment variables and secrets, but also Cloudflare-specific magic such as bindings.

What are bindings, you might ask? This could honestly be an entire post on its own, but think of them as a way to link your compute (a Worker, a Durable Object) to a resource such as a cache, database, queue or, as we’ll see shortly, a Durable Object.

One of the really cool things about bindings is, they are injected automatically at runtime, depending on the environment your compute is operating in. You can bind different resources based on development, staging and production, for example. Then at runtime, env will contain objects for you to use to interact with these resources (e.g. reading from a KV cache by calling env.KV_CACHE.get(‘your-key’))

To see this in action, let’s look at the code that’s been generated that creates Durable Objects on-the-fly using a Worker:

export default {
  async fetch(request, env, ctx): Promise<Response> {

    const id: DurableObjectId = env.MY_DURABLE_OBJECT.idFromName("foo");
    const stub = env.MY_DURABLE_OBJECT.get(id);

    const greeting = await stub.sayHello("world");

    return new Response(greeting);
  },
};

If you’re new to Cloudflare, and haven’t seen a Worker before, this is the basic structure of a Cloudflare Worker. The most common way to interact with them is via HTTP, as Workers, by default, are public and accessible by hitting a URL. When a request comes in, the fetch function is called, and you can then handle the HTTP request with standard JavaScript code.

In the example code above, a binding to the Durable Object we looked at earlier is used to create an instance of that Durable Object, call its sayHello method and return a response.

A key thing to note is that while the call to sayHello might look like a regular in-memory method call, you’re actually calling methods on a stub, that makes RPC calls to your Durable Object that is likely sitting in another data centre alongside its storage.

You can add as many methods as you like to your Durable Object, in the same way you would any other class. There are other built-in capabilities, such as alarms and WebSockets, that we’ll cover later on.

If you want to see everything working locally, simply run npm run dev in your terminal, and open the URL shown. Another big feature of Cloudflare’s developer platform is that you can (nearly always) run everything locally, with Cloudflare simulating bindings locally too.

This is true for Durable Objects as well. Keep in mind there will be no latency locally, so it’s not a true representation of the performance you’ll see once deployed. For that, you can run npm run deploy and your Worker will be deployed to Cloudflare’s global network, along with your Durable Object.

Once again, open the URL output in the terminal and your Worker will serve the request by communicating with your Durable Object.

Now that you understand how to construct and deploy a Durable Object, let’s take a closer look at some core concepts and the underlying architecture of Durable Objects.

Core Concepts of Durable Objects

State Management and Consistency

As we’ve covered already, one of the key aspects of a Durable Object is the fact it comes with built-in durable storage. This storage is colocated with the Durable Object itself, so the latency to its storage is basically non-existent.

When Durable Objects were first released, they only came with a very simple key-value store. This was useful, but it made storing complex, relational data quite cumbersome.

In late 2024, a second storage option was released, allowing you to harness the power of SQLite within your Durable Object. As you can imagine, this gives you a lot more freedom and flexibility in how you structure and store your data.

Additionally, because the storage is colocated with the Durable Object, queries are effectively zero-latency. This is because SQLite is being run not only in the same data centre, but in the exact same thread as the compute for your Durable Object. Database queries are also synchronous, because they are executed so rapidly there’s no need to make them async.

If you’ve ever worked with SQL before, you’ll likely have heard of the N+1 problem, but with SQLite-backed Durable Objects, you can genuinely write these types of queries and not incur any noticeable performance hit.

In the case of writes, they too are synchronous, but they are still durable and written to disk before a response is returned from your Durable Object. This is where some clever engineering comes in on Cloudflare’s part, as the code doesn’t wait for the query to be written to disk before continuing, but you’re still protected from inconsistencies thanks to what Cloudflare call Output Gates.

Rather than regurgitate Kenton’s blog post, I’ll just quote him verbatim:

In DOs, when the application issues a write, it continues executing without waiting for confirmation. However, when the DO then responds to the client, the response is blocked by the "Output Gate". This system holds the response until all storage writes relevant to the response have been confirmed, then sends the response on its way. In the rare case that the write fails, the response will be replaced with an error and the Durable Object itself will restart. So, even though the application constructed a "success" response, nobody can ever see that this happened, and thus nobody can be misled into believing that the data was stored.

You can see this in action in the following diagram:

There are other benefits to this approach, such as lower latency when handling requests, as the Durable Object can work on building the response while the storage layer confirms the write, actually speeding up overall request handling time.

Isolation and Concurrency Model

As previously mentioned, Durable Objects are a special kind of Worker, but they still use the same runtime and how that runtime is operated is the same.

The runtime is called V8, and it’s the same that runs when you’re using Google Chrome. In terms of isolation, you can think of it like tabs in your browser, where one tab cannot access data in another tab.

The same is true for Workers and Durable objects, that run in something called an isolate. To quote Cloudflare’s documentation:

It’s actually an incredibly efficient way to run software. There are no containers, and within a single process, you can run hundreds or thousands of isolates, each completely separate and unable to access one another’s data.

As an extra benefit, in the same way your tabs open instantly, isolates are near-instant in terms of start time too. That means there’s rarely cold starts on Cloudflare’s platform, as your code can be loaded ready to be executed during the TLS handshake.

Unlike Lambda, isolates are typically rapidly evicted from memory after they have finished executing code. That makes in-memory caching largely useless, but if your Durable Object is busy and handling lots of concurrent requests, it will stay around for a few seconds, in which case you can see benefit from in-memory caching.

But to really ram the point home, while the storage layer of a Durable Object is persisted between evictions, in-memory data is not. This is important to keep in mind, as looking at the code, you might be fooled into thinking the constructor worked in the same way as a standard class, where you’re able to initialize and cache data on creation.

Location and Global Distribution

As with the majority of Cloudflare’s developer platform, Durable Objects are automatically available globally. They are not available in as many locations as Workers are (330+ cities!) but they are definitely globally-distributed across the continents of the world.

Their initial location is determined when you first create a Durable Object, and it will be created close to where your Worker is calling from. It might be in the same data centre, but if not, it will be in close proximity.

Due to the nature of Durable Objects, and the fact they are created dynamically, the assumption here is that whoever is calling your application likely wants to keep accessing the data you’ll store in a Durable Object.

For example, consider Google Docs, if you create a document, you’re likely to be the primary person editing and working on that document. Therefore, to improve the responsiveness of the application, it makes sense the Durable Object lives close to that end user.

Naturally, there might be occasions where you want to set the location of a Durable Object yourself. Perhaps the person using a SaaS application is in Australia, but the majority of their customers are in the US. In that case, you might want to offer them the ability to create any documents in the US, to reduce latency to their customers.

This is possible at creation by specifying a location hint when you retrieve a Durable Object:

let durableObjectStub = DO_NAMESPACE.get(id, { locationHint: "enam" });

You can see the full list of available locations here.

Another quirk of Durable Objects is that once their location is set, it typically won’t move from that data centre, and you can’t request it be moved either. If you wanted to move the location of a Durable Object, you’d need to perform your own migration, where you create new Durable Objects in a different location, and then migrate any storage.

This doesn’t mean that if that data centre goes down that your Durable Object is inaccessible though, as Cloudflare can opt to move your Durable Object around if needed. There are backups of your Durable Object held in other locations to facilitate this. This is all managed by the platform though, and again, you have no control over when and if this happens.

Durable Objects API

With a solid understanding of what Durable Objects are and how they are architected, let’s take a closer look at the APIs available - there’s everything from RPC, to WebSockets, to AI agents and more to cover.

Synchronous Calls with Fetch & RPC

Let’s start out with the simple stuff: you can synchronous call your Durable Object via fetch or RPC. For a while, there was only fetch, so if you wanted to provide more than one piece of functionality from a Durable Object, you basically had to implement path-based routing in the same way you would a HTTP-based API.

This had other drawbacks, as you had to serialize/deserialize JSON for the payloads on either side of the call. This isn’t the end of the world, but it does involve a lot more code versus RPC. Here’s what a call might look like if you wanted to use a Durable Object for authentication from a Worker:

// Get the Durable Object
const id = env.MY_DURABLE_OBJECT.idFromName('foo');
let stub = env.MY_DURABLE_OBJECT.get(id);

// Construct a JSON request to the auth service.
let authRequest = {
  cookie: req.headers.get("Cookie")
};

// Send it to the Durable Object
let resp = await stub.fetch(
  "https://auth/check-cookie", {
  method: "POST",
  headers: {
    "Content-Type": "application/json; charset=utf-8",
  },
  body: JSON.stringify(authRequest)
});

if (!resp.ok) {
  return new Response("Internal Server Error", {status: 500});
}

// Parse the JSON result.
let authResult = await resp.json();

// Use the result.
if (!authResult.authenticated) {
  return new Response("Not authenticated", {status: 401});
}
    
let username = authResult.username;

Considering you likely want to make calls to Durable Objects and other Workers throughout your application, the amount of code needed to make a call rapidly adds up.

Luckily, in 2024, Cloudflare added support for calling Durable Objects using RPC (alongside Worker-to-Worker calls as well). For anyone not familiar with RPC, it’s effectively an alternative to using a protocol such as HTTP, where you make calls on a stub object (that looks like regular method calls), but behind the scenes, RPC handles all the serializing/deserializing for you as well as transmitting the data.

This ends up removing a lot of the boilerplate code above:

const id = env.MY_DURABLE_OBJECT.idFromName('foo');
let stub = env.MY_DURABLE_OBJECT.get(id);

// Call the Durable Object
let resp = await stub.authenticate(req.headers.get("Cookie"));

// Use the result.
if (!resp.authenticated) {
  return new Response("Not authenticated", {status: 401});
}
    
let username = resp.username;

I think we can all agree this is a lot simpler and cleaner. Additionally, let’s say we wanted this Durable Object to handle authentication and authorisation, we could easily add an authorized method to the Durable Object and call that too. If we were limited to fetch, we’d have to introduce some path-based routing to handle this.

It’s a lot easier to deal with regular objects too, as it means, if you’re using TypeScript, you can have type definitions for the inputs and outputs and simply pass regular data types back and forth. As long as what you pass is able to be cloned, you’re good to go.

You can even pass callbacks in the form of functions, and if that function is called, an RPC call will be made automatically back to the caller.

Schedule Execution with Alarms

If you need a Durable Object to wake itself up and execute some code on a schedule, then you’re in luck, as they come with alarms built-in. Much like the alarm you set to wake up in the morning, you simply set an alarm programatically, and the alarm method of your Durable Object will be called at that time.

To bring this concept to life, here’s what it looks like in code:

export class AlarmExample extends DurableObject {
  constructor(ctx, env) {
    this.ctx = ctx;
    this.storage = ctx.storage;
  }

  // Called via RPC
  async schedule() {
    // If there is no alarm currently set, set one in 10 seconds
    let currentAlarm = await this.storage.getAlarm();

    if (currentAlarm == null) {
      this.storage.setAlarm(Date.now() + (10 * 60));
    }
  }

  // Define your logic to execute here
  async alarm() {

  }
}

As you can see, it uses the underlying storage of the Durable Object to store the alarm. It’s only possible to set one alarm per Durable Object, but you can write your own logic to manage multiple alarms if you need to.

Alarms have retries baked in, so if your alarm handler throws an error, it will be automatically retried up to 6 times with exponential backoff.

If you’re wondering how you might use an alarm for a real-world use case, let’s say you’re building a website that provides stock market data. You could create a Durable Object per company, and schedule an alarm that periodically wakes up (let’s say every 10 seconds) to retrieve the latest data, storing it within the Durable Object itself.

This saves you having a cron-like task that loops through hundreds of companies, and has some nice benefits like isolating failures to just one company, if one particular company’s data isn’t available.

Speaking of storage, let’s take a look at the two flavours of storage available to you when using Durable Objects.

Store Simple Data with Key-Value Storage

When Durable Objects were released a few years ago, they did so with just one option for storage: a key-value store. Just for clarity, it shouldn’t be confused with Workers KV - as they are completely different in how they work.

In the case of a Durable Object, the storage is maintained by the Durable Object itself. Unlike Workers KV, it’s not globally replicated in a transactional sense, because it doesn’t need to be due to the fact the DO lives in one place at one time.

The interface itself will be familiar to anyone who has used a key-value store. Here’s a simple example using a counter to illustrate the API:

export class Counter extends DurableObject {
  constructor(ctx, env) {
    super(ctx, env);
  }

  async increment() {
    let value = (await this.ctx.storage.get("value")) || 0;
    value += 1;
    await this.ctx.storage.put("value", value);
    return value;
  }
}

The key lines here are this.ctx.storage.get("value") and this.ctx.storage.put, which do exactly as they sound: get data and store data.

Alongside get and put, there’s delete to remove data, and list to retrieve all the key-value pairs.

It works well for simple use cases, but can become unwieldy if you need to store more complex data, or even just a large amount that isn’t suitable for key-value format. This is largely due to the fact the maximum value you can store is 128 KiB per key. Additionally, you can only store 50GB across your entire account, although this can be raised by request.

If you need more complex storage, then you’re in luck - let’s take a look at the second storage option.

Store Relational Data with SQLite

In September 2024, during Birthday Week, Cloudflare gave us quite the present in the form of SQLite-backed Durable Objects. This announcement added a second storage option alongside key-value, providing the ability to run queries against a SQLite database.

The incredibly cool part of this is the storage is effectively zero-latency, as the SQLite database exists in the same thread as your Durable Object. This means you can create schemas, retrieve data and insert data pretty much instantaneously.

When compared to the key-value storage, the limits are significantly higher for SQLite-backed Durable Objects. You can store up to 10GB per Durable Object, with no limit on the amount of data you can store across your account (note: the free plan limits you to 5GB).

This sort of relational data format unlocks the ability to treat your key domain entities as living objects, at least in my opinion. There’s naturally a conversation to be had around vendor lock-in, but imagine being able to represent your key domain entities and have their lifecycle managed by a Durable Object.

Let’s say you’re a chat company, something akin to Zendesk. The key entity in your domain is likely a chat, and with Durable Objects each chat would be its own Durable Object instance.

All the history would be stored in the Durable Object, and as we’ll dive into next, the client can connect to a chat via WebSockets directly into the Durable Object. Additionally, let’s say you want to send a feedback request email 24 hours after the last message is sent - simply define an alarm, and the DO can send that email itself.

It takes some getting used to, but there’s something really unique about seeing your application behave as if it’s a living ecosystem. It’s a little like the first time you go to see the a theatre show or the ballet, you’re in awe at the coordination that just seems to magically happen before your eyes.

So what does a SQLite-backed Durable Object look like? Let’s take a look:

export class FlightSeating extends DurableObject {
  sql = this.ctx.storage.sql;

  // Call when the flight is first created to set up the seat map.
  initializeFlight(seatList) {
    this.sql.exec(`
      CREATE TABLE seats (
        seatId TEXT PRIMARY KEY,  -- e.g. "3B"
        occupant TEXT             -- null if available
      )
    `);

    for (let seat of seatList) {
      this.sql.exec(`INSERT INTO seats VALUES (?, null)`, seat);
    }
  }

  // Get a list of available seats.
  getAvailable() {
    let results = [];

    // Query returns a cursor.
    let cursor = this.sql.exec(`SELECT seatId FROM seats WHERE occupant IS NULL`);

    // Cursors are iterable.
    for (let row of cursor) {
      // Each row is an object with a property for each column.
      results.push(row.seatId);
    }

    return results;
  }

As you can see, you make use of the storage object on the context object within the Durable Object, this time using sql. It uses a cursor for access, which is straightforward to use, alongside regular insert and create statements that are standard within SQLite. The full API can be seen here.

Additionally, SQLite-backed Durable Objects come with point-in-time recovery. You can restore your SQLite database to any point in time in the last 30 days, using a straightforward API.

Now, you might be thinking, what if I need to add or update the schemas in a Durable Object? Well, thanks to fact that the queries are lightening fast, I actually tend to do any migrations in the constructor when needed on-the-fly.

The constructor will be called each time the Durable Object is woken up. So let’s say you get a Durable Object with an ID of test, the constructor will be called, and then any subsequent requests won’t trigger the constructor.

As a Durable Object will hang around in memory for a little while, if you make lots of requests in quick succession, the constructor will only be called once. As a nice little caching strategy, this means you can store instance variables as a form of very temporary cache, where they will only be present until the Durable Object is evicted from memory.

I’d like to see some tooling for this baked into the Durable Object API, in the same way D1 databases track which migrations have been applied, it would be helpful if Durable Objects could do this, and then (optionally) auto-apply any migrations needed.

If you want to reduce the amount of code you have lying around, you could have a script that loops over all your Durable Objects and applies any schema changes, as an alternative strategy - but it will take a while if you have a lot of them, and naturally use up quite a lot of requests.

It’s worth noting that while key-value-based Durable Objects will be around for a while, the recommendation is to use SQLite-backed Durable objects, which also still have access to a key-value store.

We touched on WebSocket support in this section, so let’s dive a little deeper into that.

Built-in WebSocket Support

I’ve mentioned multiplayer a few times, and in the last section mentioned a chat application that could use WebSockets to enable real-time communication. Durable Objects are perfect for this use case because they come with baked-in WebSocket support.

Before I used Durable Objects, I’d never used WebSockets, and from what I’d heard, they could be a bit of a pain to deal with. Now, whether that’s true or not, I can’t say as I’ve never had a reason to use anything beside a Durable Object, it’s that easy.

You can genuinely setup a WebSocket-based application in a few lines of code in the server-side, and just use typical connection code on the client side. The interface is really clean too:

export class WebSocketHibernationServer extends DurableObject {
  async fetch(request) {
    const webSocketPair = new WebSocketPair();
    const [client, server] = Object.values(webSocketPair);

    this.ctx.acceptWebSocket(server);

    return new Response(null, {
      status: 101,
      webSocket: client,
    });
  }

  async webSocketMessage(ws, message) {
    ws.send(
      `[Durable Object] message: ${message}, connections: ${this.ctx.getWebSockets().length}`,
    );
  }

  async webSocketClose(ws, code, reason, wasClean) {
    ws.close(code, "Durable Object is closing WebSocket");
  }
}

To quickly explain what’s happening here, a Worker would invoke the Durable Object using the fetch function when it wants to establish a WebSocket connection. The response contains the client-side WebSocket, as well as a HTTP 101 header which indicates the client wants to switch the protocol from HTTP.

The Durable Object simply calls acceptWebSocket, and that’s all there is to it. When a message is received from the client, the webSocketMessage method will be called, and you can handle the incoming message as required.

You can connect a large number of clients to a single Durable Object instance, with no published limit from Cloudflare. The number of effective WebSockets you can connect to a single instance is going to depend how busy each WebSocket is, and what happens when each message is received.

Keep in mind that the Durable Object can “only” handle 1,000 requests per second at peak, so you may need to shard your Durable Objects to ensure they remain performant.

Going back to the chat example, let’s say you have 5 people connected to a single chat. You’ll want to relay any message sent to all clients, which is easy to do by calling this.ctx.getWebSockets, looping over each one and sending a message.

You might be thinking, wait, what if I have all the clients connected to my Durable Object, isn’t that going to cost a fortune as the Durable Object will be active continuously?

Well, want to know something else cool? Durable Objects, will hibernate between handling WebSocket messages. Let’s say you have a chat, and no one has sent any messages for 30 minutes, but they have the tab open in their browser. The Durable Object has been hibernating the entire time, and only wakes up when a message is sent. Therefore, you only pay for the wall time (duration) your Durable Object uses to handle incoming WebSocket messages.

This is a pretty killer feature, and honestly the interface is so simple, I think it’s really well done, and I thoroughly enjoying building WebSocket-based applications these days.

Agents SDK

It wouldn’t be a post in 2025 without some AI, would it?

It’s honestly worth checking out agents.cloudflare.com for an overview of the capabilities Cloudflare provides for building agents. Not only is the website beautiful, it does an excellent job of explaining some AI concepts alongside how Cloudflare enables them.

In effect, the Agents SDK from Cloudflare wraps Durable Objects to provide key capabilities needed to create AI agents. When you think back to what I said about Durable Objects being excellent ways to create living objects in your ecosystem, this is exactly what the Agents SDK is doing for AI agents.

It comes with baked-in React hooks as well, so you can easily connect clients to your AI agents. If you’ve been living under a rock lately, and somehow missed the hype, MCP is all the rage right now.

I’ll be honest, I’m not entirely sold on MCP living up to the hype just yet, it feels a little like a bubble currently. I can totally see how it could be huge in the future, but for now, it feels mainly like companies are riding the hype wave and tangible use cases for MCP are few-and-far between.

Ignoring that little tangent, the Agents SDK comes with MCP support - both in terms of connecting your AI agents to remote MCP servers, as well as hosting your own MCP servers.

Honestly, the SDK comes with so much, so here’s a quick roundup:

• Server-side and client-side agent classes

• WebSockets

• State synchronization

• Scheduling

• SQLite support (using SQLite-backed Durable Objects)

• MCP support

• Server-Sent Events

• Browse the web using Puppeteer, via Browser Rendering

And to be honest, there’s more but I highly recommend checking out the website for more information plus the docs.

How can I observe what my Durable Object is doing?

One of the key aspects to using any technology is how easy is it to understand what it’s doing, and investigating issues when they arise?

I will admit, one area that is in need of some love is the observability for Durable Objects. It has steadily improved, especially with the introduction of Workers Logs, which allows you to query and filter logs across your Workers and Durable Objects.

With the acquisition of Baselime, the observability aspect of the Cloudflare platform has steadily improved year-on-year, and I know there are more things in the works.

The data side is more tricky, however. How do you view what each Durable Object contains within its storage? Well, while it’s not particularly easy right now, there is growing tooling for it.

Outerbase was acquired by Cloudflare this year, and they already provide Outerbase Studio that can be configured to access Durable Objects using SQL. With the acquisition, I’m hoping this functionality finds its way into the Cloudflare ecosystem, hopefully allowing you to query data held across your Durable Objects.

How much does running a Durable Object cost?

At this point, hopefully you’re excited to try out Durable Objects. Before you do though, you probably want to know how much it’s going to cost you, right?

Well, I’ve got you covered. The good news is Durable Objects are recently available on the free tier, meaning you get 100,000 requests per day for free and 13,000 GB-s per day too.

If you’re confused by the GB-s, you’re not alone. The GB-s metric means 1 GB used continuously for 1 second. It's calculated by multiplying the amount of storage or memory used (in GB) by the duration it's utilized (in seconds).

Keep in mind you’re charged for the maximum memory available, not the memory you actually allocate. That means on the free plan you can run a little over one Durable Object for the entire day, and not get charged. Assuming my calculations are correct, you get just under 29 hours of Durable Object duration per day for free.

Let’s say you really love Durable Objects, you build all your applications with it, and suddenly you’re processing a ton through them. Here’s what it’s going to cost you:

• $0.15 per million requests

• $12.50 per million GB-s

Helpfully, there’s a reduced cost for WebSocket messages, which aren’t billed 1:1 in terms of requests:

There is no charge for outgoing WebSocket messages, nor for incoming WebSocket protocol pings. 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.

There are separate charges for the storage used too. Starting out with the key-value option, which doesn’t have a free plan, but does come included in the $5/month Workers Paid plan:

• 1 million read requests/month (+$0.20/million after)

• 1 million write requests/month (+$1.00/million after)

• 1 million delete requests/month (+$1.00/million after)

• 1 GB of stored data (+ $0.20/ GB-month after)

Moving onto the SQLite-backed Durable Objects, which do have a free tier:

• 5 million rows read/day

• 100,000 rows write/day

• 5GB total storage

The limits then get significantly bumped on the Workers Paid plan, with additional charges beyond that:

• 25 billion rows read/month (+$0.001 / million rows after)

• 50 million rows written/month (+$1.00 / million rows after)

• 5GB total storage (+$0.20/GB-month)

That’s a lot of billing information I know, but I think it’s good to consider and dive into a little. We’ll round out this post by looking at real-world examples and some use cases featuring Durable Objects.

Real-world Examples and Case Studies

I’m going to share a few websites that I’ve come across that use Durable Objects. I’d honestly love to see more companies who are using them share their stories, both the good and the bad, as the blog articles sharing insights are few and far between.

While Durable Objects are still spreading in terms of usage, I know for sure they are used far more widely than it visible online. Having said that, here’s a few:

• tldraw is a white boarding experience, offering an infinite canvas and uses WebSockets to synchronize all client activity.

• Gitlip is a collaborative coding platform, utilizing Durable Objects to house the underlying code for each repository. There’s an excellent deep dive on how they built it here.

• Waiting Room is a product from Cloudflare, and I’m highlighting this because a ton of Cloudflare products are effectively built on Durable Objects. This blog article provides good insights into how and why they are using them for this common use case

Enjoyed the article and want to get a head start developing with Cloudflare? I’ve published a book, Serverless Apps on Cloudflare, that introduces you to all of the platform’s key offerings by guiding you through building a series of applications on Cloudflare.

Buy now: eBook | Paperback

Wrapping Up

That brings us to the end of my ultimate guide to Durable Objects, if you made it this far, thank you for reading and I hope you found the content useful.

I truly think Durable Objects allow you to build applications in completely different and novel ways, and while they take some getting used to, they are incredibly powerful and I really hope we see more and more examples of them used in the wild.

If you have any questions or think I missed something, let me know and I’ll do my best to respond and update the article, and likewise if you think something is incorrect!

It can be hard to keep up to date on everything shipped, so I’m hoping this bite-sized post can keep you in the know, and of course I’ll add my own commentary about the changes too.

I’m still working out exactly what topics and cadence I’ll share on FlaredUp, but I’d like to post a new piece fortnightly at the very least. There will be a variety of pieces, including recaps of the latest developments, case studies, deep dives on Cloudflare technologies, as well as tutorials. Some pieces, like this one, will be relatively small, but others - such as the Developer Week post shared above - will be a lot larger.

Ultimately, I’m doing this in my spare time, so it will always be best-effort, but I’m hoping it can become the source for high quality content on the Cloudflare developer platform.

That’s enough about the Substack, let’s dive into the latest developments.

🔎 Metadata Filter Support Comes to AutoRAG

For those who didn’t catch Developer Week, AutoRAG was one of the new products announced. I dived into a lot of detail about it here, but in short it’s a service that manages every aspect required to build a RAG pipeline.

Every might be a stretch considering it’s in beta, and there are some features that it’s lacking, but if you’re looking for a starting point to build a RAG-based solution, AutoRAG is going to do the heavy lifting for you.

Plus, Cloudflare has a track record of releasing early in beta, and rapidly iterating and adding features, as we are about to see. I have no doubts that more features will come, and it will truly cover every aspect required for RAG pipelines.

To summarise AutoRAG, you upload all the information you want to be able to retrieve during RAG to an R2 bucket, create a new AutoRAG that links to that R2 bucket, and Cloudflare handles the rest. It will retrieve the content from R2, parse it, chunk it, generate embeddings, store and index them in Vectorize, and provide a simple interface (SDK/API) to then retrieve content at runtime.

When AutoRAG was released, one key feature it was missing was the ability to filter for certain information before calculating similarity scores. Not being able to filter meant you needed to create multiple AutoRAGs to segregate data, but that would become quickly untenable. This would be particularly true in a multi-tenant application - as you’d need to continually add AutoRAG bindings to your Worker, and that’s just not going to scale.

With the addition of filtering, you’re able to filter by folder and timestamp. This allows you to group related information into folders within R2 - or designate a folder per tenant - and then specify the folder you wish to use at runtime, or only include records after a given timestamp for example.

This is a good first step for filtering, but I think it really needs multi-folder support (at present, you can only filter on a single folder, and it doesn’t include subfolders). It does however unlock multi-tenancy, and that has been a hotly-requested feature, so kudos to Cloudflare for adding it so quickly after release.

Additionally, being able to tag a single document with multiple pieces of metadata seems pretty vital too - otherwise you might end up duplicating information all over the place just to adequately filter. I’ve worked with AWS Bedrock Knowledge Bases extensively, and they allow you to provide a metadata file alongside each document, which works pretty well. I’d like to see something similar here to make the filtering a little more advanced and more easily configurable.

Having said that, it’s exceptionally easy to implement AutoRAG. I managed to rip out so much code from one of my applications, which involves RAG, and simply replace it with AutoRAG in a matter of minutes.

📚 Workers KV now has Support for Bulk Reads

For the longest time, you could only read one key at a time from Workers KV. This meant that, should you need to read multiple keys, you’d need to parallelise them yourself - or do them sequentially and take the performance hit.

If you’re not familiar with Workers KV, it’s one of the oldest Cloudflare developer products and provides a globally-distributed key-value store. In terms of its interface, you can think of it in the same way you would Redis. That is where the similarities end though, because unlike Redis, which stores data in-memory, Workers KV runs off of disk.

That naturally makes it slower, but it comes with some benefits. Workers KV is replicated globally automatically, versus Redis you’re going to need to configure read replicas and likely manage that yourself.

Getting into the weeds of how Workers KV operates is a little beyond this post, but I’d recommend reading the product page if you’re interested. It’s designed for high-read use cases, and with KV being replicated globally, that makes the reads incredibly quick still, as your data will be cached close to end users.

Writes will always take a little longer, as those need to always go to the central data stores. It’s also worth noting KV operates an eventually consistent model, so it is possible to write-then-read (from another part of the world from the write) and read an older value.

Back to the latest changes, and it’s now possible to read up to 100 keys from KV in a single request. Considering you could parallelise the requests in the past, why is this a big deal?

Because Workers have a built-in limit of 6 simultaneous outbound connections, meaning if you need to read more than 6 keys, you’ll effectively only be able to read 6 in parallel and any requests beyond that will be queued. That’s going to make pulling a high number of keys incredibly slow, even if the keys are cached close to where your request originates.

This problem goes away with bulk reads though, as you can read 100 keys with a single outbound request, removing the need to do any form of parallelisation yourself (unless you’re reading a lot of keys) and getting around the outbound connection limit.

The SDK update is really clean to enable this, as it’s as simple as passing an array of keys to a get request rather than a single string:

const keys = ["key-a", "key-b", "key-c", ...]
const values = await env.KV_NAMESPACE.get(keys);

This is one of those really nice quality of life updates that often get overlooked, but help to move the platform forward and remove blockers to adopting the platform.

Enjoying the article and want to get a head start developing with Cloudflare? I’ve published a book, Serverless Apps on Cloudflare, that introduces you to all of the platform’s key offerings by guiding you through building a series of applications on Cloudflare.

Buy now: eBook | Paperback

⏱️ Python Workers can now Utilise Cron Triggers

If you need to run tasks on a schedule with Cloudflare, the easiest way is to use a cron trigger. You could use Workflows or Durable Objects too, but for simple, recurring tasks, a cron trigger works pretty nicely.

For as long as I can remember, cron triggers have been supported on JavaScript-based Cloudflare Workers. Until recently, JavaScript (and TypeScript) were the only native languages supported for Cloudflare Workers.

However, last year, Cloudflare added Python as a native option for writing Workers. Python Workers are slowly catching up to the capabilities available for their JS counterparts, and the latest addition is the ability to execute cron triggers with Python.

It’s worth noting, you can also write Workers in any language that supports WebAssembly too!

As with most things on the Cloudflare developer platform, the developer experience (DX) for implementing a cron trigger couldn’t be simpler. There’s no faffing about with crontabs, you simply configure the cron’s schedule in your Worker’s wrangler.toml:

[triggers]
crons = [ "*/3 * * * *", "*/15 * * * *" ]

And then add a function to your Python Worker that will be called whenever a cron schedule occurs:

from workers import handler

@handler
async def on_scheduled(event, env, ctx):
    if event.cron == "*/3 * * * *":
        await do_something_3()
    elif event.cron == "*/15 * * * *":
        await do_something_15()

    print("cron processed")

It’s as simple as that. The on_scheduled function will be called on the schedule you set, and you can execute whatever code you need, with access to the bindings your Worker has too.

If the Python code above is invalid, blame ChatGPT. I took the JS code from one of my projects and had it convert it. Besides that code snippet, and as always, every word in this post is written by hand with no AI involvement.

📈 Increased limits for Queues pull consumers

This one is pretty straightforward, so I won’t spend too much on it, but if you’re using, or look at using, Cloudflare Queues from your existing infrastructure, your available throughput just got a significant increase.

Cloudflare Queues are exactly what they sound like: message queues. You publish a message to a queue, and then a consumer can pull messages off the queue and process them as needed. As with everything on the developer platform, they are serverless, so you just create a queue and Cloudflare handles the rest.

The most common approach to consume from a queue is using a Worker. Much like the cron triggers above, you simply add a queue function to your Worker, bind a queue to that Worker, and Cloudflare will invoke that method whenever messages are available.

The throughput for Worker-based consumers has been 5,000 messages/second per queue for a while now, but there is a second way you can consume messages from a queue - HTTP-based pull consumers. Rather than deploying a Worker, you could use your existing infrastructure to poll the queue, using Cloudflare’s REST API for messages.

Previously, pull consumers were rate limited to 1,200 requests / 5 minutes across all queues - significantly lower than the throughput available for a Worker consumer. With this change though, pull-based consumers now have the same throughput available as Workers, at 5,000 messages/second per queue.

Subscribe now

Wrapping Up

That wraps up everything in April outside of Developer Week. As you can imagine, there was a huge focus on Developer Week drops, so it’s unsurprising the rest of April was relatively quiet.

Even so, the additions above are still meaningful and push the platform forward, and this is what happens every single month.

I’ll try to do one of these every two weeks, but they may push out to a monthly cadence depending on how much content is available, and what other content I’m working on.

Share

Enjoying the article and want to get a head start developing with Cloudflare? I’ve published a book, Serverless Apps on Cloudflare, that introduces you to all of the platform’s key offerings by guiding you through building a series of applications on Cloudflare.

Buy now: eBook | Paperback

A few weeks ago it was Security Week, and this week it was my personal favourite: Developer Week. Alongside Birthday Week later in the year, this is when we typically hear about all the latest and greatest features & products coming to Cloudflare’s Developer Platform.

This week’s Developer Week did not disappoint, and I am going to go over everything announced, explain what they are, why they are important and what you can use them for.

To give you an idea of the scale of the announcements, I will cover:

• 9 new products, 7 of those are available to use now

• 12 updates & new features to existing products

• 3 products & features maturing from beta to GA

We have a lot to cover, so let’s dive in.

For avoidance of doubt, this is entirely written by hand, outside of AI providing some definitions for some of the Realtime stuff

🚀 New Products

We’ll kick off the recap with all the new products announced this week. There’s something for everyone here, from Containers to VPCs to Secrets Store to Real Time and everything in-between.

Cloudflare’s Container Platform Launches in June 2025

During Cloudflare’s Birthday Week in September 2024, they surprised the world with an announcement not many were expecting: you would soon be able to run containerised workloads on Cloudflare’s global network.

In contrast to their existing offering, which is focussed on lightweight, serverless workloads, this opened the door to a whole host of new applications on Cloudflare — including applications you’re currently running on other cloud providers such as AWS and Azure.

As you can imagine, there was a lot of hype around this announcement. Containers are the go-to mechanism for packaging up applications these days, and when combined with Cloudflare’s focus on developer experience, it could really revolutionise the market.

Fast forward to this week  and  we got another update on containers with more implementation details, this time with a release date for the open beta: June 2025.

So what are containers going to look like on Cloudflare? Well, for the most part, much like how you use the rest of the platform. The interface is exactly the same as a Durable Object (more on that later):

import { Container } from "cloudflare:workers";

// create a new ID for a container
const id = env.CODE_EXECUTOR.idFromName(sessionId);
const sandbox = env.CODE_EXECUTOR.get(id);

// execute a request on the container
return sandbox.fetch("/some-endpoint");

// define your container using the Container class
export class CodeExecutor extends Container {
  defaultPort = 8080;
  sleepAfter = "1m";
}

When the container receives its first fetch request, it will boot up and handle that request. It will then stay alive for as long as you configure in your class that extends Container.

Much like Cloudflare Workers, the container will be spun up as close to where the request originates as possible — reducing latency between your Workers and any containers.

Anyone who has worked with containers before knows that you need a set of instructions on how to build the container, with the most common being Docker and a Dockerfile.

That’s exactly how it will work on Cloudflare, with any OCI compatible container image supported. You simply run wrangler deploy , and Cloudflare will build and push your container image to their registry, ready to be used by your application.

Now, you might be thinking: what about cold starts? Well, depending how you configure your containers, you may experience cold starts while the container boots.

However, there is configuration available to set a minimum number of instances — this means Cloudflare pre-warms your containers so they are ready to serve requests immediately. Alongside prewarming, you can also set a CPU threshold that will define when your containers scale up to meet demand — meaning autoscaling is built-in to the platform.

Earlier I mentioned that the interface was that of a Durable Object, so it might not surprise you to hear that each container instance has a companion Durable Object. In essence, the Durable Object is acting as a sidecar, allowing you to communicate with and manage its companion container.

For example, from the Durable Object, you can:

• Start a container

• Stop a container

• Execute a bash script

• Define callbacks for some events (e.g. container stops, container errors)

• Allow WebSocket connections to your container

Before moving on, let’s touch on pricing quickly, with these costs being currently advertised:

• Memory: $0.0000025 per GB-second

• CPU: $0.000020 per vCPU-second

• Disk $0.00000007 per GB-second

Unlike the rest of the Cloudflare platform, there will be charges for egress. You’ll get 1TB of transfer for free every month, and then the pricing after that is TBC.

[full article]

Enjoying the article and want to get a head start developing with Cloudflare? I’ve published a book, Serverless Apps on Cloudflare, that introduces you to all of the platform’s key offerings by guiding you through building a series of applications on Cloudflare.

Buy now: eBook | Paperback

Global Virtual Private Clouds Available Later This Year

On the face of it, the announcement of VPCs might not seem the most exciting thing ever.

However, I’ve had countless conversations with companies, small and large, that want to use Cloudflare’s Developer Platform and they simply can’t — because their AWS resources, for example, are within a VPC that Cloudflare Workers cannot securely connect to.

You can expose your resources running in an AWS VPC to the wider internet, but if it’s an internal application, you’re then exposing your internal application simply to connect it to Cloudflare — which is far from ideal. You could also toy around with Cloudflare Tunnels and Zero Trust, but that’s a lot of work, and has to be done for each application.

In terms of connecting from a Cloudflare Worker to a private API in an external VPC, it will be handled using a new binding:

const response = await env.WORKERS_VPC_RESOURCE.fetch(“/api/users/342”)

Likewise, you can connect from an external VPC to a Workers VPC using standardised URL patterns (e.g. https://<account_id>.r2.cloudflarestorage.com.cloudflare-workers-vpc.com).

Along a similar vein, at present, your Workers on Cloudflare all run globally — there are no VPCs. With the introduction of Workers VPC though, you can now segment your Workers into VPCs, significantly improving security.

That means you can, if you wish, segment different applications into their own VPCs — prevent access to its internal data stored on services such as R2 from other systems.

If you’re keen to get your hands on the new VPC functionality, you’ll have to wait for more news later in the year, when I suspect it will be available in some form of beta.

[full article]

Simplifying RAG Pipelines with AutoRAG

If you’ve ever worked on a RAG pipeline, you’ll know what a nightmare it is to setup. I actually spoke about this exact problem at Cloudflare Connect in London this week — as I’ve worked with RAG a lot in my day job.

On the face of it, you just need some documents, some embeddings and a vector database, right?

Well, if only it were that simple. What if your source documents are 100’s of pages long? You need to chunk them, and likely ensure there are overlaps between the chunks. What if your source documents are in a variety of formats? You need a parser for each one, potentially including image recognition if you have images. That’s just the initial ingestion, what about ensuring your source documents stay in sync with your data stores in an efficient manner, and ensuring deleted documents are removed from your vector database?

I could go on, but you get the idea. The asynchronous aspect of RAG, managing the underlying data, is surprisingly complex — and not something you want to build yourself.

Luckily for you and I, Cloudflare has released AutoRAG in beta, providing everything need to get started with adding RAG to your application. On the ingestion side, it handles:

• Chunking

• Parsing

• Indexing

• Storage

• Retrieval

• LLM Generation

All that’s required from your side is an R2 bucket containing the information you want to be available to your LLM, and AutoRAG will handle the rest — including keeping all the data in sync and re-indexing when needed.

Under the hood, AutoRAG uses R2, Vectorize and Workers AI in combination to provide that RAG pipeline.

On the application side, you can either opt to retrieve the raw chunks via AutoRAG and manually call an LLM with that context, or you can have AutoRAG call an LLM for you as part of a single call and pass the retrieved context automatically.

At present, only Workers AI models are available for embedding and LLM generation, so if you want to use OpenAI or Anthropic models, you’ll just want to make use of the retrieval aspect for now.

Keep in mind, as with all the products that are heading into beta, that they are just that — a beta, an early look, and not the finished products. You’ll likely experience low limits (such as 1MB max file sizes for AutoRAG) and some errors here and there — but these things will be ironed out before each product graduates to being generally available (GA).

I’ve actually tried this one out already, and I managed to implement RAG into an existing AI-powered application in literally 15 minutes, as AutoRAG just does so much of the heavy lifting.

In terms of pricing, it’s not explicitly mentioned in the article, but my assumption would be you’ll just pay for the underlying resources you use from R2, Vectorize and Workers AI, with no costs for using AutoRAG itself — but that’s just my intuition, rather than an official line.

[full article]

Managed Apache Iceberg Tables with R2 Catalog

Switching gears a little, and moving over the data side of the application lifecycle, we have what could be a significant entry in the data warehouse space.

You could argue this is adding a feature to R2 versus a new product, but I think it’s a completely different use case being unlocked, so I granted it a space in this section.

If you’ve ever seen your company’s bill for the data storage used to provide data to the likes of Snowflake, AWS Redshift and Databricks, you’ll be surprised how expensive it can be.

Last year, AWS announced S3 Tables which also provide Iceberg capabilities on top of S3 — the first time cloud object storage had been able to do this, and now Cloudflare has entered the game with their offering.

This isn’t my area of expertise, so rather than attempt to explain, I’ll let Cloudflare explain with this excerpt from their article:

If you’re not already familiar with it, Iceberg is an open table format built for large-scale analytics on datasets stored in object storage. With R2 Data Catalog, you get the database-like capabilities Iceberg is known for — ACID transactions, schema evolution, and efficient querying — without the overhead of managing your own external catalog.

R2 Data Catalog exposes a standard Iceberg REST catalog interface, so you can connect the engines you already use, like PyIceberg, Snowflake, and Spark. And, as always with R2, there are no egress fees, meaning that no matter which cloud or region your data is consumed from, you won’t have to worry about growing data transfer costs.

One thing that did immediately strike me was how much more cost-effective this will be than most other solutions, thanks to R2’s zero egress fees. If you’re using S3 currently, which does charge for egress, you could save a pretty penny by switching to R2.

On the Cloudflare side, opting your R2 bucket into being a data catalog is a one-liner with Wrangler (or use the dashboard):

npx wrangler r2 bucket catalog enable my-bucket

Once that’s complete, you can then connect using whatever mechanism you typically use — such as PyIceberg and PyArrow.

R2 Data Catalog is in open beta, and free while in open beta too. The pricing for the R2 buckets themselves remains the same as R2 today, with some additional charges (once the beta period ends) for the data catalog feature. Here’s their current thinking on pricing, but this is TBC:

During the beta period, Cloudflare will be looking at improving the performance of R2’s Data Catalog with compaction and table optimisations, alongside expanding query-engine compatibility with the Iceberg REST Catalog spec.

[full article]

Simplify Secret Management with Secrets Store

If you’ve ever used Cloudflare Workers, you’ll know that secrets are set on a per-project basis. They can either be plaintext or encrypted, but critically, they cannot be shared between projects.

If you have a lot of Workers — and some people have a serious number of Workers — and you need a secret across a number of Workers, it becomes a management nightmare. Let’s say you need to rotate an API key across 100 Workers — that’s going to be a lot of manual work, not to mention prone to human error.

Furthermore, anyone who can modify a Worker could also modify the secrets — potentially causing outages but also not respecting good security practises, where people should have as little access as they need.

This has been the state of play for quite some time, but with Secrets Store, these two problems will be no more. First announced in mid 2023, Secrets Store, as the name suggests, will allow you to create centralised stores for your secrets.

These can then be shared across Workers via bindings, meaning if you need to rotate a secret, you can do so seamlessly across all your Workers.

Additionally, Secrets Store brings RBAC into the fold, with three roles to provide fine-grained access to secrets store based on the needs of each user in your organisation

This means the ability to create, update and delete secrets can be restricted to a few people — rather than your entire engineering team. You can also scope each secret to a given product, to further enhance security. For now, there’s only Workers, but in future I suspect it will extend to the Container platform and Snippets, as two likely candidates.

Accessing a secret is nice and simple:

const openAIkey = await env.open_AI_key.get();

This does mean there is a latency hit for using Secrets Store, as I suspect it will need to make a network request — but hopefully this is minimal, and in future, hopefully it’s possible to inject secrets directly into a Worker at runtime, in the same way it works today.

During the beta, you can create up to 20 secrets for free, with pricing for more keys to be announced at a later date — I suspect when Secrets Store goes GA.

[full article]

Workers Observability Launches with Logs, Metrics & Queries

If you cast your mind back a year ago, observability on Cloudflare was sorely missing. There were real-time logs, that weren’t persisted anywhere on the Cloudflare platform, or you could push them to an external provider (which is typically quite expensive).

That made debugging exceptionally difficult. That’s why a year ago, during Developer Week, Cloudflare announced the acquisition of Baselime — an observability platform focussed on serverless platforms.

After meeting the guys behind Baselime at a conference, I actually hooked all my Workers up to their platform so I could observe my Workers — all before the acquisition.

Since then, the same team has been working on bringing observability to Cloudflare as a first-class citizen — with Workers Logs being released in beta a few months later at Birthday Week in 2024.

This week, we got to see the next evolution of Cloudflare’s observability journey, which included three drops:

• Workers Metrics Dashboard (Beta): A single dashboard to view metrics and logs from all of your Workers

• Query Builder (Beta): Construct structured queries to explore your logs, extract metrics from logs, create graphical and tabular visualizations, and save queries for faster future investigations.

• Workers Logs: Now Generally Available, with a public API and improved invocation-based grouping.

Until this week, you could only see logs for an individual Worker at a time. Thanks to the new observability dashboard, you can see an aggregated view of all your logs across your Cloudflare Workers.

To make this aggregated view more powerful, a query builder has been added to allow you to comb through your logs and find what you need. You get everything you’d typically expect with a query builder for logs including visualisations (count, sum etc.), filters, search, group by and more.

Another really nice improvement is the ability to see the CPU and wall time of your Workers, which is also queryable. And lastly, you can view logs on a per-invocation basis. For example, you may want to dive into all the logs for a given invocation to see what happened — you can do that now.

[full article]

Streaming Ingestion with Pipelines

Stick with me — we’re almost there for new products, with 3 to go.

Moving onto another product that was announced last Developer Week, we have Pipelines entering open beta (restricted to Workers Paid, $5/month). Using Pipelines, you’re able to ingest large volumes of data (100MB/s, I believe) using Cloudflare, and they’ll push it all to the R2 bucket you specify.

Imagine you need to ingest clickstream data from all your customers, where you may have a significant number of concurrent users on your site — each click, page navigation and action is recorded from every device. This can generate a large amount of data, and ingesting it can be tricky — but not with Pipelines.

You don’t need to worry about any of the underlying infrastructure, you simply create a Pipeline and link it to an R2 bucket:

npx wrangler pipelines create my-clickstream-pipeline --r2-bucket my-bucket

And that will give you a URL which you can fire your data at, it’s as simple as that.

Now, the chances are you probably want to do something with that data — not just let it sit on R2. Maybe you want to transform it, maybe you want to load it into another system for analysis.

Either way, Cloudflare has acquired Arroyo to make that a reality — with Arroyo’s offerings being brought into the Cloudflare estate. They are not available today, but will be in the future.

There’s cohesion with this announcement and the R2 Data Catalog too, as in the future you’ll be able to ingest the data straight into an R2 bucket with Data Catalog enabled, and then be able to immediately query that data.

In terms of what’s next, besides transformations, there’s integrating Workers as UDFs (User-Defined Functions), adding new sources like Kafka clients, and extending Pipelines with new sinks (beyond R2).

If you’re curious about pricing, there is no cost for Pipelines during the beta, but you will pay the R2 costs. Beyond beta, this is the proposed pricing:

• Ingestion: First 50 GB per month included in Workers Paid, $0.02 per additional GB

• Delivery to R2: First 50 GB per month included in Workers Paid, $0.02 per additional GB

With Cloudflare making more and more products available on the free plan, you’ll also be pleased to hear that will happen as the beta progresses.

[full article]

Introducing RealtimeKit: Realtime Audio & Video Experiences

Onto our penultimate new product, and it’s something quite different again to anything we’ve seen so far in this recap. I think it speaks to the depth and breadth of Cloudflare’s offering, and how much it’s grown recently.

So what exactly is Realtime? In short, it’s a suite of products to help you integrate real-time audio and video into your applications. Cloudflare Realtime brings together their SFU, STUN, and TURN services, along with a new RealtimeKit SDK.

That’s a lot of acronyms, so what exactly are they?

SFU (Selective Forwarding Unit) routes media streams between participants without decoding them, STUN (Session Traversal Utilities for NAT) helps devices discover their public IP addresses for peer-to-peer connectivity, and TURN (Traversal Using Relays around NAT) relays media through a server when direct peer-to-peer connections fail due to strict NAT or firewall settings.

In essence, it’s complicated infrastructure that is required for these real-time use cases, and setting them up yourself would be difficult and a maintenance nightmare. With Cloudflare’s offering, you can let them handle all the infrastructure, and you just plug them into your applications as-needed.

Speaking of plugging into your applications, there’s also an SDK available to make integrating these things easier. Interestingly, it’s only available in closed beta, with the sign up form here.

The SDK is quite vast, containing mobile SDKs (iOS, Android, React Native, Flutter), SDKs for the Web (React, Angular, vanilla JS, WebComponents), and server side services (recording, coordination, transcription).

I’ve never had to implement such things myself, but if I did, I’d absolutely give Realtime a go as it seems to do so much heavy lifting for me. There’s a ton of technical detail and further explanations in the announcement post, which I highly recommend giving a read.

[full article]

Deploy to Cloudflare from any GitHub/GitLab Repo

Onto the last one, and this one is small but mighty. Getting people to use your platform can be tricky — especially when the bigger players have a significant moat and head start on your.

Therefore, it’s critical to make it as easy as possible for people to try out your platform, removing as many barriers to entry as possible.

That’s why I like the new deploy to Cloudflare button, that’s available for anyone to use now in GitHub and GitLab. With one line of Markdown, you can add this button to your repository, and anyone can deploy your Worker to Cloudflare instantly.

Once clicked, it will do the following:

1. Creates a new Git repository on your GitHub/ GitLab account

2. Automatically provisions resources the app needs (including dependent resources like R2, D1 etc.)

3. Configures Workers Builds (CI/CD)

4. Adds preview URLs to each pull request

There isn’t much more to say around this one, it’s definitely a nice quality of life update, and certainly beats following a set of instructions in a README.

[full article]

💎 Major Product Updates

Are you still with me? I know, that was a lot. If you made it this far, thank you, and let me repay you with yet more content drops across a range of existing Cloudflare products & services.

In this section, we have everything from AI to Static Assets to Workflows to Hyperdrive to Durable Objects and much, much more. We’ve got a lot to cover, so let’s get going!

Agents SDK — Remote MCP & Auth

It wouldn’t be a Developer Week recap without plenty of AI, and we’re kicking it off with some AI-focussed updates to kick things off.

Earlier this year, Cloudflare released the Agents SDK to make building AI agents easier — backed by the power of the Cloudflare platform.

The SDK can be used not only to make AI Agents, but also remote MCP servers. Companies such as PayPal have already used this exact SDK to deploy their own MCP server, just to show you how quickly MCP and this SDK is growing in popularity.

However, until this week, you couldn’t power-up your AI agents by giving them the ability to connect to remote MCP servers. But good news — now you can, with the new MCPClientManager class.

Better yet, this class handles everything you need to manage the lifecycle of connecting to remote MCP servers, including transport, connection management, capability discovery, real-time updates, namespacing and authentication (via Stytch, Auth0, and WorkOS).

While the focus was on enabling AI agents to connect to remote MCP servers, there was a nice quality of life update to MCP servers built on Cloudflare too — they are now able to hibernate between requests, making them significantly cheaper to run. This is thanks to the power of Durable Objects, which are able to hibernate when not handling any requests.

If you’re curious what agent capabilities you can build with this SDK, I highly recommend checking out agents.cloudflare.com — not only does it do a great job of highlighting AI use cases and ways to solve them, it’s incredibly jazzy too.

[full article]

Workers AI — quicker, batch support, new models, LoRA & New Dash

Continuing the AI theme, we’re onto Workers AI — Cloudflare’s global inference platform for AI workloads. This means your inference tasks run significantly closer to the end user than other platforms, with Cloudflare having GPUs in close to 200 cities worldwide.

This platform is now 2–4x quicker, thanks to a series of improvements involving speculative decoding, prefix caching, an updated inference backend, and more.

Wondering what those fancy-sounding things are? Me too, so I asked ChatGPT to summarise them in a sentence:

Speculative decoding in LLMs accelerates text generation by having a smaller, faster model predict possible continuations that a larger model then verifies, while prefix caching reuses previously computed hidden states to avoid redundant calculations when generating text from shared prompts.

Well, that clears that up nicely — and to ensure there was no impact to the quality of the responses, there was extensive A/B testing before this has been applied. For now, it’s only applied to cf/meta/llama-3.3–70b-instruct-fp8-fast, but presumably will be rolled out wider over time.

Moving onto another topic, let’s talk about batch processing. Until this week, you could only synchronous call models hosted on Workers AI — even if you didn’t have an immediate need for the response, or needed all responses to be returned before you processed them.

Now however, you can pass an additional parameter when calling Workers AI, and it will queue the request rather than return immediately. You can then poll for the response via API or the AI binding.

In terms of why you might use this piece of functionality, consider that sometimes GPUs get overloaded and can’t handle your response — or take a long time to do so. If you don’t immediately need a response, it’ll be better to schedule it via the batch functionality, which will handle retries automatically.

Switching topic one again, we’re onto LoRAs — which are now available on more models.

In essence, a Low Rank Adaptation (LoRA) adapter allows people to take a trained adapter file and use it in conjunction with a model to alter the response of a model. Think of it like a cheaper alternative to fine-tuning, where you can make a model more suited to your use case.

LoRA support is/will be available for the following models:

• @cf/meta/llama-3.2–11b-vision-instruct (soon)

• @cf/meta/llama-3.3–70b-instruct-fp8-fast (soon)

• @cf/meta/llama-guard-3–8b

• @cf/meta/llama-3.1–8b-instruct-fast (soon)

• @cf/deepseek-ai/deepseek-r1-distill-qwen-32b (soon)

• @cf/qwen/qwen2.5-coder-32b-instruct

• @cf/qwen/qwq-32b

• @cf/mistralai/mistral-small-3.1–24b-instruct (soon)

• @cf/google/gemma-3–12b-it (soon)

While we’re talking about models, there are some new brand ones too (and I stole the descriptions from the blog post rather than rehashing them):

• @cf/mistralai/mistral-small-3.1–24b-instruct: a 24B parameter model achieving state-of-the-art capabilities comparable to larger models, with support for vision and tool calling.

• @cf/google/gemma-3–12b-it: well-suited for a variety of text generation and image understanding tasks, including question answering, summarization and reasoning, with a 128K context window, and multilingual support in over 140 languages.

• @cf/qwen/qwq-32b: a medium-sized reasoning model, which is capable of achieving competitive performance against state-of-the-art reasoning models, e.g., DeepSeek-R1, o1-mini.

• @cf/qwen/qwen2.5-coder-32b-instruct: the current state-of-the-art open-source code LLM, with its coding abilities matching those of GPT-4o.

One last thing for Workers AI before we move on: there is a shiny new dashboard to help you understand your AI workloads that shows your usage in traditional measurements (tokens, seconds) versus the Neurons that Cloudflare has been using — I really like this one as it makes it a lot easier to reason about your usage, as people are used to using tokens, for example.

[full article]

Durable Objects — Available in the Free Tier

I cannot understate how excited I am for this announcement. For as long as Durable Objects have existed, they have been gated behind the Workers Paid plan. By no means a large barrier to entry, but if you simply wanted to try them out, $5 was probably going to put you off.

With Durable Objects underpinning the Agents SDK, and being very unique and magical, you won’t find anything like these anywhere else, it’s a no-brainer to make them available on the free plan.

For the uninitiated, Durable Objects are effectively defined in your code as normal-looking classes. However, they are far from normal, as at runtime you’re able to spin up effectively unlimited instances of these classes — but the twist is they are not instantiated in the same process as the calling code, it spins up a remote server where the code is executed.

You can spin up as many of these as you need on-demand, with some Cloudflare customers having millions of instances of Durable Objects. Each instance is unique, and there can only ever be one instance with a given ID active at any one time globally, making them perfect for multiplayer and coordination.

They come packed with features too, including:

• Durable storage (Key-value, SQLite) — they hibernate between requests, but their storage remains intact between restarts.

• WebSockets built-in — you can genuinely connect via WebSockets in a few lines of code, and they hibernate between WebSocket messages, making them incredibly cost-efficient.

• Alarms, to handle scheduled tasks

• The ability to make RPC calls to a Durable Object from other Cloudflare products such as Workers

At first, it can be hard to get your head around Durable Objects, or even explain them to anyone. But, I highly recommend you give them a try, as they are incredibly powerful. And as you just learned, they are now available to try for free. The free plan is pretty generous too:

[full article] (part of the Agent MCP post, but I felt like it deserves its own!)

D1 — Support for Global Read Replication

Moving away from AI and onto databases — we’ll cover D1 first, and then take a look at what’s new with Hyperdrive.

If you’ve not heard of D1 before, it’s Cloudflare’s SQLite offering. Well, technically, they have two, as I just explained that Durable Objects have SQLite capabilities too!

When to use each is a topic in its own right, but considering D1 now has read replicas globally, the quick answer is use D1 when you need that global availability. As a Durable Object exists in one location, you may experience high latency when making calls from the other side of the world, at least when compared to D1.

Winding back a little, D1 has been around for quite a while now, with its beta landing in September 2023. It’s perfect to store things like configuration, user data, session data and other app-wide data.

However, it had a significant drawback, in that your database resided in a single location. This made reads potentially slow, as they would have to travel significant distances if the user request originated the other side of the world to your database.

The good news is, this is a problem of the past, with read replicas now being available to everyone. It’s in beta, and you can enable on it a per-database basis in the dashboard.

Before you do though, you need to understand two concepts to ensure your reads perform as you expect:

• Sessions are required to ensure sequential consistency. Whenever you run a query, you do so via a session with a unique ID, ensuring that all your queries go to the same replica. This ensures you get consistent results you expect, as the replicas will asynchronously sync their data between themselves. You can either opt to start a session from the primary (ensuring data is the latest) or a replica (where the data may lag behind the primary).

• Bookmarks are references to a point within a session, and need to be passed to all your queries after the initial query. This ensures that your query is served by a database that is at least up to date as your last query using this bookmark.

It sounds a little fiddly, and will take some getting used to, but unfortunately with a global platform comes global problems, and this is one of them. It may take some getting used to, and it will be interesting how difficult the sessions and bookmarks are to deal with in a real-world application.

If you want more information, I recommend diving into the docs or reading the full article linked below.

[full article]

Hyperdrive — MySQL support & Free Tier

Moving onto the service with possibly the coolest name at Cloudflare, we have Hyperdrive, which was first released in September 2023. Hyperdrive is Cloudflare’s service for speeding up your database queries against region-locked databases.

Much like D1 read replication, Hyperdrive is solving somewhat of a unique challenge that Cloudflare faces. With its platform being global, and your Workers being spun up in over 330 cities around the world, what happens when your Worker needs to connect to a database that’s tied to a single location?

In short, it becomes quite slow — especially if you’re executing multiple queries within a single request. That’s because each query will need to go from say Australia to Europe every single time, and additionally, you’ll need to connect to the database each time a Worker is spun up, which is quite often each time a new request comes in as Workers don’t typically hang around for long.

If you’re in a more traditional cloud setup, your compute is probably sitting in the same region as your database, so the latency is actually pretty small between your application and the database. However, there will be high latency from the end user to the actual compute — even for retrieving static assets like images and CSS.

This is where Hyperdrive comes in, which has two primary features:

1. It acts as a connection pooler, so rather than every instance of your Worker having to connect to the database separately and each time it’s started, Hyperdrive keeps your database connections alive and ready to be used. Considering it takes several round trips to establish a database connection, this is a huge saving on latency.

2. It has the ability to cache non-mutating queries (e.g. reads) so that for repeated queries, you don’t need to go fetch from your origin database, drastically improving performance by using Cloudflare’s global cache. This is configurable, and you can disable it if you wish.

Ultimately, it’s a no-brainer to use Hyperdrive if you’re connecting to a database that’s locked away in a single region.

As an aside, you’ll want to enable Smart Placement too, which tactically works out the best place to spin up your Worker. By default, the Worker will be spun up as close to the end user as possible. However, if you’re making several database queries, or API calls to externally-hosted systems, Cloudflare can move your Worker to a location that will reduce latency between your Worker and any downstream systems.

Alright back to Hyperdrive, and what’s new for Developer Week?

To start, it now supports MySQL. Up until now, it’s only supported Postgres, so if you have an existing MySQL database you need to connect to, you’re in luck.

In terms of compatibility, it supports MySQL and MySQL-compatible databases (e.g. PlanetScale, Azure, Google Cloud SQL, AWS RDS and Aurora) along with the following database drivers (mysql2, mysql, Drizzle, Kysely).

Secondly, you can now use Hyperdrive on the free tier. I’m a huge fan of adding as much as possible to the free tier, as it allows anyone to try out a service without any commitment.

You get 100,000 database queries per day on the free tier, any beyond that will error out. Just for reference, if you do need more throughput than that, you get unlimited queries on the $5/month Workers Paid plan.

[Hyperdrive explainer | MySQL announcement]

Workflows — Increased Throughput, New APIs & Generally Available

Up next, we’re going to cover one of Cloudflare’s newest products: Workflows. I probably don’t need to explain too much about what they do, as the name is pretty self-explanatory.

In essence, Workflows are Cloudflare’s take on Durable Execution. You can define a Workflow, that has a series of steps, and Cloudflare will execute that Workflow, including recovering from errors and automatially retrying failed steps.

Furthermore, it will keep track of what steps passed on any prior runs, and automatically rehydrate any state needed from steps that successfully completed.

For example, let’s say you have a Workflow that downloads a CSV file on a daily basis and inserts each row into a database. You could do this with a simple scheduled task, but what happens if a database query fails in the middle of the job?

If it’s just a temporary blip, you can retry, but what if your actual database is down, or the host for the CSV file is unavailable? Now you either need something to retry the entire job, or in the case of it failing part-way through, you don’t want to insert duplicate records, so now you need to handle that too, which is a bit of a pain.

All these failure cases are a pain to deal with, but not with Workflows. With Workflows, you could have one step that downloads the CSV and stores it in the Workflow’s state, and then trigger a step for every single row in the CSV to insert it into the database.

If there were 500 rows, and it failed on row 400, the entire Workflow would re-run — but it would know that the first 400 steps succeeded and not re-run those, and pick up where it left off.

Just to preempt, I know 500 rows isn’t a lot and you could likely do one big insert. But what if you’re dealing with 500,000 rows? Going to be a little bit trickier.

Retries and how long to wait between retries is all configurable, and the APIs are really easy to use as they are all written in vanilla JavaScript. You can also have a Workflow pause for a set amount of time too (or a date/time in the future).

In terms of what’s new for Developer Week, my favourite addition is the new waitForEvent API. As soon as I started using Workflows, I wished for a way to pause a Workflow until an event outside my Workflow happened (so much so, I wrote a little hack for it with Durable Objects).

To explain what this enables, let’s say your Workflow takes care of your user onboarding flow. The user signs up, confirms their email, and then we create their account and send them a welcome email.

We don’t want to send that welcome email until the user has confirmed their account, but we do want to send the actual confirm account email. Workflows would be perfect for this, as if the email sending fails to confirm their account, that’s going to be really frustrating — so we can rely on its retries to ensure it’s sent.

The Workflow needs to wait for the user to click the link in the email before sending the welcome email though, so at that point we can make use of the new waitForEvent functionality.

Once the user clicks the link, we can send an “event” to our Workflow and it can resume and send the welcome email — super simple, and super reliable. In terms of sending that event, you can either use a binding from a Worker, or use the Cloudflare REST API.

Alongside the new API, there’s a few more quality of life updates:

• Concurrent limits increased: Initially the limit was really low, but as the product has moved through beta, the limits have been raised, and it now stands at a pretty respectable 4,500. This limit will go higher throughout the year, expected to reach 10,000 concurrent workflows by the end of the year.

• Improved observability: you can now see CPU time for each Workflow instance in the dashboard.

• Vitest support: to enable you to run tests locally and in CI/CD pipelines, there’s now Vitest support for Workflows.

[full article]

Static Asset Workers — Frameworks Go Generally Available

During Birthday Week last year, Cloudflare started the migration of Pages to Workers with the release of Static Asset Workers in beta. For as long as I can remember, Pages has been the go-to option for hosting static and full-stack websites on Cloudflare.

However, there were always some drawbacks with it, such as not being able to use Durable Objects without creating a separate Worker, and more recently, not having access to Workers Logs.

To solve this problem, the direction from Cloudflare is to move static asset hosting into Workers, in the form of Static Asset Workers. This was confirmed this week with the announcement that no new features would be added to Pages.

If you’re currently hosting sites on Pages, there’s no need to worry about support suddenly disappearing. However, investment, optimisations, and feature work will be focussed solely on Workers when it comes to hosting websites going forward.

Fast forward 7 months, and Static Asset Workers are now generally available, alongside a number of frameworks that it supports:

• React Router v7 (Remix)

• Astro

• Hono

• Vue.js

• Nuxt

• Svelte (SvelteKit)

• Qwik

• Gatsby

• Docusaurus

• Angular

This means you can now safely migrate projects that rely on these frameworks from Pages to Workers, and reap all the benefits of wider support for the rest of the Cloudflare developer platform.

If you want to have a go at that migration, there’s a guide available here.

There are some notable frameworks that are not moving to GA, with Next.js and Solid both staying in beta for now. With Next.js notoriously difficult to host on infrastructure outside of Vercel, Cloudflare is working to make OpenNext work seamlessly on Cloudflare with an adapter.

That adapter is now hitting its first major milestone: v1 is available, but still in beta form for now. Most of the Next.js 15 features are supported, including:

Cloudflare will continue iterating on the adapter until it’s ready to hit GA, which I suspect will happen later this year. I really like this initiative as it removes the vendor lock to Vercel that has typically existed for many years around Next.js.

Before moving onto the next section, there’s one more thing worth mentioning around serving sites via Workers, and that’s Vite support on Cloudflare hitting v1, alongside support React Router v7.

[Static Assets GA | OpenNext v1 | Vite v1]

Snippets Are Generally Available

Time for a bit of a history lesson on this one, as it really hits home how far the Cloudflare developer platform has come. When I first heard of Cloudflare Workers, many years ago, they were released as a way to make simple changes to HTTP requests — modify headers, add cookies, things like that.

From memory, it was only possible to edit them via a UI too, which was particularly terrifying, but I honestly might be misremembering that. Either way, it’s fair to say you couldn’t do much with a Worker at that time.

Fast forward to 2025, and as we just covered, Workers can now serve static assets, including a ton of popular frameworks, but they can also be created with any language that supports WebAssembly, they can be APIs, they can be cron jobs, they can consume messages from a Queue, it’s fair to say they are incredibly versatile.

The original use case still exists though, such as making some simple modifications to a HTTP request or response, and for that a Worker is now a little overkill — it can certainly do it, but Snippets now cater for the original purpose that Workers were created for.

If you need to transform headers dynamically, fine-tune caching, rewrite URLs, retry failed requests, replace expired links, throttle suspicious traffic, or validate authentication tokens, that’s where Snippets shine.

So why would you use Snippets over a Worker? That one is easy, it comes down to cost. With a Worker, you pay for the number of requests you handle and the CPU you use. With Snippets, they are free on any paid plan (Pro, Business & Enterprise — they are not currently available on Workers Paid).

If you’re wondering when to use a Worker and when to use a Snippet, Cloudflare’s got you covered:

While not available just yet, later in the year you’ll also be able to access values from Secrets Store from Snippets too.

[full article]

Super Slurper — 5x Faster With A New Architecture

You’ll perhaps be relieved to know we’re at the end of the recap of Developer Week 2025, with this being the final entry.

If Hyperdrive has the coolest name of any Cloudflare service, then Super Slurper takes the award for the most fun (although its companion, Sippy, is a close second).

Super Slurper is used in combination with R2 to migrate contents from S3-compatible storage on other cloud providers, such as AWS and Google Cloud Storage.

It’s an all-at-once migration, so it will migrate all the objects in one big migration. This is in comparison to Sippy, which does it object-by-object as you request them from an external source.

One of the barriers to entry for moving data across clouds is the difficulty in doing so, but with Super Slurper, it should be a breeze. And better yet, it’ll now be 5x faster to move your data across thanks to a re-architecture of the tool, making use of Workers, Durable Objects and Queues.

If you’re new to the Cloudflare platform, you’ll probably not realise that the vast majority of Cloudflare’s offerings involve “dogfooding” their own products. This is another example of that, with Super Slurper moving from Kubernetes to a native Cloudflare solution.

There’s a ton of detail around how they achieve this in the blog post, which I’d recommend checking out, as I personally really enjoy the technical depth that a lot of Cloudflare’s blog posts go into.

[full article]

Closing Thoughts

That brings us to the end of my Developer Week recap, and this is definitely one of my favourite Developer Weeks so far.

There’s just so much variety, and you can see that the platform just goes from strength-to-strength, allowing you to build quicker, more efficiently and lets you focus on what you do best: shipping.

I want my developer platform of choice to get in the way as little as possible, while still doing as much of the heavy-lifting as possible. In my view, that’s exactly what Cloudflare does.

I can effortlessly create products and services, with excellent developer experience when developing locally, and push them to production in a few seconds. I also know I can rely on the platform to be stable, and take care of things like scaling and high availability for me.

Above all else, building on the platform is just fun and a joy, I highly recommend you give it a go for yourself — and try out some of the developments announced this week!

Enjoyed the article and want to get a head start developing with Cloudflare? I’ve published a book, Serverless Apps on Cloudflare, that introduces you to all of the platform’s key offerings by guiding you through building a series of applications on Cloudflare.

Buy now: eBook | Paperback