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.