Setup: One Worker fronting a container app via @cloudflare/containers (^0.3.7): class extends Container, a single DO addressed with getByName, sleepAfter: "15m", instance_type: basic, max_instances: 2. Deploys via wrangler containers push + wrangler deploy with the config's image pinned to the pushed registry tag. Wrangler 4.107.0.
Observed (2026-07-09, UTC): After wrangler deploy updated configuration.image, the rollouts API reported the rollout completed (both the default two-step 50%/100% and a later --containers-rollout=immediate single 100% step; rollout_active_grace_period: 0). The running instance kept serving the old image for over an hour: a route that exists only in the new image kept 404ing, both through the Worker and via workers.dev directly.
- An 18-minute zero-traffic window (>
sleepAfter) followed by a cold start (~3-4s first response) still served the old image.
wrangler containers instances later showed a fresh instance record (new created, version: null); its cold start also served the old image — so even re-provisioning bound back to the old spec.wrangler containers list showed LIVE INSTANCES: 2 while application health reported {active: 1, healthy: 1}, consistent with the rollout satisfying itself with a new-image instance the DO never routed to.
Expected: a completed rollout (especially --containers-rollout=immediate) means requests are served by the configured image — or the rollout does not report completed.
Workaround that resolved it: wrangler containers delete <APP_ID> + wrangler deploy (per workers-sdk #12988's "delete and redeploy"). New application ID; the first request provisioned the configured image; correct behavior since — a subsequent image rollout on the recreated application replaced the serving instance within ~35 seconds, so the stale binding appears to have been specific to the original application.
Happy to provide rollout IDs and timestamps privately if useful.
Setup: One Worker fronting a container app via
@cloudflare/containers(^0.3.7):class extends Container, a single DO addressed withgetByName,sleepAfter: "15m",instance_type: basic,max_instances: 2. Deploys viawrangler containers push+wrangler deploywith the config'simagepinned to the pushed registry tag. Wrangler 4.107.0.Observed (2026-07-09, UTC): After
wrangler deployupdatedconfiguration.image, the rollouts API reported the rollout completed (both the default two-step 50%/100% and a later--containers-rollout=immediatesingle 100% step;rollout_active_grace_period: 0). The running instance kept serving the old image for over an hour: a route that exists only in the new image kept 404ing, both through the Worker and via workers.dev directly.sleepAfter) followed by a cold start (~3-4s first response) still served the old image.wrangler containers instanceslater showed a fresh instance record (newcreated,version: null); its cold start also served the old image — so even re-provisioning bound back to the old spec.wrangler containers listshowedLIVE INSTANCES: 2while application health reported{active: 1, healthy: 1}, consistent with the rollout satisfying itself with a new-image instance the DO never routed to.Expected: a completed rollout (especially
--containers-rollout=immediate) means requests are served by the configured image — or the rollout does not report completed.Workaround that resolved it:
wrangler containers delete <APP_ID>+wrangler deploy(per workers-sdk #12988's "delete and redeploy"). New application ID; the first request provisioned the configured image; correct behavior since — a subsequent image rollout on the recreated application replaced the serving instance within ~35 seconds, so the stale binding appears to have been specific to the original application.Happy to provide rollout IDs and timestamps privately if useful.