My question is not so much about how to avoid the cold start... it's about the billable duration. T

My question is not so much about how to avoid the cold start... it's about the billable duration.

The difference is that idle time on Containers cost while the time an AWS lambda stays warm after invocation doesn't, right?

If I set set the cointainer sleep to 0, will every call be a cold start or will it stay warm for a while?

SSteps My question is not so much about how to avoid the cold start... it's about the b...

gruntlord6•9/23/25, 11:45 PM

thats more comparable to a durable object then a container

pandalambda2•9/24/25, 1:33 AM

So the new about capnweb dropped, and it's powering wrangler local<>remote services in dev mode, i.e. it can communicate with Cloudflare services remotely and this is powered by capnweb protocol, so things like kv, worker bindings, queues etc.. are no longer restricted to workers, so I guess in theory if one digs into the source code for wrangler, we could use the same code to allow direct communicate from containers. My question is are you planning to drop a few SDKs for this - node initially, java, dotnet, go, rust? And secondly is this on the short term horizon perhaps this birthday week?

pandalambda2•9/24/25, 1:34 AM

ref: https://blog.cloudflare.com/capnweb-javascript-rpc-library/#try-it-out (the bottom bit about remote bindings)...

The Cloudflare Blog

Cap'n Web: A new RPC system for browsers and web servers

Cap'n Web is a new open source, JavaScript-native RPC protocol for use in browsers and web servers. It provides the expressive power of Cap'n Proto, but with no schemas and no boilerplate.

pandalambda2•9/24/25, 1:35 AM

it would really nice to not have to use the cripppled front-door rest HTTP apis for cloudflare services from containers, fingers crossed for more info

pandalambda2•9/24/25, 1:39 AM

and if capnweb rpc trafifc to CF services did not incur container egress fees...

pandalambda2•9/24/25, 4:00 AM

@kian | Containers can you raise this internally - https://www.cloudflare.com/ips/ is out of date. for example I am making outbound container egress from 104.28.154.x currently

IP Ranges | Cloudflare

This page is intended to be the definitive source of Cloudflare’s current IP ranges.

pandalambda2•9/24/25, 4:00 AM

does not intersect with any of those ipv4 ranges

pandalambda2•9/24/25, 4:01 AM

afaik

pandalambda2•9/24/25, 4:03 AM

NetRange: 104.16.0.0 - 104.31.255.255
CIDR: 104.16.0.0/12

pandalambda2•9/24/25, 4:03 AM

its listed as a /13

pandalambda2•9/24/25, 4:04 AM

I'm hoping this is only used for container egress, as that a pretty huge oversight if these are proxy ips as well (our iac fetch this ipv4 file to allow cf <-> origin traffic)

Ppandalambda2 @kian | Containers can you raise this internally - https://www.cloudflare.com/ip...

kian•9/24/25, 4:33 AM

It's actually expected that Containers don't egress from those IPs.

kian•9/24/25, 4:34 AM

There isn't currently any published IPs that you can use to lock down egress from Containers alone.

pandalambda2•9/24/25, 4:50 AM

thanks, is a stable range of outbound IPs expected for GA?

Ggruntlord6 thats more comparable to a durable object then a container

StepsOP•9/24/25, 5:19 AM

I understand that Containers are backed by Durables…

However, my question doesn’t matter anymore as the pricing on Containers that also includes Durables and Workers according to the docs, seems pretty confusing. There are too many parts to understand the total costs.

Given my recent experiences with R2 and the strict „no refunds“ policy this could be very well the next thing I mess up and end up with unexpected/high bills. So I decided that I will stick strictly to workers for everything I can do with them and for everything else they need to call an AWS lambda.

pandalambda2•9/24/25, 5:25 AM

@Steps watching with interest but I agree far too many unknowns across the whole board, not just pricing. In april they said https://blog.cloudflare.com/cloudflare-containers-coming-2025/ "We'll be working out the details between now and the beta, and will be launching with clear, transparent pricing across all dimensions so you know where you stand" <- . well beta came and this couldn't be further from the truth, clear as mud

currently reading https://docs.aws.amazon.com/lambda/latest/dg/images-create.html#images-ric

The Cloudflare Blog

Simple, scalable, and global: Containers are coming to Cloudflare W...

Cloudflare Containers are coming this June. Run new types of workloads on our network with an experience that is simple, scalable, global and deeply integrated with Workers.

StepsOP•9/24/25, 5:42 AM

On AWS I used the Java images in the past and for the better cold start time I’m moving to native images using Kotlin/Native.

Yes, it’s not only the pricing, but mostly. The other thing (as said above) is that they can’t idle without cost. That’s the deal breaker for me, too.

