Cloudflare Containers: Durable Object Scheduling, Snapshots, and Recovery

Two announcements, with different scopes

Cloudflare published the Durable Object scheduling announcement and container snapshot announcement on September 30, 2026. Both explicitly say public beta. Scheduling lets instances in one application use different images; snapshots restore files after sleep, restart, or transfer to another Durable Object. Snapshots require the new scheduling policy.

The scheduling documentation lists default and durable_object. With default, Wrangler specifies one application image and instance_type; image updates roll out across the application. With durable_object, code chooses each instance's image and size at ctx.container.start(), and instances do not automatically follow image-map updates. Default remains simpler when all instances share a configuration.

Step 1: Configure a new durable_object application

Set scheduling_policy to durable_object in the Wrangler containers entry, specify class_name, and name Dockerfiles in images. Match the Durable Object binding and class names. Wrangler prepares digest-pinned image references, available through values such as ctx.container.images.base. Without a custom image, the documentation provides the hosted cloudflare/debian-trixie image for the image parameter. See the official configuration example for the full structure.

Check ctx.container.running, then call ctx.container.start({ image: ctx.container.images.base, instance: "standard-2", enableInternet: false }). Instance options are lite and standard-1 through standard-4; lite is the default. Custom runtime sizing uses memoryMib and diskMb, whereas Wrangler default-policy instance_type uses memory_mib and disk_mb. start() returns before readiness, so perform your own readiness check before forwarding requests or using exec().

This policy does not support max_instances; running instances still count toward account limits. Control outbound access explicitly with enableInternet. Proxy access is not a prerequisite for the feature. Changing the image map does not restart running instances: application code must arrange any required stop and restart.

Step 2: Save the running container's filesystem

Following the snapshot guide, call await this.ctx.container.snapshotContainer({ name: "before-upgrade" }) on a running Container. The returned handle is a plain data object. Persist it in Durable Object storage or pass it to another Durable Object for restoration. It captures the complete filesystem at that moment, not running processes, memory, or an automatic backup of Durable Object storage.

Take the snapshot after writes finish and application state is consistent. Record the image version, logical container ID, and handle together. Snapshots are immutable: files changed after restoration need a new snapshotContainer() call. They are not a migration mechanism across image versions. A snapshot is bound to its creation image; create a new snapshot from a container running the new image after an upgrade.

Step 3: Restore a handle and check the result

Read the saved containerSnapshot from storage and confirm it exists, then call this.ctx.container.start({ containerSnapshot, enableInternet: false }). containerSnapshot and image are mutually exclusive because the snapshot already defines the filesystem image. Do not attach an old handle to a new image. After start(), wait for readiness, then read representative files and check expected data and application health.

The official retention rules specify an implicit 30-day lifetime, renewed with each restoration; custom TTL is not currently supported. Use separate persistent storage and backups for long-lived data. An unused snapshot is not a permanent backup. Test how your application handles missing or expired handles, image mismatches, and repeated restoration.

Migration needs a new application and namespace

The Cloudflare migration guide says an existing Container application cannot change scheduling_policy directly. Create a new application, Durable Object class, and namespace, keeping the original application and bindings available for rollback. If the original class extends Container from @cloudflare/containers, the new class uses the Durable Object Container API directly; recreate its readiness, request forwarding, sleep, and other helper behavior yourself.

Test images, sizing, network boundaries, entry points, and readiness on a separate route, then switch logical containers or gradually move traffic. Do not randomly route requests for the same sandbox between two namespaces. A new namespace cannot read the old namespace's Durable Object storage; stateful applications need a separately designed and tested migration. Keep the old route during observation and account for writes to the new namespace when rolling back. Deleting the old application removes its containers, while removing its Durable Object class removes storage; clean them up separately only when no longer needed.

Checks before use, and unresolved conditions

In a usable test account, verify deployment of the new policy and images, expected per-object image selection and default sizing, appropriate outbound access, restoration in the original and another object, new snapshots after changed files, the 30-day retention behavior, and observable traffic migration and rollback. Calculate costs against the account's current Containers, Durable Objects, storage, and network pricing.

As of September 30, 2026, the announcements and guides establish the two public betas, their API basics, and limitations. They do not guarantee identical access for every account, region, or existing application, nor provide a separate production-stability commitment or comprehensive beta price list. Recheck your account, current documentation, and billing before use. This is a Cloudflare platform guide; PuppyIP products are not required for these APIs.