Applications
List Applications associated with your account
Create a new application
Get a single application by id
Modify an application
Delete a single application by id
ModelsExpand Collapse
ApplicationListResponse = object { id, account_id, configuration, 13 more } or object { id, account_id, created_at, 7 more } The public Containers API returns an application.
The public Containers API returns an application.
CcScheduledApplication object { id, account_id, configuration, 13 more } Describes an application and the parameters that govern how it places its instances.
Describes an application and the parameters that govern how it places its instances.
configuration: object { image, authorized_keys, command, 4 more } User-specified container configuration.
User-specified container configuration.
The command that runs when the container starts, passed to the entrypoint. You can override this at run-time. If you override only the command, it gets passed to the default entrypoint specified in the image.
The entry point for the container, specifying the executable to run when the container starts. You can override this at run-time. If you do, the default command from the image is ignored. Specify both entrypoint and command at run-time to completely replace the image defaults.
instance_type: optional "lite" or "basic" or "standard-1" or 3 moreThe instance type configures vCPU, memory, and disk.
- “lite”: 1/16 vCPU, 256 MiB memory, 2 GB disk
- “basic”: 1/4 vCPU, 1 GiB memory, 4 GB disk
- “standard-1”: 1/2 vCPU, 4 GiB memory, 8 GB disk
- “standard-2”: 1 vCPU, 6 GiB memory, 12 GB disk
- “standard-3”: 2 vCPU, 8 GiB memory, 16 GB disk
- “standard-4”: 4 vCPU, 12 GiB memory, 20 GB disk
The instance type configures vCPU, memory, and disk.
- “lite”: 1/16 vCPU, 256 MiB memory, 2 GB disk
- “basic”: 1/4 vCPU, 1 GiB memory, 4 GB disk
- “standard-1”: 1/2 vCPU, 4 GiB memory, 8 GB disk
- “standard-2”: 1 vCPU, 6 GiB memory, 12 GB disk
- “standard-3”: 2 vCPU, 8 GiB memory, 16 GB disk
- “standard-4”: 4 vCPU, 12 GiB memory, 20 GB disk
durable_objects: optional object { namespace_id } Durable object configuration stored on and returned from a Cloudchamber application.
Durable object configuration stored on and returned from a Cloudchamber application.
health: optional object { errors, instances, summary }
errors: array of object { event, instance_id }
event: object { id, details, message, 4 more } An event within a Placement or a Job.
An event within a Placement or a Job.
name: "SchedulerPlaced" or "NetworkingIPAssigned" or "VMStarted" or 14 moreName of the event that describes the kind event that happened.
- SchedulerPlaced: It’s the first event that creates a container placement. It happens when the Containers runtime was able to retrieve deployment resources and start verifying everything is correct.
- NetworkingIPAssigned: It’s sent when the Containers runtime maps the IP to the container.
- VMStarted: It’s sent when the Containers runtime starts the VM. The container might remain unhealthy at this point.
- ImagePulled: It’s sent when the Containers runtime pulls the image successfully.
- ImagePullError: It’s sent when the Containers runtime is having issues pulling the image. The message and details have more information on what happened for debugging.
- VMFailedToStart: It’s sent when the Containers runtime was unable to boot the VM.
- VMStopping: It’s sent when the scheduler is stopping the VM.
- VMStopped: It’s sent when the VM finally exits.
- VMFailed: It’s sent when the scheduling of the VM failed in the current location.
- RuntimeStartFailed: It’s sent when the runtime hits an internal error.
- SSHStarted: It’s sent when the container gains network connectivity and opens the SSH port. Containers only send this event when SSH keys exist.
- CheckUpdate: Sent when the status of a health or readiness check changes. This may also affect the health status of the placement.
- DurableObjectConnected: Sent when a durable object instance connects and gains control of the deployment.
This event is only sent for durable object deployments. It is sent after VMStarted.
- ContainerStarted: It’s sent when the container starts running.
Name of the event that describes the kind event that happened.
- SchedulerPlaced: It’s the first event that creates a container placement. It happens when the Containers runtime was able to retrieve deployment resources and start verifying everything is correct.
- NetworkingIPAssigned: It’s sent when the Containers runtime maps the IP to the container.
- VMStarted: It’s sent when the Containers runtime starts the VM. The container might remain unhealthy at this point.
- ImagePulled: It’s sent when the Containers runtime pulls the image successfully.
- ImagePullError: It’s sent when the Containers runtime is having issues pulling the image. The message and details have more information on what happened for debugging.
- VMFailedToStart: It’s sent when the Containers runtime was unable to boot the VM.
- VMStopping: It’s sent when the scheduler is stopping the VM.
- VMStopped: It’s sent when the VM finally exits.
- VMFailed: It’s sent when the scheduling of the VM failed in the current location.
- RuntimeStartFailed: It’s sent when the runtime hits an internal error.
- SSHStarted: It’s sent when the container gains network connectivity and opens the SSH port. Containers only send this event when SSH keys exist.
- CheckUpdate: Sent when the status of a health or readiness check changes. This may also affect the health status of the placement.
- DurableObjectConnected: Sent when a durable object instance connects and gains control of the deployment. This event is only sent for durable object deployments. It is sent after VMStarted.
- ContainerStarted: It’s sent when the container starts running.
instances: object { active, assigned } Shows a count of application instance states.
Shows a count of application instance states.
Number of instances whose runtime reports the container as running (container_status = “running”). This is a subset of the placements that remain up: an instance that is already bound to a Durable Object and serving traffic is counted under “assigned” until its container_status catches up to “running”, so container_status can briefly lag Durable Object attachment under churn. To estimate running, Durable-Object-bound instances, sum “active” + “assigned” rather than reading “active” alone.
summary: optional "healthy" or "degraded" or "unhealthy" or "pending"High-level health assessment. Only populated for “new_instances” strategy.
Based on a sample of target-version instances rather than a full count.
- “pending”: Zero target-version instances exist yet.
- “healthy”: Every sampled target-version instance reports running or active.
- “degraded”: Some sampled instances remain starting or scheduling.
- “unhealthy”: One or more sampled instances have failed.
High-level health assessment. Only populated for “new_instances” strategy. Based on a sample of target-version instances rather than a full count.
- “pending”: Zero target-version instances exist yet.
- “healthy”: Every sampled target-version instance reports running or active.
- “degraded”: Some sampled instances remain starting or scheduling.
- “unhealthy”: One or more sampled instances have failed.
Maximum number of instances the application allows. This is relevant for applications that auto-scale.
CcDurableObjectApplication object { id, account_id, created_at, 7 more } Each Durable Object creates and manages the lifecycle of its container instance.
Each Durable Object creates and manages the lifecycle of its container instance.
Selects a Durable Object-managed application. Each Durable Object creates and manages the lifecycle of its container instance. Configure application-wide observability settings here. Deployment configuration, scaling, placement constraints, versions, and rollouts do not apply.
configuration: optional object { authorized_keys, wrangler_ssh } Application-wide settings for a Durable Object-managed application.
Application-wide settings for a Durable Object-managed application.
health: optional object { instances, summary } Aggregate current activity for the latest observed placement of each instance.
Runtime snapshots feed periodic background sweeps. Counts refresh after each
complete sweep. Instance listings retain their separate three-month history
for failure discovery.
Aggregate current activity for the latest observed placement of each instance. Runtime snapshots feed periodic background sweeps. Counts refresh after each complete sweep. Instance listings retain their separate three-month history for failure discovery.
ApplicationCreateResponse = object { id, account_id, configuration, 13 more } or object { id, account_id, created_at, 7 more } The public Containers API returns an application.
The public Containers API returns an application.
CcScheduledApplication object { id, account_id, configuration, 13 more } Describes an application and the parameters that govern how it places its instances.
Describes an application and the parameters that govern how it places its instances.
configuration: object { image, authorized_keys, command, 4 more } User-specified container configuration.
User-specified container configuration.
The command that runs when the container starts, passed to the entrypoint. You can override this at run-time. If you override only the command, it gets passed to the default entrypoint specified in the image.
The entry point for the container, specifying the executable to run when the container starts. You can override this at run-time. If you do, the default command from the image is ignored. Specify both entrypoint and command at run-time to completely replace the image defaults.
instance_type: optional "lite" or "basic" or "standard-1" or 3 moreThe instance type configures vCPU, memory, and disk.
- “lite”: 1/16 vCPU, 256 MiB memory, 2 GB disk
- “basic”: 1/4 vCPU, 1 GiB memory, 4 GB disk
- “standard-1”: 1/2 vCPU, 4 GiB memory, 8 GB disk
- “standard-2”: 1 vCPU, 6 GiB memory, 12 GB disk
- “standard-3”: 2 vCPU, 8 GiB memory, 16 GB disk
- “standard-4”: 4 vCPU, 12 GiB memory, 20 GB disk
The instance type configures vCPU, memory, and disk.
- “lite”: 1/16 vCPU, 256 MiB memory, 2 GB disk
- “basic”: 1/4 vCPU, 1 GiB memory, 4 GB disk
- “standard-1”: 1/2 vCPU, 4 GiB memory, 8 GB disk
- “standard-2”: 1 vCPU, 6 GiB memory, 12 GB disk
- “standard-3”: 2 vCPU, 8 GiB memory, 16 GB disk
- “standard-4”: 4 vCPU, 12 GiB memory, 20 GB disk
durable_objects: optional object { namespace_id } Durable object configuration stored on and returned from a Cloudchamber application.
Durable object configuration stored on and returned from a Cloudchamber application.
health: optional object { errors, instances, summary }
errors: array of object { event, instance_id }
event: object { id, details, message, 4 more } An event within a Placement or a Job.
An event within a Placement or a Job.
name: "SchedulerPlaced" or "NetworkingIPAssigned" or "VMStarted" or 14 moreName of the event that describes the kind event that happened.
- SchedulerPlaced: It’s the first event that creates a container placement. It happens when the Containers runtime was able to retrieve deployment resources and start verifying everything is correct.
- NetworkingIPAssigned: It’s sent when the Containers runtime maps the IP to the container.
- VMStarted: It’s sent when the Containers runtime starts the VM. The container might remain unhealthy at this point.
- ImagePulled: It’s sent when the Containers runtime pulls the image successfully.
- ImagePullError: It’s sent when the Containers runtime is having issues pulling the image. The message and details have more information on what happened for debugging.
- VMFailedToStart: It’s sent when the Containers runtime was unable to boot the VM.
- VMStopping: It’s sent when the scheduler is stopping the VM.
- VMStopped: It’s sent when the VM finally exits.
- VMFailed: It’s sent when the scheduling of the VM failed in the current location.
- RuntimeStartFailed: It’s sent when the runtime hits an internal error.
- SSHStarted: It’s sent when the container gains network connectivity and opens the SSH port. Containers only send this event when SSH keys exist.
- CheckUpdate: Sent when the status of a health or readiness check changes. This may also affect the health status of the placement.
- DurableObjectConnected: Sent when a durable object instance connects and gains control of the deployment.
This event is only sent for durable object deployments. It is sent after VMStarted.
- ContainerStarted: It’s sent when the container starts running.
Name of the event that describes the kind event that happened.
- SchedulerPlaced: It’s the first event that creates a container placement. It happens when the Containers runtime was able to retrieve deployment resources and start verifying everything is correct.
- NetworkingIPAssigned: It’s sent when the Containers runtime maps the IP to the container.
- VMStarted: It’s sent when the Containers runtime starts the VM. The container might remain unhealthy at this point.
- ImagePulled: It’s sent when the Containers runtime pulls the image successfully.
- ImagePullError: It’s sent when the Containers runtime is having issues pulling the image. The message and details have more information on what happened for debugging.
- VMFailedToStart: It’s sent when the Containers runtime was unable to boot the VM.
- VMStopping: It’s sent when the scheduler is stopping the VM.
- VMStopped: It’s sent when the VM finally exits.
- VMFailed: It’s sent when the scheduling of the VM failed in the current location.
- RuntimeStartFailed: It’s sent when the runtime hits an internal error.
- SSHStarted: It’s sent when the container gains network connectivity and opens the SSH port. Containers only send this event when SSH keys exist.
- CheckUpdate: Sent when the status of a health or readiness check changes. This may also affect the health status of the placement.
- DurableObjectConnected: Sent when a durable object instance connects and gains control of the deployment. This event is only sent for durable object deployments. It is sent after VMStarted.
- ContainerStarted: It’s sent when the container starts running.
instances: object { active, assigned } Shows a count of application instance states.
Shows a count of application instance states.
Number of instances whose runtime reports the container as running (container_status = “running”). This is a subset of the placements that remain up: an instance that is already bound to a Durable Object and serving traffic is counted under “assigned” until its container_status catches up to “running”, so container_status can briefly lag Durable Object attachment under churn. To estimate running, Durable-Object-bound instances, sum “active” + “assigned” rather than reading “active” alone.
summary: optional "healthy" or "degraded" or "unhealthy" or "pending"High-level health assessment. Only populated for “new_instances” strategy.
Based on a sample of target-version instances rather than a full count.
- “pending”: Zero target-version instances exist yet.
- “healthy”: Every sampled target-version instance reports running or active.
- “degraded”: Some sampled instances remain starting or scheduling.
- “unhealthy”: One or more sampled instances have failed.
High-level health assessment. Only populated for “new_instances” strategy. Based on a sample of target-version instances rather than a full count.
- “pending”: Zero target-version instances exist yet.
- “healthy”: Every sampled target-version instance reports running or active.
- “degraded”: Some sampled instances remain starting or scheduling.
- “unhealthy”: One or more sampled instances have failed.
Maximum number of instances the application allows. This is relevant for applications that auto-scale.
CcDurableObjectApplication object { id, account_id, created_at, 7 more } Each Durable Object creates and manages the lifecycle of its container instance.
Each Durable Object creates and manages the lifecycle of its container instance.
Selects a Durable Object-managed application. Each Durable Object creates and manages the lifecycle of its container instance. Configure application-wide observability settings here. Deployment configuration, scaling, placement constraints, versions, and rollouts do not apply.
configuration: optional object { authorized_keys, wrangler_ssh } Application-wide settings for a Durable Object-managed application.
Application-wide settings for a Durable Object-managed application.
health: optional object { instances, summary } Aggregate current activity for the latest observed placement of each instance.
Runtime snapshots feed periodic background sweeps. Counts refresh after each
complete sweep. Instance listings retain their separate three-month history
for failure discovery.
Aggregate current activity for the latest observed placement of each instance. Runtime snapshots feed periodic background sweeps. Counts refresh after each complete sweep. Instance listings retain their separate three-month history for failure discovery.
ApplicationGetResponse = object { id, account_id, configuration, 13 more } or object { id, account_id, created_at, 7 more } The public Containers API returns an application.
The public Containers API returns an application.
CcScheduledApplication object { id, account_id, configuration, 13 more } Describes an application and the parameters that govern how it places its instances.
Describes an application and the parameters that govern how it places its instances.
configuration: object { image, authorized_keys, command, 4 more } User-specified container configuration.
User-specified container configuration.
The command that runs when the container starts, passed to the entrypoint. You can override this at run-time. If you override only the command, it gets passed to the default entrypoint specified in the image.
The entry point for the container, specifying the executable to run when the container starts. You can override this at run-time. If you do, the default command from the image is ignored. Specify both entrypoint and command at run-time to completely replace the image defaults.
instance_type: optional "lite" or "basic" or "standard-1" or 3 moreThe instance type configures vCPU, memory, and disk.
- “lite”: 1/16 vCPU, 256 MiB memory, 2 GB disk
- “basic”: 1/4 vCPU, 1 GiB memory, 4 GB disk
- “standard-1”: 1/2 vCPU, 4 GiB memory, 8 GB disk
- “standard-2”: 1 vCPU, 6 GiB memory, 12 GB disk
- “standard-3”: 2 vCPU, 8 GiB memory, 16 GB disk
- “standard-4”: 4 vCPU, 12 GiB memory, 20 GB disk
The instance type configures vCPU, memory, and disk.
- “lite”: 1/16 vCPU, 256 MiB memory, 2 GB disk
- “basic”: 1/4 vCPU, 1 GiB memory, 4 GB disk
- “standard-1”: 1/2 vCPU, 4 GiB memory, 8 GB disk
- “standard-2”: 1 vCPU, 6 GiB memory, 12 GB disk
- “standard-3”: 2 vCPU, 8 GiB memory, 16 GB disk
- “standard-4”: 4 vCPU, 12 GiB memory, 20 GB disk
durable_objects: optional object { namespace_id } Durable object configuration stored on and returned from a Cloudchamber application.
Durable object configuration stored on and returned from a Cloudchamber application.
health: optional object { errors, instances, summary }
errors: array of object { event, instance_id }
event: object { id, details, message, 4 more } An event within a Placement or a Job.
An event within a Placement or a Job.
name: "SchedulerPlaced" or "NetworkingIPAssigned" or "VMStarted" or 14 moreName of the event that describes the kind event that happened.
- SchedulerPlaced: It’s the first event that creates a container placement. It happens when the Containers runtime was able to retrieve deployment resources and start verifying everything is correct.
- NetworkingIPAssigned: It’s sent when the Containers runtime maps the IP to the container.
- VMStarted: It’s sent when the Containers runtime starts the VM. The container might remain unhealthy at this point.
- ImagePulled: It’s sent when the Containers runtime pulls the image successfully.
- ImagePullError: It’s sent when the Containers runtime is having issues pulling the image. The message and details have more information on what happened for debugging.
- VMFailedToStart: It’s sent when the Containers runtime was unable to boot the VM.
- VMStopping: It’s sent when the scheduler is stopping the VM.
- VMStopped: It’s sent when the VM finally exits.
- VMFailed: It’s sent when the scheduling of the VM failed in the current location.
- RuntimeStartFailed: It’s sent when the runtime hits an internal error.
- SSHStarted: It’s sent when the container gains network connectivity and opens the SSH port. Containers only send this event when SSH keys exist.
- CheckUpdate: Sent when the status of a health or readiness check changes. This may also affect the health status of the placement.
- DurableObjectConnected: Sent when a durable object instance connects and gains control of the deployment.
This event is only sent for durable object deployments. It is sent after VMStarted.
- ContainerStarted: It’s sent when the container starts running.
Name of the event that describes the kind event that happened.
- SchedulerPlaced: It’s the first event that creates a container placement. It happens when the Containers runtime was able to retrieve deployment resources and start verifying everything is correct.
- NetworkingIPAssigned: It’s sent when the Containers runtime maps the IP to the container.
- VMStarted: It’s sent when the Containers runtime starts the VM. The container might remain unhealthy at this point.
- ImagePulled: It’s sent when the Containers runtime pulls the image successfully.
- ImagePullError: It’s sent when the Containers runtime is having issues pulling the image. The message and details have more information on what happened for debugging.
- VMFailedToStart: It’s sent when the Containers runtime was unable to boot the VM.
- VMStopping: It’s sent when the scheduler is stopping the VM.
- VMStopped: It’s sent when the VM finally exits.
- VMFailed: It’s sent when the scheduling of the VM failed in the current location.
- RuntimeStartFailed: It’s sent when the runtime hits an internal error.
- SSHStarted: It’s sent when the container gains network connectivity and opens the SSH port. Containers only send this event when SSH keys exist.
- CheckUpdate: Sent when the status of a health or readiness check changes. This may also affect the health status of the placement.
- DurableObjectConnected: Sent when a durable object instance connects and gains control of the deployment. This event is only sent for durable object deployments. It is sent after VMStarted.
- ContainerStarted: It’s sent when the container starts running.
instances: object { active, assigned } Shows a count of application instance states.
Shows a count of application instance states.
Number of instances whose runtime reports the container as running (container_status = “running”). This is a subset of the placements that remain up: an instance that is already bound to a Durable Object and serving traffic is counted under “assigned” until its container_status catches up to “running”, so container_status can briefly lag Durable Object attachment under churn. To estimate running, Durable-Object-bound instances, sum “active” + “assigned” rather than reading “active” alone.
summary: optional "healthy" or "degraded" or "unhealthy" or "pending"High-level health assessment. Only populated for “new_instances” strategy.
Based on a sample of target-version instances rather than a full count.
- “pending”: Zero target-version instances exist yet.
- “healthy”: Every sampled target-version instance reports running or active.
- “degraded”: Some sampled instances remain starting or scheduling.
- “unhealthy”: One or more sampled instances have failed.
High-level health assessment. Only populated for “new_instances” strategy. Based on a sample of target-version instances rather than a full count.
- “pending”: Zero target-version instances exist yet.
- “healthy”: Every sampled target-version instance reports running or active.
- “degraded”: Some sampled instances remain starting or scheduling.
- “unhealthy”: One or more sampled instances have failed.
Maximum number of instances the application allows. This is relevant for applications that auto-scale.
CcDurableObjectApplication object { id, account_id, created_at, 7 more } Each Durable Object creates and manages the lifecycle of its container instance.
Each Durable Object creates and manages the lifecycle of its container instance.
Selects a Durable Object-managed application. Each Durable Object creates and manages the lifecycle of its container instance. Configure application-wide observability settings here. Deployment configuration, scaling, placement constraints, versions, and rollouts do not apply.
configuration: optional object { authorized_keys, wrangler_ssh } Application-wide settings for a Durable Object-managed application.
Application-wide settings for a Durable Object-managed application.
health: optional object { instances, summary } Aggregate current activity for the latest observed placement of each instance.
Runtime snapshots feed periodic background sweeps. Counts refresh after each
complete sweep. Instance listings retain their separate three-month history
for failure discovery.
Aggregate current activity for the latest observed placement of each instance. Runtime snapshots feed periodic background sweeps. Counts refresh after each complete sweep. Instance listings retain their separate three-month history for failure discovery.
ApplicationEditResponse = object { id, account_id, configuration, 13 more } or object { id, account_id, created_at, 7 more } The public Containers API returns an application.
The public Containers API returns an application.
CcScheduledApplication object { id, account_id, configuration, 13 more } Describes an application and the parameters that govern how it places its instances.
Describes an application and the parameters that govern how it places its instances.
configuration: object { image, authorized_keys, command, 4 more } User-specified container configuration.
User-specified container configuration.
The command that runs when the container starts, passed to the entrypoint. You can override this at run-time. If you override only the command, it gets passed to the default entrypoint specified in the image.
The entry point for the container, specifying the executable to run when the container starts. You can override this at run-time. If you do, the default command from the image is ignored. Specify both entrypoint and command at run-time to completely replace the image defaults.
instance_type: optional "lite" or "basic" or "standard-1" or 3 moreThe instance type configures vCPU, memory, and disk.
- “lite”: 1/16 vCPU, 256 MiB memory, 2 GB disk
- “basic”: 1/4 vCPU, 1 GiB memory, 4 GB disk
- “standard-1”: 1/2 vCPU, 4 GiB memory, 8 GB disk
- “standard-2”: 1 vCPU, 6 GiB memory, 12 GB disk
- “standard-3”: 2 vCPU, 8 GiB memory, 16 GB disk
- “standard-4”: 4 vCPU, 12 GiB memory, 20 GB disk
The instance type configures vCPU, memory, and disk.
- “lite”: 1/16 vCPU, 256 MiB memory, 2 GB disk
- “basic”: 1/4 vCPU, 1 GiB memory, 4 GB disk
- “standard-1”: 1/2 vCPU, 4 GiB memory, 8 GB disk
- “standard-2”: 1 vCPU, 6 GiB memory, 12 GB disk
- “standard-3”: 2 vCPU, 8 GiB memory, 16 GB disk
- “standard-4”: 4 vCPU, 12 GiB memory, 20 GB disk
durable_objects: optional object { namespace_id } Durable object configuration stored on and returned from a Cloudchamber application.
Durable object configuration stored on and returned from a Cloudchamber application.
health: optional object { errors, instances, summary }
errors: array of object { event, instance_id }
event: object { id, details, message, 4 more } An event within a Placement or a Job.
An event within a Placement or a Job.
name: "SchedulerPlaced" or "NetworkingIPAssigned" or "VMStarted" or 14 moreName of the event that describes the kind event that happened.
- SchedulerPlaced: It’s the first event that creates a container placement. It happens when the Containers runtime was able to retrieve deployment resources and start verifying everything is correct.
- NetworkingIPAssigned: It’s sent when the Containers runtime maps the IP to the container.
- VMStarted: It’s sent when the Containers runtime starts the VM. The container might remain unhealthy at this point.
- ImagePulled: It’s sent when the Containers runtime pulls the image successfully.
- ImagePullError: It’s sent when the Containers runtime is having issues pulling the image. The message and details have more information on what happened for debugging.
- VMFailedToStart: It’s sent when the Containers runtime was unable to boot the VM.
- VMStopping: It’s sent when the scheduler is stopping the VM.
- VMStopped: It’s sent when the VM finally exits.
- VMFailed: It’s sent when the scheduling of the VM failed in the current location.
- RuntimeStartFailed: It’s sent when the runtime hits an internal error.
- SSHStarted: It’s sent when the container gains network connectivity and opens the SSH port. Containers only send this event when SSH keys exist.
- CheckUpdate: Sent when the status of a health or readiness check changes. This may also affect the health status of the placement.
- DurableObjectConnected: Sent when a durable object instance connects and gains control of the deployment.
This event is only sent for durable object deployments. It is sent after VMStarted.
- ContainerStarted: It’s sent when the container starts running.
Name of the event that describes the kind event that happened.
- SchedulerPlaced: It’s the first event that creates a container placement. It happens when the Containers runtime was able to retrieve deployment resources and start verifying everything is correct.
- NetworkingIPAssigned: It’s sent when the Containers runtime maps the IP to the container.
- VMStarted: It’s sent when the Containers runtime starts the VM. The container might remain unhealthy at this point.
- ImagePulled: It’s sent when the Containers runtime pulls the image successfully.
- ImagePullError: It’s sent when the Containers runtime is having issues pulling the image. The message and details have more information on what happened for debugging.
- VMFailedToStart: It’s sent when the Containers runtime was unable to boot the VM.
- VMStopping: It’s sent when the scheduler is stopping the VM.
- VMStopped: It’s sent when the VM finally exits.
- VMFailed: It’s sent when the scheduling of the VM failed in the current location.
- RuntimeStartFailed: It’s sent when the runtime hits an internal error.
- SSHStarted: It’s sent when the container gains network connectivity and opens the SSH port. Containers only send this event when SSH keys exist.
- CheckUpdate: Sent when the status of a health or readiness check changes. This may also affect the health status of the placement.
- DurableObjectConnected: Sent when a durable object instance connects and gains control of the deployment. This event is only sent for durable object deployments. It is sent after VMStarted.
- ContainerStarted: It’s sent when the container starts running.
instances: object { active, assigned } Shows a count of application instance states.
Shows a count of application instance states.
Number of instances whose runtime reports the container as running (container_status = “running”). This is a subset of the placements that remain up: an instance that is already bound to a Durable Object and serving traffic is counted under “assigned” until its container_status catches up to “running”, so container_status can briefly lag Durable Object attachment under churn. To estimate running, Durable-Object-bound instances, sum “active” + “assigned” rather than reading “active” alone.
summary: optional "healthy" or "degraded" or "unhealthy" or "pending"High-level health assessment. Only populated for “new_instances” strategy.
Based on a sample of target-version instances rather than a full count.
- “pending”: Zero target-version instances exist yet.
- “healthy”: Every sampled target-version instance reports running or active.
- “degraded”: Some sampled instances remain starting or scheduling.
- “unhealthy”: One or more sampled instances have failed.
High-level health assessment. Only populated for “new_instances” strategy. Based on a sample of target-version instances rather than a full count.
- “pending”: Zero target-version instances exist yet.
- “healthy”: Every sampled target-version instance reports running or active.
- “degraded”: Some sampled instances remain starting or scheduling.
- “unhealthy”: One or more sampled instances have failed.
Maximum number of instances the application allows. This is relevant for applications that auto-scale.
CcDurableObjectApplication object { id, account_id, created_at, 7 more } Each Durable Object creates and manages the lifecycle of its container instance.
Each Durable Object creates and manages the lifecycle of its container instance.
Selects a Durable Object-managed application. Each Durable Object creates and manages the lifecycle of its container instance. Configure application-wide observability settings here. Deployment configuration, scaling, placement constraints, versions, and rollouts do not apply.
configuration: optional object { authorized_keys, wrangler_ssh } Application-wide settings for a Durable Object-managed application.
Application-wide settings for a Durable Object-managed application.
health: optional object { instances, summary } Aggregate current activity for the latest observed placement of each instance.
Runtime snapshots feed periodic background sweeps. Counts refresh after each
complete sweep. Instance listings retain their separate three-month history
for failure discovery.
Aggregate current activity for the latest observed placement of each instance. Runtime snapshots feed periodic background sweeps. Counts refresh after each complete sweep. Instance listings retain their separate three-month history for failure discovery.
ApplicationsInstances
List container instances (deprecated)
List container instances
Get a container instance
ModelsExpand Collapse
InstanceListV1Response object { id, application_id, image, 5 more } The last-reported state of a logical container instance.
The last-reported state of a logical container instance.
status: object { state, updated_at, exit_code } The latest known status of a container instance.
The latest known status of a container instance.
configuration: optional object { disk, memory, vcpu } The resources allocated to the container instance.
The resources allocated to the container instance.
location: optional object { name, region } The location of the instance’s current container placement.
The location of the instance’s current container placement.
InstanceListResponse object { id, application_id, image, 5 more } The last-reported state of a logical container instance.
The last-reported state of a logical container instance.
status: object { state, updated_at, exit_code } The latest known status of a container instance.
The latest known status of a container instance.
configuration: optional object { disk, memory, vcpu } The resources allocated to the container instance.
The resources allocated to the container instance.
location: optional object { name, region } The location of the instance’s current container placement.
The location of the instance’s current container placement.
InstanceGetResponse object { id, application_id, image, 5 more } The last-reported state of a logical container instance.
The last-reported state of a logical container instance.
status: object { state, updated_at, exit_code } The latest known status of a container instance.
The latest known status of a container instance.
configuration: optional object { disk, memory, vcpu } The resources allocated to the container instance.
The resources allocated to the container instance.
location: optional object { name, region } The location of the instance’s current container placement.
The location of the instance’s current container placement.
ApplicationsRollouts
Create a new rollout for an application
ModelsExpand Collapse
RolloutCreateResponse object { id, created_at, current_configuration, 14 more } Represents the status and metadata of a rollout process for an application.
For “rolling” strategy: includes steps and progress with instance counts.
For “new_instances” strategy: the response omits steps and progress. Use percentage,
version_distribution, and health.summary for status.
Represents the status and metadata of a rollout process for an application. For “rolling” strategy: includes steps and progress with instance counts. For “new_instances” strategy: the response omits steps and progress. Use percentage, version_distribution, and health.summary for status.
current_configuration: object { authorized_keys, command, entrypoint, 4 more } User-specified container configuration changes.
User-specified container configuration changes.
The command that runs when the container starts, passed to the entrypoint. You can override this at run-time. If you override only the command, it gets passed to the default entrypoint specified in the image.
The entry point for the container, specifying the executable to run when the container starts. You can override this at run-time. If you do, the default command from the image is ignored. Specify both entrypoint and command at run-time to completely replace the image defaults.
instance_type: optional "lite" or "basic" or "standard-1" or 3 moreThe instance type configures vCPU, memory, and disk.
- “lite”: 1/16 vCPU, 256 MiB memory, 2 GB disk
- “basic”: 1/4 vCPU, 1 GiB memory, 4 GB disk
- “standard-1”: 1/2 vCPU, 4 GiB memory, 8 GB disk
- “standard-2”: 1 vCPU, 6 GiB memory, 12 GB disk
- “standard-3”: 2 vCPU, 8 GiB memory, 16 GB disk
- “standard-4”: 4 vCPU, 12 GiB memory, 20 GB disk
The instance type configures vCPU, memory, and disk.
- “lite”: 1/16 vCPU, 256 MiB memory, 2 GB disk
- “basic”: 1/4 vCPU, 1 GiB memory, 4 GB disk
- “standard-1”: 1/2 vCPU, 4 GiB memory, 8 GB disk
- “standard-2”: 1 vCPU, 6 GiB memory, 12 GB disk
- “standard-3”: 2 vCPU, 8 GiB memory, 16 GB disk
- “standard-4”: 4 vCPU, 12 GiB memory, 20 GB disk
health: object { errors, instances, summary }
errors: array of object { event, instance_id }
event: object { id, details, message, 4 more } An event within a Placement or a Job.
An event within a Placement or a Job.
name: "SchedulerPlaced" or "NetworkingIPAssigned" or "VMStarted" or 14 moreName of the event that describes the kind event that happened.
- SchedulerPlaced: It’s the first event that creates a container placement. It happens when the Containers runtime was able to retrieve deployment resources and start verifying everything is correct.
- NetworkingIPAssigned: It’s sent when the Containers runtime maps the IP to the container.
- VMStarted: It’s sent when the Containers runtime starts the VM. The container might remain unhealthy at this point.
- ImagePulled: It’s sent when the Containers runtime pulls the image successfully.
- ImagePullError: It’s sent when the Containers runtime is having issues pulling the image. The message and details have more information on what happened for debugging.
- VMFailedToStart: It’s sent when the Containers runtime was unable to boot the VM.
- VMStopping: It’s sent when the scheduler is stopping the VM.
- VMStopped: It’s sent when the VM finally exits.
- VMFailed: It’s sent when the scheduling of the VM failed in the current location.
- RuntimeStartFailed: It’s sent when the runtime hits an internal error.
- SSHStarted: It’s sent when the container gains network connectivity and opens the SSH port. Containers only send this event when SSH keys exist.
- CheckUpdate: Sent when the status of a health or readiness check changes. This may also affect the health status of the placement.
- DurableObjectConnected: Sent when a durable object instance connects and gains control of the deployment.
This event is only sent for durable object deployments. It is sent after VMStarted.
- ContainerStarted: It’s sent when the container starts running.
Name of the event that describes the kind event that happened.
- SchedulerPlaced: It’s the first event that creates a container placement. It happens when the Containers runtime was able to retrieve deployment resources and start verifying everything is correct.
- NetworkingIPAssigned: It’s sent when the Containers runtime maps the IP to the container.
- VMStarted: It’s sent when the Containers runtime starts the VM. The container might remain unhealthy at this point.
- ImagePulled: It’s sent when the Containers runtime pulls the image successfully.
- ImagePullError: It’s sent when the Containers runtime is having issues pulling the image. The message and details have more information on what happened for debugging.
- VMFailedToStart: It’s sent when the Containers runtime was unable to boot the VM.
- VMStopping: It’s sent when the scheduler is stopping the VM.
- VMStopped: It’s sent when the VM finally exits.
- VMFailed: It’s sent when the scheduling of the VM failed in the current location.
- RuntimeStartFailed: It’s sent when the runtime hits an internal error.
- SSHStarted: It’s sent when the container gains network connectivity and opens the SSH port. Containers only send this event when SSH keys exist.
- CheckUpdate: Sent when the status of a health or readiness check changes. This may also affect the health status of the placement.
- DurableObjectConnected: Sent when a durable object instance connects and gains control of the deployment. This event is only sent for durable object deployments. It is sent after VMStarted.
- ContainerStarted: It’s sent when the container starts running.
instances: object { active, assigned } Shows a count of application instance states.
Shows a count of application instance states.
Number of instances whose runtime reports the container as running (container_status = “running”). This is a subset of the placements that remain up: an instance that is already bound to a Durable Object and serving traffic is counted under “assigned” until its container_status catches up to “running”, so container_status can briefly lag Durable Object attachment under churn. To estimate running, Durable-Object-bound instances, sum “active” + “assigned” rather than reading “active” alone.
summary: optional "healthy" or "degraded" or "unhealthy" or "pending"High-level health assessment. Only populated for “new_instances” strategy.
Based on a sample of target-version instances rather than a full count.
- “pending”: Zero target-version instances exist yet.
- “healthy”: Every sampled target-version instance reports running or active.
- “degraded”: Some sampled instances remain starting or scheduling.
- “unhealthy”: One or more sampled instances have failed.
High-level health assessment. Only populated for “new_instances” strategy. Based on a sample of target-version instances rather than a full count.
- “pending”: Zero target-version instances exist yet.
- “healthy”: Every sampled target-version instance reports running or active.
- “degraded”: Some sampled instances remain starting or scheduling.
- “unhealthy”: One or more sampled instances have failed.
kind: "full_auto" or "full_manual" or "durable_objects_auto"Kind of the rollout process.
- “full_auto”: For rolling rollouts, starts progressing steps upon rollout creation. For new_instances rollouts, advances percentage targets automatically after target-version health is observed.
- “full_manual”: Requires manually progressing each step in the rollout using the UpdateRollout’s action paramater.
- “durable_objects_auto”: Default when the application is a DO application.
Kind of the rollout process.
- “full_auto”: For rolling rollouts, starts progressing steps upon rollout creation. For new_instances rollouts, advances percentage targets automatically after target-version health is observed.
- “full_manual”: Requires manually progressing each step in the rollout using the UpdateRollout’s action paramater.
- “durable_objects_auto”: Default when the application is a DO application.
strategy: "rolling" or "new_instances"The rollout strategy.
- “rolling”: Step-based rollout with health gates. Actively replaces instances to reach each step’s target percentage. Response includes steps and progress.
- “new_instances”: Percentage control over version distribution. Version sync actively replaces instances to match the configured percentage. “full_auto” ramps through fixed percentage targets after target-version health is observed. Response includes percentage, version_distribution, and health.summary.
The rollout strategy.
- “rolling”: Step-based rollout with health gates. Actively replaces instances to reach each step’s target percentage. Response includes steps and progress.
- “new_instances”: Percentage control over version distribution. Version sync actively replaces instances to match the configured percentage. “full_auto” ramps through fixed percentage targets after target-version health is observed. Response includes percentage, version_distribution, and health.summary.
target_configuration: object { authorized_keys, command, entrypoint, 4 more } User-specified container configuration changes.
User-specified container configuration changes.
The command that runs when the container starts, passed to the entrypoint. You can override this at run-time. If you override only the command, it gets passed to the default entrypoint specified in the image.
The entry point for the container, specifying the executable to run when the container starts. You can override this at run-time. If you do, the default command from the image is ignored. Specify both entrypoint and command at run-time to completely replace the image defaults.
instance_type: optional "lite" or "basic" or "standard-1" or 3 moreThe instance type configures vCPU, memory, and disk.
- “lite”: 1/16 vCPU, 256 MiB memory, 2 GB disk
- “basic”: 1/4 vCPU, 1 GiB memory, 4 GB disk
- “standard-1”: 1/2 vCPU, 4 GiB memory, 8 GB disk
- “standard-2”: 1 vCPU, 6 GiB memory, 12 GB disk
- “standard-3”: 2 vCPU, 8 GiB memory, 16 GB disk
- “standard-4”: 4 vCPU, 12 GiB memory, 20 GB disk
The instance type configures vCPU, memory, and disk.
- “lite”: 1/16 vCPU, 256 MiB memory, 2 GB disk
- “basic”: 1/4 vCPU, 1 GiB memory, 4 GB disk
- “standard-1”: 1/2 vCPU, 4 GiB memory, 8 GB disk
- “standard-2”: 1 vCPU, 6 GiB memory, 12 GB disk
- “standard-3”: 2 vCPU, 8 GiB memory, 16 GB disk
- “standard-4”: 4 vCPU, 12 GiB memory, 20 GB disk
Target application version after the rollout is complete and applied to all current instances.
Current target version percentage (0-100). Only present for “new_instances” strategy.
progress: optional object { current_step, total_instances, total_steps, 2 more } Progress details of an application rollout.
Progress details of an application rollout.
version_distribution: optional object { current_version_instances, current_version_percentage, target_version_instances, target_version_percentage } Expected distribution of instances per version, based on the current percentage split.
Populated during active rollouts. Values derive from the version percentage weights
rather than actual running instance counts.
Expected distribution of instances per version, based on the current percentage split. Populated during active rollouts. Values derive from the version percentage weights rather than actual running instance counts.
Expected number of instances remaining on the current (old) version based on the current percentage split. Only populated for “rolling” strategy.
The percentage of new instances being scheduled on the current version (100 - target_version_percentage). Only populated for “new_instances” strategy.
steps: optional array of object { id, description, status, 4 more }
ApplicationsVersions
List all application versions
ModelsExpand Collapse
VersionListResponse object { configuration, percentage, version } An application with the configuration of its version.
An application with the configuration of its version.
configuration: object { authorized_keys, command, entrypoint, 4 more } User-specified container configuration changes.
User-specified container configuration changes.
The command that runs when the container starts, passed to the entrypoint. You can override this at run-time. If you override only the command, it gets passed to the default entrypoint specified in the image.
The entry point for the container, specifying the executable to run when the container starts. You can override this at run-time. If you do, the default command from the image is ignored. Specify both entrypoint and command at run-time to completely replace the image defaults.
instance_type: optional "lite" or "basic" or "standard-1" or 3 moreThe instance type configures vCPU, memory, and disk.
- “lite”: 1/16 vCPU, 256 MiB memory, 2 GB disk
- “basic”: 1/4 vCPU, 1 GiB memory, 4 GB disk
- “standard-1”: 1/2 vCPU, 4 GiB memory, 8 GB disk
- “standard-2”: 1 vCPU, 6 GiB memory, 12 GB disk
- “standard-3”: 2 vCPU, 8 GiB memory, 16 GB disk
- “standard-4”: 4 vCPU, 12 GiB memory, 20 GB disk
The instance type configures vCPU, memory, and disk.
- “lite”: 1/16 vCPU, 256 MiB memory, 2 GB disk
- “basic”: 1/4 vCPU, 1 GiB memory, 4 GB disk
- “standard-1”: 1/2 vCPU, 4 GiB memory, 8 GB disk
- “standard-2”: 1 vCPU, 6 GiB memory, 12 GB disk
- “standard-3”: 2 vCPU, 8 GiB memory, 16 GB disk
- “standard-4”: 4 vCPU, 12 GiB memory, 20 GB disk