If eastdakota/jgc are here.

- simply expose containers to the world directly - without having to go via workers.

- You have other amazing parts of the stack anyway (D1, durable objects, a great object store). These aren't considered "lockin".

- workers is "lockin" - not similar enough to lambda/cloud functions and so becomes CF specific.

Not having a simple container based compute piece has made me hesitate in taking up CF. (Fly or firebase won out)

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

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

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

[dead]