# Cloudflare Containers can now let each Durable Object choose its own runtime — and snapshot its filesystem Cloudflare has put a new Containers scheduling policy into public beta that lets each Durable Object choose a container image and instance size at runtime, while new immutable filesystem snapshots can preserve and restore container state. The architectural shift is from application-wide container configuration toward individually managed stateful compute. A Durable Object can now start its own image and size, keep an independent lifecycle and restore filesystem state without treating every instance as part of one rollout. - Status: Active - Published: 2026-10-01T06:09:56+13:00 - Updated: 2026-10-01T06:09:56+13:00 - Categories: Cloud & Infrastructure, Cloud Platforms, Compute & AI Infrastructure, Deployment & DevOps - Tags: Cloudflare, containers, Durable Objects, snapshots, stateful compute - Canonical HTML: https://beyondthe.news/dossiers/cloudflare-containers-durable-object-scheduling-filesystem-snapshots ## What changed On September 30, 2026 Cloudflare introduced the `durable_object` scheduling policy for Containers in public beta. Instead of a centrally configured image and instance type for an application, a Durable Object can select an immutable image reference and instance size when it starts a Container. Cloudflare also documented filesystem snapshots for Containers using this policy, allowing point-in-time filesystem state to be captured and restored later. ## Why it matters This gives builders a more stateful, individually addressable compute model inside Cloudflare's platform. Agent sandboxes, development environments and other long-lived workloads can choose runtime resources per instance and preserve disk state without coupling every instance to an application-wide image rollout. It narrows the gap between serverless orchestration and VM-like lifecycle control, while retaining important constraints around image compatibility and snapshot scope. ## A Durable Object can now decide what Container to run With the new scheduling policy, Wrangler prepares configured images and exposes immutable references through the Durable Object Container API. The Durable Object supplies the image and instance size when starting the Container. Cloudflare also provides a managed Debian Trixie image with Node.js 24.20.0 that can be started without defining a custom image. ## Instances stop participating in one application-wide rollout Cloudflare says Durable Object-managed Container instances have independent lifecycles and do not participate in application-wide image rollouts. That gives an application more control over when individual stateful workloads move between images or sizes, but it also means builders need an explicit update strategy for those instances. ## Snapshots preserve disk state, not a running process Snapshots capture the Container's complete filesystem state but not memory or running processes. They are immutable and tied to the Container image version that created them. A snapshot cannot be restored onto a different image version, and applications must use the durable_object scheduling policy to create or restore one. ## Key details - The `durable_object` scheduling policy entered public beta on September 30, 2026. - A Durable Object can select the Container image and instance size at runtime. - Durable Object-managed instances have independent lifecycles and do not join application-wide image rollouts. - Cloudflare provides a managed `cloudflare/debian-trixie` image with Node.js 24.20.0. - Filesystem snapshots are available only with the `durable_object` scheduling policy. - Snapshots capture the complete filesystem but not memory or running processes. - Snapshots are immutable and tied to the image version from which they were created. ## Builder takeaways - Agent and sandbox platforms can assign different runtime images or sizes per stateful Durable Object instead of treating every Container as one deployment cohort. - Use snapshots for disk-state checkpoints, not process checkpointing; application code must recreate in-memory state after restore. - Plan image migrations deliberately because a snapshot is not portable across image versions and independently managed instances do not automatically follow application-wide rollouts. - Treat the feature as public beta and test lifecycle, recovery and billing behaviour before relying on it for critical production state. ## What to watch - Pricing and retention details for filesystem snapshots. - Whether Cloudflare expands snapshots beyond the durable_object scheduling policy. - How image upgrades and fleet management evolve for independently managed Container instances. - Production evidence from agent sandboxes, development environments and other stateful workloads using the new lifecycle model. ## Uncertainties - The scheduling policy is public beta, so APIs and operational limits can still change. - The current snapshot documentation does not establish VM-style memory/process checkpointing; only filesystem state is captured. - Independent production performance and recovery measurements are not yet available. ## Sources - [New scheduling policy for Containers to configure image and instance from Durable Objects](https://developers.cloudflare.com/changelog/post/2026-09-30-durable-object-scheduling-policy/) — Cloudflare Docs · primary changelog · 2026-09-30T00:00:00+13:00. Primary announcement for the public-beta scheduling policy, runtime image/instance selection and independent lifecycle model. - [Use snapshots](https://developers.cloudflare.com/containers/guides/snapshots/) — Cloudflare Docs · primary documentation · 2026-09-30T00:00:00+13:00. Primary documentation for filesystem snapshot scope, policy requirement, immutability and image-version compatibility.