Scheduling Policies

A scheduling policy determines where you configure a Container image and instance size. It also determines how image updates and rollouts apply. Choose the policy when you create the Container application.

One Wrangler configuration can contain applications with both policies. This lets a Worker use centrally managed service Containers alongside Durable Object-managed sandboxes.

The scheduling policy is immutable. To use a different policy, create a new Container application. Deleting an application also deletes its Container instances, so switching policies means replacing every running instance. To move an existing application, refer to Migrate to the Durable Object scheduling policy.

With the default policy, Wrangler configuration defines one application-wide image, one instance_type, and settings such as max_instances. Omitting scheduling_policy selects default.

{
	"containers": [
		{
			"class_name": "ApiContainer",
			"scheduling_policy": "default",
			"image": "./api/Dockerfile",
			"instance_type": "standard-1",
			"max_instances": 5,
		},
	],
}

[[containers]]
class_name = "ApiContainer"
scheduling_policy = "default"
image = "./api/Dockerfile"
instance_type = "standard-1"
max_instances = 5

When you change the image or instance type and deploy, Cloudflare rolls out that change across the application. Refer to Rollouts.

The durable_object policy moves per-instance decisions into your Durable Object. Wrangler associates the Container application with the Durable Object class, and your code supplies a startup image or snapshot and an optional instance size to ctx.container.start().

Configure the policy. To use custom images, add the images that the Durable Object can start:

{
	"name": "agent-computer",
	"main": "src/index.ts",
	"compatibility_date": "2026-09-29",
	"containers": [
		{
			"class_name": "AgentComputer",
			"scheduling_policy": "durable_object",
			"images": {
				"base": {
					"dockerfile": "./container/Dockerfile",
				},
			},
		},
	],
	"durable_objects": {
		"bindings": [
			{
				"name": "AGENT_COMPUTER",
				"class_name": "AgentComputer",
			},
		],
	},
	"exports": {
		"AgentComputer": {
			"type": "durable-object",
			"storage": "sqlite",
		},
	},
}

name = "agent-computer"
main = "src/index.ts"
compatibility_date = "2026-09-29"

[[containers]]
class_name = "AgentComputer"
scheduling_policy = "durable_object"

[containers.images.base]
dockerfile = "./container/Dockerfile"

[[durable_objects.bindings]]
name = "AGENT_COMPUTER"
class_name = "AgentComputer"

[exports.AgentComputer]
type = "durable-object"
storage = "sqlite"

Wrangler builds or resolves each named image, prepares it for the Containers runtime, and exposes its digest-pinned reference on ctx.container.images. Select an image and instance size when the Durable Object starts its Container:

import { DurableObject } from "cloudflare:workers";

export class AgentComputer extends DurableObject {
	startContainer() {
		if (this.ctx.container.running) {
			return;
		}

		this.ctx.container.start({
			image: this.ctx.container.images.base,
			instance: "standard-2",
			enableInternet: false,
		});
	}
}

import { DurableObject } from "cloudflare:workers";

export class AgentComputer extends DurableObject {
	startContainer() {
		if (this.ctx.container.running) {
			return;
		}

		this.ctx.container.start({
			image: this.ctx.container.images.base,
			instance: "standard-2",
			enableInternet: false,
		});
	}
}

ctx.container.start() initiates startup and returns before the Container is ready to accept requests. Add an application-specific readiness check before sending traffic or calling exec().

The durable_object policy does not support max_instances. Running instances count toward your account limits.

If you do not need a custom image, start the cloudflare/debian-trixie Cloudflare-managed image directly without adding a named image to Wrangler. It includes Node.js 24.20.0 on Debian Trixie slim:

this.ctx.container.start({
	image: "cloudflare/debian-trixie",
	instance: "standard-2",
	enableInternet: false,
});

this.ctx.container.start({
	image: "cloudflare/debian-trixie",
	instance: "standard-2",
	enableInternet: false,
});

Each key under containers[].images in your Wrangler configuration becomes a property on ctx.container.images. For example, containers[].images.base is available to the Durable Object as ctx.container.images.base. Each value must specify exactly one image source. Use dockerfile for a path to a Dockerfile. When you run wrangler deploy, Wrangler builds and uploads that image. You can also set build_context and build_vars for that image.

Use image for a digest-pinned image in the Cloudflare managed registry. Use the form registry.cloudflare.com/<ACCOUNT_ID>/<REPOSITORY>@sha256:<DIGEST>. Direct references to Docker Hub, Amazon ECR, or Google Artifact Registry are not supported. To use an image from another registry, push it to the Cloudflare managed registry first.

A configuration can contain up to 100 named images. An image name must contain between 1 and 128 characters.

The image map is uploaded with the Worker version. Updating the map does not restart or replace running Container instances. Your application selects an image from the map when it starts an instance. During a gradual deployment, ctx.container.images reflects the image map of the Worker version that runs the Durable Object, so different Durable Objects can start different images until the deployment completes.

Set instance in ctx.container.start() to one of the following named instance types:

• lite
• standard-1
• standard-2
• standard-3
• standard-4

The runtime does not accept basic or the legacy dev and standard aliases.

If you omit instance, the Container uses lite. You can also supply a custom instance object that meets the custom instance type constraints:

this.ctx.container.start({
	image: this.ctx.container.images.base,
	enableInternet: false,
	instance: {
		vcpu: 1,
		memoryMib: 4096,
		diskMb: 8000,
	},
});

this.ctx.container.start({
	image: this.ctx.container.images.base,
	enableInternet: false,
	instance: {
		vcpu: 1,
		memoryMib: 4096,
		diskMb: 8000,
	},
});

The runtime uses camel case (memoryMib and diskMb). Wrangler's application-level instance_type object uses snake case (memory_mib and disk_mb) and only applies to the default policy.

For a new filesystem, pass image to ctx.container.start(). To restore a full filesystem snapshot, pass containerSnapshot instead. image and containerSnapshot are mutually exclusive because a snapshot already identifies the filesystem to restore.

Snapshots are only supported with the durable_object policy. A snapshot is tied to the image it was created from. After you update an image, create new snapshots from Containers running that image.

Refer to Snapshots for the complete save and restore flow.

Container instances that use the durable_object policy do not participate in application-wide image rollouts. A running instance continues to use its startup image. Your application decides when to stop that instance and start it with another configured image. For an example that compares the running image with the configured image, refer to Roll out a named image update.

The durable_object policy supports the ssh and authorized_keys fields. Refer to SSH.

• Durable Object Container API
• Lifecycle of a Container
• Image Management
• Wrangler Containers configuration