Deployments really seem to be oscilliating today.... Earlier the containers were available within a

Deployments really seem to be oscilliating today.... Earlier the containers were available within a minute again, but now >10min and nothing... How can this be debugged? Is this expected?

MMrBithles Is the concept containers only for local/isolated tasks that can be executed by ...

kian•8/19/25, 12:06 AM

That unenv error sounds more related to your Worker than the Container itself

TTobiLG Deployments really seem to be oscilliating today.... Earlier the containers were...

kian•8/19/25, 12:21 AM

What exactly are you measuring, the time when making a request to an inactive instance?

Kkian What exactly are you measuring, the time when making a request to an inactive in...

TobiLGOP•8/19/25, 5:22 AM

Recurrent curl requests to the endpoints, until the service gets available. Had everything between 1-20mins yesterday. And that is after the Dashboard says the deployments are done… Honestly, this is not really tolerable for a Container Service when people want to iterate quickly during development. Also, sometimes it seems that I receive cached responses, even though all the old instances are shown to be shut down, which is strange. I‘m aware that this is in beta, but multi-minute downtimes upon redeployments might be a showstopper.

TobiLGOP•8/19/25, 5:26 AM

I‘ve been part of the private beta, and I didn’t see this behavior before. Unsure if there‘s something I can do to improve this on my end, or how to debug this. The Worker logs show the timeouts to DOs, but no error messages

Nick•8/19/25, 9:50 AM

Does anyone know what happens if I redeploy the DO while a container is running? Will the container be killed?

Meathill•8/19/25, 3:37 PM

Hello, everyone. I tried to setup a Strapi Docker on worker, but now I am stuck at

Failed to start container: The container is not listening in the TCP address 10.0.0.1:1337

Failed to start container: The container is not listening in the TCP address 10.0.0.1:1337

Anyone can help me? Thank you all

Jjschlesser make sure you have a line like this in your Dockerfile `EXPOSE 1337` and dont fo...

Meathill•8/19/25, 4:22 PM

Yes, I think so, I have test this Image locally and it works well

Jjschlesser locally use localhost instead of 10.0.0.1 , you will have to do some environment...

Meathill•8/19/25, 4:24 PM

I tried 0.0.0.0 before, and it didn't work. So

localhost

localhost

should be better?

Jjschlesser what is the code you are using to connect?

Meathill•8/19/25, 4:25 PM

Sorry, I don't understand. What code do you mean? I hope to setup a Strapi docker as my backend, currently I cannot visit from browser.

Meathill•8/19/25, 4:32 PM

OK, I have used

docker build

docker build

locally and

docker run

docker run

locally to make sure my

Dockerfile

Dockerfile

works.
Then I followed the tutorial from Cloudfalre to create this worker.
The entry is quite simple, like a few lines of code:

NNick Does anyone know what happens if I redeploy the DO while a container is running?...

kian•8/19/25, 4:52 PM

I suspect it's handled the same as any other rollout: https://developers.cloudflare.com/containers/faq/#how-do-container-updates-and-rollouts-work

TTobiLG I‘ve been part of the private beta, and I didn’t see this behavior before. Unsur...

kian•8/19/25, 4:53 PM

What's the application ID (the GUID in the URL when viewing the instances page for that Containers app)?

I can pass it onto the team & ask them if they see anything unusual.

kian•8/19/25, 5:07 PM

Depending what it is, I'd probably say opening an issue on https://github.com/cloudflare/containers/issues as the best way to get it to the team

gruntlord6•8/19/25, 8:22 PM

This was an interesting one, had a degraded instance. Its gone now but it keeps occupying a slot of capacity even when all the instances are done

gruntlord6•8/19/25, 8:25 PM

its finally let go of it now but that was bizzare

Ggruntlord6 This was an interesting one, had a degraded instance. Its gone now but it keeps ...

kian•8/20/25, 12:44 AM

The team said it’s just a UI bug (they don’t count as live) which they’ll fix

Kkian The team said it’s just a UI bug (they don’t count as live) which they’ll fix