I’d like to pay only for the time the Container actual does something purely based on the time it takes. Having different prices based on instance size is fine, of course. Paying for Durables extra seems unnecessarily.

pandalambda2•9/24/25, 5:55 AM

Oh that's interesting, I didn't realize Kotlin/Native was ready for server-side work, Ktor is there now i see, but you've got no r2dc or jdbc? I guess if you've got a http client though you can talk to all of aws rest http apis including dynamodb, but I imagine you have zero sdks so you're hand rolling your own high level client code for the dependencies?

SSteps I understand that Containers are backed by Durables… 🤔 However, my question do...

gruntlord6•9/24/25, 5:56 AM

I think thats probably a good call here, its very easy to lose track of containers given how early they are in dev at this stage

gruntlord6•9/24/25, 5:57 AM

personally I decided unless its something that needs to live in cloudflare its honestly easier to have an actual vps running a container vs using cloudflare containers, especially at this stage

gruntlord6•9/24/25, 5:57 AM

its certainly cheaper and more performant, although less scalable

pandalambda2•9/24/25, 5:59 AM

https://dokku.com/ on a VM for now works, but we may go AWS lambda or ecs fargate in meantime, see what comes out in rest of developer week from CF

Dokku - The smallest PaaS implementation you've ever seen

pandalambda2•9/24/25, 6:00 AM

birthday week *

Ppandalambda2 Oh that's interesting, I didn't realize Kotlin/Native was ready for server-side ...

StepsOP•9/24/25, 6:02 AM

AWS is migrating their Kotlin SDK to Native. I expect that to be usable in the near future.
Right now I use APIs via HTTP if I need to.
Here is a small project I build: https://github.com/StefanOltmann/steam-login-helper
it doesn’t use AWS APIs. I still need to figure out how to use them, but that’s the next thing I’m going to do.

pandalambda2•9/24/25, 6:02 AM

>AWS is migrating their Kotlin SDK to Native

oh wow, that is game changing..

pandalambda2•9/24/25, 6:02 AM

will take a look at that repo, thanks

Ashish Rawat•9/24/25, 6:10 AM

Why containers pricing look so costly considering it also require durable objects. I compared this with cloud run (instance based billing):
- vCPU :
GCP : $0.000018/sec vs $0.000020/sec (CF)
- Memory
GCP : $0.000002/sec vs $0.0000025/sec (CF)

Plus cloudflare containers run on durable objects + workers which is another extra cost. So overall, this looks like atleast 2x costlier.

I'm already using workers and my use case with containers is to host mongodb atlas with small container (never sleep) for fast requests and mongodb in-built connection pooling (since mongodb require durable object for connection pooling).

StepsOP•9/24/25, 6:34 AM

I find pricing hard to compare here.
A fair comparison would include all other costs a Container has - so workers, durables and whatever else included.

StepsOP•9/24/25, 7:57 AM

Maybe if/when they put up a pricing calculator that lets me calculate the costs for my scenario: A call approx. every 20 seconds that takes ~250ms to calculate on a machine with 128 or 256 MB RAM that idles between the calls.

On AWS I can translate this into the two metrics they have: Absolute call count and GB/s computing time.

For Containers this is much harder right now.

Also, I don't know if cloud run charges for idle time or not. Makes a difference, too.

StepsOP•9/24/25, 8:21 AM

In short: Containers should be priced similar to workers. Like a more powerful (and thus more expensive) worker.

JayTheDeveloper•9/24/25, 9:09 AM

Reposting sorry, because i didn't notice there is a dedicated containers channel.

Does the cloudflares containers support a "fire-forget" use case? I'm looking at an ffmpeg encoding scenario where I use containerStub.start({entryPoint: args}) where I don't await the start method.

I tried a few things but it seems my container gets kills (exit code 143) before it even completes.

pandalambda2•9/24/25, 9:16 AM

how long is the ffmpeg encoding taking? so you want to run longer than the request to the container? i.e. /submitjob and return something like { ok: true, queuedId: guid } and keep going?

JayTheDeveloper•9/24/25, 9:18 AM

Basically yeah, start the container with an assigned jobId. On my grunty desktop a 4k video can be encoding into HLS 720p, 1080p, 2160p in about 3 minutes. Video is about 8GB, I would assume it takes a bit longer on highest container type but unsure.

pandalambda2•9/24/25, 9:21 AM

you can probably just adjust sleepAfter to something high and be done, are you sure it's not the process inside the container that causing the shutdown.

but perhaps instead of awaiting .start have you tried passing the promise to waitUntil at the worker https://developers.cloudflare.com/workers/runtime-apis/context/#waituntil although I would of thought this wouldn't been coupled tbh

