{
  "version": "2",
  "id": "https://freelancenews.online/news/cloudflare-adds-durable-object-scheduling-policy-for-containers-in-afa32fb7",
  "title": "Cloudflare adds Durable Object scheduling policy for Containers in public beta",
  "summary": "A new public-beta scheduling policy lets a Durable Object pick a Container's image and instance size at runtime, and adds a Cloudflare-managed Debian Trixie image with Node.js 24.20.0.",
  "body": "Cloudflare has introduced a new scheduling policy for Containers that lets a Durable Object choose both the image and the instance size for a Container at runtime, rather than relying on a single centrally managed configuration for the whole application. The company describes the capability as being in public beta, and documents it in a changelog entry dated 30 September 2026.\n\nThe change matters because it moves a decision that was previously application-wide down to the level of an individual Durable Object. Under the new policy, the object itself supplies the image reference and the instance size when it starts a Container, so different objects in the same application can run different images or different sizes without a shared rollout configuration.\n\nConfiguration happens in Wrangler. Developers set the scheduling policy to the value durable_object and declare one or more named images, each pointing at a Dockerfile. Cloudflare's example uses a class named AgentComputer with a named image called base built from ./container/Dockerfile, and shows the same structure expressed in both JSON and TOML forms.\n\nAt runtime, Wrangler prepares each declared image and exposes an immutable reference to it through ctx.container.images. The Durable Object then passes that reference, along with an instance size, into the container start call. Cloudflare's documented example starts the container with the base image reference, internet access disabled, and an instance size of standard-2.\n\nThe policy also supports a new Cloudflare-managed image, cloudflare/debian-trixie, which the changelog says includes Node.js 24.20.0 on Debian Trixie slim. According to the source, this managed image can be started directly without configuring a named image first, which removes the need to declare and build a Dockerfile for that particular base.\n\nOne documented consequence concerns lifecycle. Container instances managed by a Durable Object have independent lifecycles and, per the changelog, do not participate in application-wide image rollouts. That is a meaningful operational difference: updating a shared image configuration will not necessarily move objects that are running under this policy onto a new image.\n\nThe changelog points readers to a separate Scheduling Policies page for configuration, runtime sizing, snapshots and update behavior. Those details are not reproduced in the supplied evidence, so the exact mechanics of snapshots, how instance sizes map to resources, and how updates propagate remain outside what can be confirmed here.\n\nFor freelancers and small development teams working on Cloudflare Workers and Durable Objects, the practical appeal is per-object control. A single application could, in principle, run a heavier instance size for one class of object and a lighter one for another, or pin different objects to different images, without maintaining separate deployments for each variation.\n\nThat flexibility comes with a tradeoff that the source states directly rather than merely implies. Because these instances sit outside application-wide image rollouts, teams that adopt the policy take on more responsibility for tracking which objects run which image and for deciding when each one should move to a newer build. The supplied excerpts do not include a description of any automatic reconciliation between those independent lifecycles; whether such a mechanism exists elsewhere in Cloudflare's documentation is not something this evidence can settle.\n\nThe managed Debian Trixie image is the other concrete addition. Naming a specific Node.js version, 24.20.0, on a slim Debian base gives developers a documented starting point that does not require their own Dockerfile, which is useful for projects that want a standard runtime without maintaining image build configuration.\n\nSeveral things are not established by the available evidence. The changelog does not state pricing for the new policy or for the managed image, does not give a general availability date beyond the public beta label, and does not quantify performance or cost differences between instance sizes. It also does not say whether the policy is available in every Cloudflare region or on every plan.\n\nThe source likewise does not describe migration behavior for existing Containers, nor does it explain what happens to a running instance when its underlying image reference changes. Those are open questions a team would need to resolve against Cloudflare's fuller Scheduling Policies documentation before committing production workloads.\n\nIt is also worth being precise about what kind of change this is. This is a configuration and runtime-selection capability for an existing product, not a new product line, and the evidence describes it as a public beta rather than a finished release. Beta status is itself a limitation: interfaces and behavior can change before general availability.\n\nFor this audience, the sensible reading is that the policy is worth evaluating where per-object image or size selection solves a real problem, and less compelling where a single application-wide configuration already works. The independent lifecycle is the detail most likely to affect day-to-day operations, because it changes what an image update actually does.\n\nThe changelog's own framing is narrow: it announces the policy, shows the Wrangler configuration shape, shows the start call, names the managed image, and states the lifecycle caveat. Anything beyond that, including how snapshots interact with the policy, is deferred to other documentation that is not part of this evidence.",
  "category": "dev",
  "language": "en",
  "datePublished": "2026-09-30T12:17:45.492Z",
  "dateModified": "2026-09-30T12:17:45.492Z",
  "eventDate": "2026-09-30",
  "sourcePublicationDate": "2026-09-30T00:00:00.000Z",
  "source": {
    "name": "developers.cloudflare.com",
    "url": "https://developers.cloudflare.com/changelog/post/2026-09-30-durable-object-scheduling-policy/",
    "kind": "official-publisher"
  },
  "practicalImpact": "Editorial interpretation: teams already using Durable Objects can evaluate whether per-object image and instance-size selection removes the need for separate deployments or shared rollout configuration. The managed Debian Trixie image offers a documented Node.js 24.20.0 starting point without maintaining a Dockerfile. The main operational cost is that these instances sit outside application-wide image rollouts, so teams must track which objects run which image and decide when each moves forward.",
  "limitations": "The evidence is a single Cloudflare changelog entry, and the supplied excerpts are truncated rather than the full document. It does not state pricing, plan or region availability, general availability timing, instance-size resource mappings, snapshot behavior, or how existing Containers migrate. The policy is described as public beta, so behavior may change. No independent testing or third-party confirmation is available, and the linked Scheduling Policies documentation is not included in the supplied evidence.",
  "keyPoints": [
    "Cloudflare's Containers now support a durable_object scheduling policy in public beta, letting a Durable Object select the image and instance size at runtime instead of using one centrally managed application configuration.",
    "Wrangler configuration sets scheduling_policy to durable_object and declares named images built from Dockerfiles; Wrangler exposes each prepared image as an immutable reference via ctx.container.images.",
    "A Durable Object starts a Container by passing that image reference and an instance size, as in the documented example using the base image, internet disabled, and instance size standard-2.",
    "The policy supports the new Cloudflare-managed cloudflare/debian-trixie image, which includes Node.js 24.20.0 on Debian Trixie slim and can be started without configuring a named image.",
    "Durable Object-managed Container instances have independent lifecycles and do not participate in application-wide image rollouts, per the changelog."
  ],
  "review": {
    "status": "source-reviewed",
    "checkedAt": "2026-09-30T12:17:45.492Z",
    "method": "Automated comparison against retrieved source text; not independent fact-checking.",
    "correctionNote": null
  },
  "sources": [
    {
      "id": 1,
      "url": "https://developers.cloudflare.com/changelog/post/2026-09-30-durable-object-scheduling-policy/",
      "publisher": "developers.cloudflare.com",
      "title": "Changelog",
      "publishedAt": 1790726400000,
      "fetchedAt": 1790770645036,
      "hash": "8a7aaf189380073f1298e14f8c640cdebcde958cdbad95e93d3f59134fad3536",
      "kind": "official-publisher"
    }
  ],
  "claims": [
    {
      "claim": "Cloudflare says Containers support a durable_object scheduling policy in public beta that lets a Durable Object select the image and instance size at runtime instead of using one centrally managed application configuration.",
      "source": 1,
      "id": "claim-1",
      "url": "https://freelancenews.online/news/cloudflare-adds-durable-object-scheduling-policy-for-containers-in-afa32fb7#claim-1"
    },
    {
      "claim": "Wrangler configuration sets the policy to durable_object and declares named images built from Dockerfiles, shown in both JSON and TOML.",
      "source": 1,
      "id": "claim-2",
      "url": "https://freelancenews.online/news/cloudflare-adds-durable-object-scheduling-policy-for-containers-in-afa32fb7#claim-2"
    },
    {
      "claim": "Wrangler prepares each image and exposes an immutable reference through ctx.container.images, which is passed with an instance size when starting the Container.",
      "source": 1,
      "id": "claim-3",
      "url": "https://freelancenews.online/news/cloudflare-adds-durable-object-scheduling-policy-for-containers-in-afa32fb7#claim-3"
    },
    {
      "claim": "The policy supports the Cloudflare-managed cloudflare/debian-trixie image, which includes Node.js 24.20.0 on Debian Trixie slim and can be started without configuring a named image.",
      "source": 1,
      "id": "claim-4",
      "url": "https://freelancenews.online/news/cloudflare-adds-durable-object-scheduling-policy-for-containers-in-afa32fb7#claim-4"
    },
    {
      "claim": "Durable Object-managed Container instances have independent lifecycles and do not participate in application-wide image rollouts.",
      "source": 1,
      "id": "claim-5",
      "url": "https://freelancenews.online/news/cloudflare-adds-durable-object-scheduling-policy-for-containers-in-afa32fb7#claim-5"
    }
  ],
  "formats": {
    "html": "https://freelancenews.online/news/cloudflare-adds-durable-object-scheduling-policy-for-containers-in-afa32fb7",
    "markdown": "https://freelancenews.online/news/cloudflare-adds-durable-object-scheduling-policy-for-containers-in-afa32fb7.md",
    "json": "https://freelancenews.online/news/cloudflare-adds-durable-object-scheduling-policy-for-containers-in-afa32fb7.json"
  }
}