gruntlord6•8/20/25, 1:23 AM

Weird, it wouldn’t spin a 10th instance as far as I could tell

Jjschlesser i just tried to connect from my DO to 10.0.0.1 in my local environment and it wo...

Meathill•8/20/25, 2:30 AM

I think your suggestion worked somewhat. I got another error now:

Failed to start container: The container is not running, consider calling start()

Failed to start container: The container is not running, consider calling start()

I think maybe it's because that the Strapi need some time to get fully started, so the request failed

MMeathill I think your suggestion worked somewhat. I got another error now: `Failed to sta...

TobiLGOP•8/20/25, 5:25 AM

Had the same yesterday. It Took several minutes until the container was available

TTobiLG Had the same yesterday. It Took several minutes until the container was availabl...

Meathill•8/20/25, 5:47 AM

Hey, thanks, so I should refresh the page until the container got fully started and the webpage shows?

Kkian What's the application ID (the GUID in the URL when viewing the instances page f...

TobiLGOP•8/20/25, 12:15 PM

a0325cd9-6679-4d75-b1fe-4bea193f14ec

Kkian Depending what it is, I'd probably say opening an issue on <https://github.com/c...

jmickelly•8/20/25, 6:11 PM

Hello, I contacted earlier about whether if Cloudflare Containers supports nested virtualization in their Container infrasturcture and need the functionality for allowing using microVMs inside of the container.

Is there a way of customizing how the container itself exposes devices such as /dev/kvm?

TTobiLG a0325cd9-6679-4d75-b1fe-4bea193f14ec

kian•8/20/25, 7:56 PM

I've passed it onto the team. I don't suppose you have anything else like a timestamp or the image tag of the deployments that took a long time?

gruntlord6•8/20/25, 11:12 PM

is there any way to kill a container that is stuck running?

gruntlord6•8/20/25, 11:13 PM

is deleting it the only option if the process controlling it became detached?

Prydar•8/21/25, 12:23 AM

have they said anything about raising container limits for the beta? they're kinda low for our testing/purposes

China•8/21/25, 5:40 PM

Hi, I’m running into an issue with my Worker + Containers setup. In my wrangler.toml, I’ve defined both the container and the durable object binding like this:

[[env.production.containers]]
max_instances = 10
class_name = "ForumFullscanContainer"
image = "./containers/forum-fullscan/ForumFullscanDockerfile.dockerfile"

[[env.production.durable_objects.bindings]]
name = "FORUM_FULLSCAN_CONTAINER"
class_name = "ForumFullscanContainer"

[[env.production.containers]]
max_instances = 10
class_name = "ForumFullscanContainer"
image = "./containers/forum-fullscan/ForumFullscanDockerfile.dockerfile"

[[env.production.durable_objects.bindings]]
name = "FORUM_FULLSCAN_CONTAINER"
class_name = "ForumFullscanContainer"

I deployed locally yesterday using npx wrangler deploy --env=production, and it was working fine. Today, after another deployment via our GitHub Action, it stopped working. The wrangler.toml hasn’t changed. and the Durable Object migration has also been applied.
The error I’m seeing in the Worker logs is:
"Container is not enabled for this durable object class. Have you correctly setup your wrangler.toml?"
Could someone help me understand why this might be happening?

joeyblake•8/22/25, 12:40 AM

Hey y'all! I have been trying to get a very simple worker and container running locally, and when the container is created, it gets a really high

HOST_PORT

HOST_PORT

I'm using rancher desktop. And my docker file builds correctly and is usable on its own. But when running

wrangler dev

wrangler dev

then hitting the endpoint I see the container start up in rancher, but the

HOST_PORT

HOST_PORT

is not what I would expect it to be. I'm assuming that's why I can't connect when using the local worker. I really appreciate any insight y'all may have.

goofysystem•8/22/25, 12:42 AM

Running into this on deploy:

--- 2025-08-22T00:33:52.056Z debug
Checking for local image registry.cloudflare.com/<account-id>/rust-task-container-staging:90ba2969 failed with error: Expected there to only be 1 valid digests for this repository: registry.cloudflare.com/<account-id>/rust-task-container-staging but there were 0
---

--- 2025-08-22T00:34:28.883Z log

---

--- 2025-08-22T00:34:28.934Z error
[31m✘ [41;31m[[41;97mERROR[41;31m][0m [1mError rolling out application rust-task-container-staging due to an internal error (request id: undefined):   Internal Server Error[0m


---

--- 2025-08-22T00:34:28.935Z debug
Error: Error rolling out application rust-task-container-staging due to an internal error (request id: undefined):   Internal Server Error
    at apply (/Users/myname/projects/work/utc/apps/edge-service/node_modules/wrangler/wrangler-dist/cli.js:64300:17)
    at process.processTicksAndRejections (node:internal/process/task_queues:105:5)
    at async deployContainers (/Users/myname/projects/work/utc/apps/edge-service/node_modules/wrangler/wrangler-dist/cli.js:64435:5)
    at async deploy (/Users/myname/projects/work/utc/apps/edge-service/node_modules/wrangler/wrangler-dist/cli.js:152882:5)
    at async Object.handler (/Users/myname/projects/work/utc/apps/edge-service/node_modules/wrangler/wrangler-dist/cli.js:80948:66)
    at async Object.handler (/Users/myname/projects/work/utc/apps/edge-service/node_modules/wrangler/wrangler-dist/cli.js:77880:7)
---

--- 2025-08-22T00:33:52.056Z debug
Checking for local image registry.cloudflare.com/<account-id>/rust-task-container-staging:90ba2969 failed with error: Expected there to only be 1 valid digests for this repository: registry.cloudflare.com/<account-id>/rust-task-container-staging but there were 0
---

--- 2025-08-22T00:34:28.883Z log

---

--- 2025-08-22T00:34:28.934Z error
[31m✘ [41;31m[[41;97mERROR[41;31m][0m [1mError rolling out application rust-task-container-staging due to an internal error (request id: undefined):   Internal Server Error[0m


---

--- 2025-08-22T00:34:28.935Z debug
Error: Error rolling out application rust-task-container-staging due to an internal error (request id: undefined):   Internal Server Error
    at apply (/Users/myname/projects/work/utc/apps/edge-service/node_modules/wrangler/wrangler-dist/cli.js:64300:17)
    at process.processTicksAndRejections (node:internal/process/task_queues:105:5)
    at async deployContainers (/Users/myname/projects/work/utc/apps/edge-service/node_modules/wrangler/wrangler-dist/cli.js:64435:5)
    at async deploy (/Users/myname/projects/work/utc/apps/edge-service/node_modules/wrangler/wrangler-dist/cli.js:152882:5)
    at async Object.handler (/Users/myname/projects/work/utc/apps/edge-service/node_modules/wrangler/wrangler-dist/cli.js:80948:66)
    at async Object.handler (/Users/myname/projects/work/utc/apps/edge-service/node_modules/wrangler/wrangler-dist/cli.js:77880:7)
---

rust-task-container-staging already exists and can be viewed from the dashboard btw.

EDIT: Ok found a way to reproduce this. wrangler deploy will always fail the very first time when there is no image and generate an image tagged registry.cloudflare.com. If I keep the image and run deploy, it will succeed with Image already exists remotely, skipping pushImage already exists remotely, skipping push. If you delete the image from Docker Desktop and run deploy you will run into the same error. This explains why it always fails in ci.

Maurice•8/22/25, 7:10 AM

When working inside containers there is no access to worker bindings, so when using a product like queues, limited to pushing by sdk / http. This works, however, when working on development (wrangler dev), the simulated queues are in the run time and not exposed to http, so the only option is to debug in production. Is there a better way to get around this? I'm not sure this is the best place to report this, but I figured someone would pick it up.

scotto•8/22/25, 1:54 PM

it would be great to have a simple doc on deploing a single dockerfile, similar to what flyio offsets, like Dockerfile -> deploy, simple, current docs are mostly focues on the workers + containers integrations

Ggoofysystem Running into this on deploy: ``` --- 2025-08-22T00:33:52.056Z debug Checking fo...

