You can set an alarm to keep it alive, but you probably want multiple containers, as you aren’t nece

✅

✅BattlefieldDuck•6/28/25, 8:04 PM

Hello, is it possible to consume message from cloudflare queue to cloudflare containers? is there any examples? thanks

HHello, I’m Allie!You can set an alarm to keep it alive, but you probably want multiple containers...

S

slice•6/28/25, 8:04 PM

I was planning to use long polling

S

slice•6/28/25, 8:05 PM

does that mean that there must be a http based entry point for containers to work ?

Iiamnotapipe cron?

S

slice•6/28/25, 10:39 PM

It would be lot of cronjobs

S

slice•6/28/25, 10:40 PM

Or delay in processsing in the bot

F

Francisco Hermida•6/29/25, 4:58 AM

made a demo showing how to use containers to create a image transformation service:
https://github.com/franciscohermida/boa-stack-img-transformer

GitHub

GitHub - franciscohermida/boa-stack-img-transformer

Contribute to franciscohermida/boa-stack-img-transformer development by creating an account on GitHub.

S

slice•6/29/25, 12:44 PM

hello, how do I have a mongodb database connectivity here ?

so everytime a container is spun it will create new instance of database ? is there any way to store the db instance in durable objects or something ?

Sslice hello, how do I have a mongodb database connectivity here ? so everytime a con...

T

Torianna•6/29/25, 2:42 PM

one idea could be to look into using R2 as a local storage sync, but you might lose data if the container stops before a sync finishes

T

Torianna•6/29/25, 2:43 PM

but as of right now, theres no way to access the container once its stopped. you could hook into the SIGKILL signal and perhaps sync that way, but its early days right now and i cant give a solid answer on how to do this

TTorianna one idea could be to look into using R2 as a local storage sync, but you might l...

S

slice•6/29/25, 2:45 PM

Thanks for the suggestion.

I think it’s better to wait few days instead of relying on such solutions for production.

T

Torianna•6/29/25, 2:46 PM

honestly, ive been thinking on this for a bit, if i come up with something, i'll give you a shout

TTorianna honestly, ive been thinking on this for a bit, if i come up with something, i'll...

S

slice•6/29/25, 4:36 PM

thanks

S

sandeep•6/29/25, 4:36 PM

Is anyone seeing their container instances getting killed quickly? In my case I have set

sleepAfter

sleepAfter

sleepAfter

sleepAfter to "10m" but it seems to be inactive in 1-2 mins always

J

João Castro•6/29/25, 5:28 PM

Containers have some sort of simultaneous open connection limits like Workers do?

J

John Spurlock•6/29/25, 7:20 PM

Hmm, when deleting a worker in the dashboard with an associated DO, which is then associated with a container application: I was surprised the container application was not deleted when the worker (and DO namespace) were deleted. This leaves an orphan app associated with a DO namespace id that no longer exists.

S

Shafeeq Elanattil•6/29/25, 10:28 PM

I have a doubt about cloudflare containers. I have a video processing work load which downlaod the video from r2 and do some processing and send the results to database. Is there any time restrictions for container run time? because it probably take more time depend upon the video size. I think container should call from worker and worker have a time execution limit.

面

面条•6/30/25, 2:06 AM

Use Cloudflare Worker + Container to process images, relying on Photon, supporting functions such as scaling, cropping, watermarking, and filters. https://github.com/ccbikai/cloudflare-worker-image

GitHub

GitHub - ccbikai/cloudflare-worker-image: 使用 Cloudflare Worker ...

使用 Cloudflare Worker + Container 处理图片, 依赖 Photon，支持缩放、剪裁、水印、滤镜等功能。 - ccbikai/cloudflare-worker-image

T

thelovekesh•6/30/25, 8:11 AM

can we connect to the hyperdrive using containers?

つ

つんでれd•6/30/25, 9:07 AM

When running Containers locally on macOS,

fetch()

fetch()

fetch()

fetch()ing to the Container throws a

Container port not found

Container port not found

Container port not found

Container port not found error even after a while the Container has

this.ctx.container!.start()

this.ctx.container!.start()

this.ctx.container!.start()

this.ctx.container!.start()ed, which is causing

startAndWaitForPorts()

startAndWaitForPorts()

startAndWaitForPorts()

