upvote
I am here but I retired from being CTO of Cloudflare in March 2025 [1] and the current CTO is Dane Knecht (dknecht here). What advantage does decoupling Cloudflare Containers from Cloudflare Workers have?

[1] https://blog.cloudflare.com/three-chapters-at-cloudflare-pro...

reply
Not sure if it's the only blocker, but I wanted to use containers with UDP/SRT.
reply
quick piece of feedback, the workers architecture is a little bit annoying when converting from Lambda but hooking up to cloudflare MCP solves 90% of the issues
reply
there's absolutely nothing positive we want to encourage copying from AWS's architectural approach to anything.
reply
chuckles
reply
> simply expose containers to the world directly - without having to go via workers.

I run workers and containers and am curious what you mean. Do you have specific use cases in mind outside of the worker invocation model? If so, I'm curious what you'd want to run on Cloudflare. Otherwise, workers don't have to be much of a "lockin" if treated as a thin layer, more like configuration.

> You have other amazing parts of the stack anyway (D1, durable objects, a great object store).

Instead, if you mean accessing these resources from containers, it's a bit clunky [0] but it's there - you should be able to access worker bindings from containers through those outbound handlers.

[0] https://developers.cloudflare.com/containers/platform-detail...

reply
Not the OP, but for me it's a simple matter of not wanting to use typescript and the whole swamp on fire that is NPM.
reply
>Not having a simple container based compute piece made me hesitate in taking up CF

Agreed. I wish CF had something like Azure's new fast-starting Express containers.

reply
[dead]
reply