that worked, thanks for the help (do you know whether this is documented somewhere?)

RRui Hayashi that worked, thanks for the help (do you know whether this is documented somewhe...

I don't believe it is, although I wish it was. In case it helps, here is a client api I wrote against it - same as you, just based on poking through wrangler

https://github.com/skymethod/denoflare/blob/f46183514877db55d1fff21a9eb0055fa09ae827/common/cloudflare_api.ts#L2586

Steps•9/22/25, 3:42 PM

For Cloudflare Containers the included usage is 375 vCPU-minutes/month ...
That means the small "dev" instance with 1/16 vCPU can run for 6000 minutes/month, which are roughly 4 days. Is that math correct?

If I set "sleepAfter" to "0" this bascially means that every call to the container will be a 2-3 second cold start, right?

My service gets a call every 20 seconds. So if I set the timeout to 30 seconds, it will be active all the time and burn through the quota with reaching the limit after 4 days... is that correct?

Or will it still be considerably fast when sleeping?

An AWS lambda has a nasty cold start of 2-3 seconds, too, but after that it's "warm" for about 10 to 15 minutes... But I only need to pay the actual usage time, not the time it's idling.

Did I get that right about the difference between a AWS Lambda and an Cloudflare Container?

Vvilvei AWS Lambda is a function service, that can be called using http via their apigat...

pandalambda2•9/23/25, 8:15 AM

the OP is probably using lambda layers then architecturally its almost identical

Vvilvei AWS Lambda is a function service, that can be called using http via their apigat...

Steps•9/23/25, 6:48 PM

Yes, AWS API gateway is pricy. I use the HTTP Function URLs - they are free.

Vvilvei If you know you are receiving a call every 20 seconds, then you could create Dur...

Steps•9/23/25, 6:50 PM

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

Steps•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.

Steps•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 ...

Steps•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).

Steps•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.

Steps•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.

Steps•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.

that worked, thanks for the help (do you know whether this is documented somewhere?)

Similar Threads