startAndWaitForPorts() to time out.
Is it just me or are there any workaround, or is it a known bug?
I'm using the latest template from Cloudflare.

つつんでれd When running Containers locally on macOS, `fetch()`ing to the Container throws a...

D

Darrin Deal•6/30/25, 12:16 PM

Not just you. I have not found a fix as of yet

R

robert@moyai.ai•6/30/25, 1:17 PM

Started playing around with Containers to deploy a Motherduck MCP server. Locally running the container works

local

docker run -p 8000:8000 motherduck-sse-mcp-amd64
WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested
[motherduck] INFO - 🦆 MotherDuck MCP Server v0.6.2
[motherduck] INFO - Ready to execute SQL queries via DuckDB/MotherDuck
[motherduck] INFO - Starting MotherDuck MCP Server
[motherduck] INFO - Using MotherDuck token to connect to database `md:`
[motherduck] INFO - Connecting to MotherDuck in SaaS mode
[motherduck] INFO - Database client initialized in `motherduck` mode
[motherduck] INFO - 🔌 Connecting to motherduck database
[motherduck] INFO - ✅ Successfully connected to motherduck database
[motherduck] INFO - Registering handlers
[motherduck] INFO - MCP server initialized in sse mode
[motherduck] INFO - 🦆 Connect to MotherDuck MCP Server at http://0.0.0.0:8000/sse
[uvicorn]    INFO - Started server process [18]
[uvicorn]    INFO - Waiting for application startup.
[uvicorn]    INFO - Application startup complete.
[uvicorn]    INFO - Uvicorn running on http://0.0.0.0:8000 (Press CTRL+C to quit)

docker run -p 8000:8000 motherduck-sse-mcp-amd64
WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested
[motherduck] INFO - 🦆 MotherDuck MCP Server v0.6.2
[motherduck] INFO - Ready to execute SQL queries via DuckDB/MotherDuck
[motherduck] INFO - Starting MotherDuck MCP Server
[motherduck] INFO - Using MotherDuck token to connect to database `md:`
[motherduck] INFO - Connecting to MotherDuck in SaaS mode
[motherduck] INFO - Database client initialized in `motherduck` mode
[motherduck] INFO - 🔌 Connecting to motherduck database
[motherduck] INFO - ✅ Successfully connected to motherduck database
[motherduck] INFO - Registering handlers
[motherduck] INFO - MCP server initialized in sse mode
[motherduck] INFO - 🦆 Connect to MotherDuck MCP Server at http://0.0.0.0:8000/sse
[uvicorn]    INFO - Started server process [18]
[uvicorn]    INFO - Waiting for application startup.
[uvicorn]    INFO - Application startup complete.
[uvicorn]    INFO - Uvicorn running on http://0.0.0.0:8000 (Press CTRL+C to quit)

docker run -p 8000:8000 motherduck-sse-mcp-amd64
WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested
[motherduck] INFO - 🦆 MotherDuck MCP Server v0.6.2
[motherduck] INFO - Ready to execute SQL queries via DuckDB/MotherDuck
[motherduck] INFO - Starting MotherDuck MCP Server
[motherduck] INFO - Using MotherDuck token to connect to database `md:`
[motherduck] INFO - Connecting to MotherDuck in SaaS mode
[motherduck] INFO - Database client initialized in `motherduck` mode
[motherduck] INFO - 🔌 Connecting to motherduck database
[motherduck] INFO - ✅ Successfully connected to motherduck database
[motherduck] INFO - Registering handlers
[motherduck] INFO - MCP server initialized in sse mode
[motherduck] INFO - 🦆 Connect to MotherDuck MCP Server at http://0.0.0.0:8000/sse
[uvicorn]    INFO - Started server process [18]
[uvicorn]    INFO - Waiting for application startup.
[uvicorn]    INFO - Application startup complete.
[uvicorn]    INFO - Uvicorn running on http://0.0.0.0:8000 (Press CTRL+C to quit)