pandalambda2•9/24/25, 9:23 AM

also check the logs in dashboard under containers too incase its been terminated for some reason (OMM etc)

JayTheDeveloper•9/24/25, 9:36 AM

It says exit code 143, presumably cloudflare killed it

JayTheDeveloper•9/24/25, 9:48 AM

I'll try a higher timeout and see if that helps.

SSteps Maybe if/when they put up a pricing calculator that lets me calculate the costs ...

Ashish Rawat•9/24/25, 10:03 AM

Actually this is what I'm saying, cloudflare container is overall 2x costlier compared to aws or cloud run. Here idle time doesn't matter because I calculated based on per second billing.

pandalambda2•9/24/25, 12:24 PM

Possibly more than 2x, it looks like cloudflare charge for any container egress, so thats hitting D1/KV/queues rest endpoints at CF too, also whilst you can get 1TB free on AWS for your first container by smashing the traffic through cloudfront, in CF you have no control over placement yet, I'm getting provisioned in AU ffs most expensive place on planet, and 500gb allowance there. Of course this is a different at scale, but testing crazy, no clarity..

Ppandalambda2 So the new about capnweb dropped, and it's powering wrangler local<>remote servi...

Matthew 🦘🫕•9/24/25, 2:21 PM

I had these same questions, I was hoping to use Apache Ballista on Containers for Distributed Compute on the edge in the future but it communicates in between the Scheduler & Executor using gRPC so I would need to rewrite these services to use CapnWeb?

Mike Nomitch•9/24/25, 8:56 PM

Hey all, want to give a quick update on two topics: limits and pricing

Mike Nomitch•9/24/25, 8:58 PM

Limits

We initially set our public limits for concurrent containers pretty low and don’t (yet) have large instance types. This was because we wanted to make sure the system could handle load and the plan has always been that we’ll move these up with time.

Tomorrow, we’ll be bumping concurrent resource limits considerably. We’ll still bump it up further in the future, but it’ll be a big step up (over 10 X where we’re at today). If you need more than that, please reach out!

On instance types, we’ll also add a larger one, but it won’t be huge (8 GiB, 1 vCPU, 12 GB disk). More to come in the future, but we’ll need to be a bit more gradual here to make sure we can place well at scale.

Mike Nomitch•9/24/25, 9:00 PM

Pricing

Good news and bad news.

Bad news: Nothing happening this week.
Good news: There will be changes soon (think weeks, not quarters).

Changes happening on two fronts:
- Firstly, we don’t want people having to think about Durable Object pricing at all if you’re using them for a Container. Most of it will just "go away" - the exception being DO storage (if and only if you’re using it).
- Secondly, overall cost will come down. Aside from the DO pricing going away, we’ve got another change that’ll bring cost down.

I have to be a big vague here right now unfortunately (with pricing I don’t want to make any promises before we finalize things) - To set expectations, we still won't be the cheapest spot to run a container, but the net effect on price will be non-trivial.

Mike Nomitch•9/24/25, 9:01 PM

Appreciate the patience here! On both of these fronts, we’re still learning, changing things internally, and being cautious. - We didn’t want to get put into a situation where our system got overloaded with containers and we wanted to be cautious on pricing while we worked out some internal details and got a better handle of costs with real usage.

So, stay tuned! - Limits change imminently, and pricing changes not too far off!

Paul Dlug•9/24/25, 9:23 PM

My service is failing to respond with the error

Container suddenly disconnected, try again

Container suddenly disconnected, try again

being returned. When I look at the worker logs it shows a 500 error in the fetch but when I look at the container logs it shows it responded to the request with a 200 OK. Everything works perfectly running locally w/

wrangler dev

wrangler dev

but fails in production (though this same service did work yesterday).

MMike Nomitch **Limits** We initially set our public limits for concurrent containers pretty ...

1984 Ford Laser•9/24/25, 11:15 PM

Appreciate these clarifications, people have been getting a bit worried about Containers even though its still very early days for the product. Really curious to see where things go in future!

MMike Nomitch Appreciate the patience here! On both of these fronts, we’re still learning, cha...

fforres•9/25/25, 1:38 AM

we still won't be the cheapest spot to run a container

Is that the goal?

If so (and with those announcements) moving off of AWS is looking very tempting

pandalambda2•9/25/25, 2:14 AM

I think people just want certainty over costs, I wouldn't expect CF to be cheapest, that's the different market full of naff providers with no redundancy that fake CPU cores and throw everything out over he.net/cogent, clarity over egress pricing would be a good start..

My question is not so much about how to avoid the cold start... it's about the billable duration. T

Similar Threads

Similar Threads

Similar Threads