gruntlord6•8/22/25, 8:27 PM

I always have to deploy twice lol

MMaurice When working inside containers there is no access to worker bindings, so when us...

gruntlord6•8/22/25, 8:28 PM

Can't you just have the durable object make those requests?

Ggruntlord6 I always have to deploy twice lol

goofysystem•8/22/25, 8:31 PM

So is everyone deploying locally bc ci builds the image afresh everytime so it will always fail

. but also it used to work before so

gruntlord6•8/22/25, 8:32 PM

no it seems to work fine either though CI/CID when I push with github. If using wrangler it works the second time I push

gruntlord6•8/22/25, 8:33 PM

I have noticed a higher error rate from wrangler the last few days, both on my machine and the CI/CID pipeline. Most of them internal errors or "malformed responses"

Ggruntlord6 no it seems to work fine either though CI/CID when I push with github. If using...

goofysystem•8/22/25, 8:36 PM

I use wrangler in ci too thats probably why. I really want to stay using wrangler to deploy from ci so hopefully fix comes soon

Ggoofysystem Running into this on deploy: ``` --- 2025-08-22T00:33:52.056Z debug Checking fo...

goofysystem•8/23/25, 3:07 AM

Found out that wrangler deploy does not replace the image with the new image ever. The image shown on cloudflare containers dashboard was much older version regardless of how many new image I deploy. Obviously, the first failure uploads to the repository but fails to update the image to use the newst tag. And the second run just skips pushing the new image and treats it as already existing. Only way to get new image up is deleting the container from the dashboard and redeploying, which is not ideal.

bentlegen•8/23/25, 3:51 AM

Came in here to basically repeat the same as above.

"✘ [ERROR] Error rolling out application <appname> due to an internal error (request id: undefined): Internal Server Error"

We basically can't auto-deploy new containers anymore from CI. Pretty painful.

[[env.production.containers]] max_instances = 10 class_name = "ForumFullscanContainer" image = "./containers/forum-fullscan/ForumFullscanDockerfile.dockerfile" [[env.production.durable_objects.bindings]] name = "FORUM_FULLSCAN_CONTAINER" class_name = "ForumFullscanContainer"

--- 2025-08-22T00:33:52.056Z debug Checking for local image registry.cloudflare.com/<account-id>/rust-task-container-staging:90ba2969 failed with error: Expected there to only be 1 valid digests for this repository: registry.cloudflare.com/<account-id>/rust-task-container-staging but there were 0 --- --- 2025-08-22T00:34:28.883Z log --- --- 2025-08-22T00:34:28.934Z error [31m✘ [41;31m[[41;97mERROR[41;31m][0m [1mError rolling out application rust-task-container-staging due to an internal error (request id: undefined): Internal Server Error[0m --- --- 2025-08-22T00:34:28.935Z debug Error: Error rolling out application rust-task-container-staging due to an internal error (request id: undefined): Internal Server Error at apply (/Users/myname/projects/work/utc/apps/edge-service/node_modules/wrangler/wrangler-dist/cli.js:64300:17) at process.processTicksAndRejections (node:internal/process/task_queues:105:5) at async deployContainers (/Users/myname/projects/work/utc/apps/edge-service/node_modules/wrangler/wrangler-dist/cli.js:64435:5) at async deploy (/Users/myname/projects/work/utc/apps/edge-service/node_modules/wrangler/wrangler-dist/cli.js:152882:5) at async Object.handler (/Users/myname/projects/work/utc/apps/edge-service/node_modules/wrangler/wrangler-dist/cli.js:80948:66) at async Object.handler (/Users/myname/projects/work/utc/apps/edge-service/node_modules/wrangler/wrangler-dist/cli.js:77880:7) ---

Deployments really seem to be oscilliating today.... Earlier the containers were available within a

Similar Threads