docker run -p 8000:8000 motherduck-sse-mcp-amd64
WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested
[motherduck] INFO - 🦆 MotherDuck MCP Server v0.6.2
[motherduck] INFO - Ready to execute SQL queries via DuckDB/MotherDuck
[motherduck] INFO - Starting MotherDuck MCP Server
[motherduck] INFO - Using MotherDuck token to connect to database `md:`
[motherduck] INFO - Connecting to MotherDuck in SaaS mode
[motherduck] INFO - Database client initialized in `motherduck` mode
[motherduck] INFO - 🔌 Connecting to motherduck database
[motherduck] INFO - ✅ Successfully connected to motherduck database
[motherduck] INFO - Registering handlers
[motherduck] INFO - MCP server initialized in sse mode
[motherduck] INFO - 🦆 Connect to MotherDuck MCP Server at http://0.0.0.0:8000/sse
[uvicorn]    INFO - Started server process [18]
[uvicorn]    INFO - Waiting for application startup.
[uvicorn]    INFO - Application startup complete.
[uvicorn]    INFO - Uvicorn running on http://0.0.0.0:8000 (Press CTRL+C to quit)

But when trying to deploy to a container worker I never get a successful connection with motherduck database and instead get new error in the worker that seems to be complaining about a healthcheck endpoint:

Error checking 8000: The container is not listening in the TCP address 10.0.0.1:8000

Error checking 8000: The container is not listening in the TCP address 10.0.0.1:8000

Error checking 8000: The container is not listening in the TCP address 10.0.0.1:8000

Error checking 8000: The container is not listening in the TCP address 10.0.0.1:8000. Anybody else receive these error messages when trying to connect to a container?

K

KZ•6/30/25, 2:40 PM

@Mike Nomitch | Workers PM can you guys create a containers-help and a bugs channel?

M

Mike Nomitch•6/30/25, 7:02 PM

Hey all

!

Sorry, I've been less active over last 48 hours on here due to some travel + personal commitments.

General updates on what we're working on now:

1. Fixing sleepAfter bug that currently exists in 0.0.13. If you revert to @Cloudflare/containers 0.0.11, the sleepAfter bug is actually gone, and the fixes between 11 and 13 have actually been solved at the runtime-layer, so this should be fine. - We'll be cutting an 0.0.14 release today with the fix.
2. Continue making regional placement better - We fixed the core bug that was launching containers in the wrong region. Sorry, this was an embarrassing one

. If you redeploy your container, it should be fixed. But we've got more to do here. If you spin up a bunch of containers, you'll fall back to other regions faster than we want. So working on making this better. And then also, if you launch a container via Workers CI ("Deploy to Cloudflare" button), it's not pre-warming properly.
3. Look into slow cold starts - We're seeing some people report abnormally long cold starts. A few seconds (as of now) is not unexpected, but at 5+ seconds for our hello-world or even worse 10+ seconds, something is going wrong. We think what is happening is that we're clamping down on CPU too early. The goal is to allow for higher CPU for VM + Container boot and then move it down to whatever your instance size is afer cold start is done.
4. Fix memory accounting for small instance sizes - The memory we're granting to instances is currently both container-memory and VM-memory. This meant that some people were OOMing at lower than expected values. We're switching that so the memory you get is just for the container. Should allow for rails/django on

dev

dev

dev

dev instances just fine.

M

Mike Nomitch•6/30/25, 7:02 PM

