# Cloudflare adds Durable Object scheduling policy for Containers in public beta 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. Canonical URL: https://freelancenews.online/news/cloudflare-adds-durable-object-scheduling-policy-for-containers-in-afa32fb7 Published: 2026-09-30T12:17:45.492Z Updated: 2026-09-30T12:17:45.492Z Source published: 2026-09-30T00:00:00.000Z Event date: 2026-09-30 Review status: source-reviewed Review method: Automated comparison against retrieved source text; not independent fact-checking. ## Report 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. The 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. Configuration 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. At 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. The 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. One 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. The 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. For 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. That 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. The 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. Several 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. The 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. It 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. For 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. The 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. ## Key points - 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. ## Practical implications — editorial interpretation 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 and unknowns 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. ## Sources - [1] developers.cloudflare.com: Changelog https://developers.cloudflare.com/changelog/post/2026-09-30-durable-object-scheduling-policy/ Retrieved: 2026-09-30T12:17:25.036Z ## Claim references - 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] - Wrangler configuration sets the policy to durable_object and declares named images built from Dockerfiles, shown in both JSON and TOML. [source 1] - 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] - 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] - Durable Object-managed Container instances have independent lifecycles and do not participate in application-wide image rollouts. [source 1]