(and I'm going to be going thru open questions/issues today - sorry about the delays here!)

K

Kraus•6/30/25, 8:20 PM

Trying to build with containers but keep getting the following error:

Uncaught Error: Container is not enabled for this durable object class. Have you correctly setup your wrangler.toml?

Uncaught Error: Container is not enabled for this durable object class. Have you correctly setup your wrangler.toml?

Uncaught Error: Container is not enabled for this durable object class. Have you correctly setup your wrangler.toml?

Uncaught Error: Container is not enabled for this durable object class. Have you correctly setup your wrangler.toml?

Here is my part of my toml file:

# Containers
[[containers]]
name="transcription-containers"
class_name="TranscriptionContainer"
image="./Dockerfile"

[[durable_objects.bindings]]
name="TRANSCRIPTION_CONTAINER"
class_name="TranscriptionContainer"

# Containers
[[env.development.containers]]
class_name="TranscriptionContainer"
image="./Dockerfile"
name="transcription-containers"

[[env.development.durable_objects.bindings]]
class_name="TranscriptionContainer"
name="TRANSCRIPTION_CONTAINER"

# Containers
[[containers]]
name="transcription-containers"
class_name="TranscriptionContainer"
image="./Dockerfile"

[[durable_objects.bindings]]
name="TRANSCRIPTION_CONTAINER"
class_name="TranscriptionContainer"

# Containers
[[env.development.containers]]
class_name="TranscriptionContainer"
image="./Dockerfile"
name="transcription-containers"

[[env.development.durable_objects.bindings]]
class_name="TranscriptionContainer"
name="TRANSCRIPTION_CONTAINER"

# Containers
[[containers]]
name="transcription-containers"
class_name="TranscriptionContainer"
image="./Dockerfile"

[[durable_objects.bindings]]
name="TRANSCRIPTION_CONTAINER"
class_name="TranscriptionContainer"

# Containers
[[env.development.containers]]
class_name="TranscriptionContainer"
image="./Dockerfile"
name="transcription-containers"

[[env.development.durable_objects.bindings]]
class_name="TranscriptionContainer"
name="TRANSCRIPTION_CONTAINER"

# Containers
[[containers]]
name="transcription-containers"
class_name="TranscriptionContainer"
image="./Dockerfile"

[[durable_objects.bindings]]
name="TRANSCRIPTION_CONTAINER"
class_name="TranscriptionContainer"

# Containers
[[env.development.containers]]
class_name="TranscriptionContainer"
image="./Dockerfile"
name="transcription-containers"

[[env.development.durable_objects.bindings]]
class_name="TranscriptionContainer"
name="TRANSCRIPTION_CONTAINER"

And the code implementation:

import { Container } from "@cloudflare/containers";
export class TranscriptionContainer extends Container {
  // Port the container listens on (default: 8080)
  defaultPort = 8080;
  // Time before container sleeps due to inactivity (default: 30s)
  sleepAfter = "2m";
  // Environment variables passed to the container
  envVars = {
    MESSAGE: "I was passed in via the container class!",
  };
}

import { Container } from "@cloudflare/containers";
export class TranscriptionContainer extends Container {
  // Port the container listens on (default: 8080)
  defaultPort = 8080;
  // Time before container sleeps due to inactivity (default: 30s)
  sleepAfter = "2m";
  // Environment variables passed to the container
  envVars = {
    MESSAGE: "I was passed in via the container class!",
  };
}

import { Container } from "@cloudflare/containers";
export class TranscriptionContainer extends Container {
  // Port the container listens on (default: 8080)
  defaultPort = 8080;
  // Time before container sleeps due to inactivity (default: 30s)
  sleepAfter = "2m";
  // Environment variables passed to the container
  envVars = {
    MESSAGE: "I was passed in via the container class!",
  };
}

import { Container } from "@cloudflare/containers";
export class TranscriptionContainer extends Container {
  // Port the container listens on (default: 8080)
  defaultPort = 8080;
  // Time before container sleeps due to inactivity (default: 30s)
  sleepAfter = "2m";
  // Environment variables passed to the container
  envVars = {
    MESSAGE: "I was passed in via the container class!",
  };
}

Let me know if you have any questions, would like to get this resolved.

K

Kraus•6/30/25, 8:21 PM

@Mike Nomitch | Workers PM

G

goofysystem•7/1/25, 3:33 AM

I've encountered an inconsistency with how wrangler dev and wrangler deploy handle Docker build contexts.
The Issue:
When I place my Dockerfile in a subdirectory (e.g., cf-worker/containers/project-a/Dockerfile) and set the image field in wrangler.jsonc to './containers/project-a/Dockerfile':

wrangler dev builds successfully
wrangler deploy fails

Root Cause:
The two commands use different build contexts:

wrangler dev uses the Dockerfile's directory as the build context
wrangler deploy uses the worker's root directory as the build context

Current Workaround:
To make both commands work, I have to:

Move the Dockerfile to the worker root
Update the image field in wrangler.jsonc to './Dockerfile'
Modify COPY statements in the Dockerfile to account for the new context

Also deployed container has 30 second cold start and causing transaction timeout errors

Y

Yash•7/1/25, 1:51 PM

I'm trying to deploy a Cloudflare container. It works occasionally, but most of the time I encounter the following error:

{"error":"Internal server error","message":"A call to blockConcurrencyWhile() in a Durable Object waited for too long. The call was canceled and the Durable Object was reset."}
Has anyone come across this issue before or have any reference on how to fix it?

G

Gabriel Francisco•7/1/25, 2:55 PM

I keep getting this error, even if its working

YYash I'm trying to deploy a Cloudflare container. It works occasionally, but most of ...

T

Tory•7/1/25, 2:59 PM

Yes, we get this error all the time. We're trying to migrate a service over to containers but right now it won't reliably accept requests and this is the most common error we see.

T

Tory•7/1/25, 3:28 PM

Containers are pretty unusable for us at the moment. We get a combination of failures on the majority of requests because instances are inactive (even though we removed the

sleepAfter

sleepAfter

sleepAfter

sleepAfter time we had defined (using latest @Cloudflare/containers 0.0.16). We get a combination of

A call to blockConcurrencyWhile() in a Durable Object waited for too long. The call was canceled and the Durable Object was reset.

A call to blockConcurrencyWhile() in a Durable Object waited for too long. The call was canceled and the Durable Object was reset.

A call to blockConcurrencyWhile() in a Durable Object waited for too long. The call was canceled and the Durable Object was reset.

A call to blockConcurrencyWhile() in a Durable Object waited for too long. The call was canceled and the Durable Object was reset.

errors and this error with 5 instances sitting inactive:

There is no Container instance available at this time.
This is likely because you have reached your max concurrent instance count (set in wrangler config) or are you currently provisioning the Container.
If you are deploying your Container for the first time, check your dashboard to see provisioning status, this may take a few minutes.

There is no Container instance available at this time.
This is likely because you have reached your max concurrent instance count (set in wrangler config) or are you currently provisioning the Container.
If you are deploying your Container for the first time, check your dashboard to see provisioning status, this may take a few minutes.

There is no Container instance available at this time.
This is likely because you have reached your max concurrent instance count (set in wrangler config) or are you currently provisioning the Container.
If you are deploying your Container for the first time, check your dashboard to see provisioning status, this may take a few minutes.

There is no Container instance available at this time.
This is likely because you have reached your max concurrent instance count (set in wrangler config) or are you currently provisioning the Container.
If you are deploying your Container for the first time, check your dashboard to see provisioning status, this may take a few minutes.

MMike Nomitch Hey all 👋 ! Sorry, I've been less active over last 48 hours on here due to som...

J

Josh•7/1/25, 3:28 PM

Very excited to see some of these changes! I'll have to play around with the container placements because that was one of the biggest things I noticed in my testing.

L

LRQ•7/1/25, 6:54 PM

Hey team, was wondering if it was possible to increase the 2gb image size limit for containers? Would ideally like for it to be 10GB

G

Gabriel Francisco•7/1/25, 6:56 PM

have anyone gotten "there is no container instance that can be provided to this durable object" after deployed?

F

fare•7/2/25, 12:38 AM

Hi, I was using the container generated worker-url in another worker in my account. I get an error 1042(Worker tried to fetch from another Worker on the same zone) . Do we have some sort of handling for this particular case?

Ffare Hi, I was using the container generated worker-url in another worker in my accou...

1

1984 Ford Laser•7/2/25, 3:47 AM

Use Service Bindings probably

11984 Ford Laser Use Service Bindings probably

F

fare•7/2/25, 4:49 AM

yes I did use service bindings, it works nicely with https but it didnt work with rpc (it couldnt detect the function even after trying multiple times). Curretnly I am sticking to the http fetch through serverbindings. I have used rpc from server bindings before and it used to work fine.

G

goofysystem•7/2/25, 4:56 AM

Container + R2 + Worker workflow is not ideal: I am using a separate container service to upload a PDF with a QR code to a remote R2 using the S3 API. My Worker accesses the uploaded PDF from R2 and emails it to the user. This works fine in staging and production but not in development, since the Worker uses a local R2 instance instead of the remote one. I can't use

wrangler dev --remote

wrangler dev --remote

wrangler dev --remote

wrangler dev --remote because I use Durable Objects, Workflows, and Queues. Is there any workaround for this?

G

goofysystem•7/2/25, 5:07 AM

Should I configure a separate container per environment (staging vs production) in my wrangler.jsonc? Injected env variables would be different depending on the environment but the image itself will be the same.

V

vin•7/2/25, 9:52 AM

Is there any plan of GPU support?

You can set an alarm to keep it alive, but you probably want multiple containers, as you aren’t nece

Similar Threads

Similar Threads

Similar Threads