4 ms·

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 a

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)

yodon 4mo ago
>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.
ndjdjxixjenej 4mo ago
[dead]
jgrahamc 4mo ago
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-programmer-to-cto-to-board-of-directors/ https://blog.cloudflare.com/three-chapters-at-cloudflare-pro...
- htrp 4mo ago
  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
  - tailscaler2026 4mo ago
    there's absolutely nothing positive we want to encourage copying from AWS's architectural approach to anything.
    - tough 4mo ago
      chuckles
- CuriouslyC 4mo ago
  Not sure if it's the only blocker, but I wanted to use containers with UDP/SRT.
- eek2121 4mo ago
  I'm pretty sure I heard your groan from all the way over here in Nashville. ;)
- david_shi 4mo ago
  Speaking from personal experience, I already know exactly what I’m getting with containers. Same with Postgres.
- anilgulecha 4mo ago
  No per-request billing, portable devops - easier multicloud, known semantics (env variables, entrypoint, websocket lifecycle).
unix1 4mo ago
> 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-details/workers-connections/ https://developers.cloudflare.com/containers/platform-detail...
- sofixa 4mo ago
  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.
csomar 4mo ago
I think you have it the other way around? D1, DO, KV are lockin. The worker is not lockin as it's just JavaScript/WASM and can run in a regular browser.

yodon 4mo ago

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

ndjdjxixjenej 4mo ago

[dead]

jgrahamc 4mo ago

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-programmer-to-cto-to-board-of-directors/ https://blog.cloudflare.com/three-chapters-at-cloudflare-pro...

htrp 4mo ago
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
- tailscaler2026 4mo ago
  there's absolutely nothing positive we want to encourage copying from AWS's architectural approach to anything.
  - tough 4mo ago
    chuckles
CuriouslyC 4mo ago
Not sure if it's the only blocker, but I wanted to use containers with UDP/SRT.
eek2121 4mo ago
I'm pretty sure I heard your groan from all the way over here in Nashville. ;)
david_shi 4mo ago
Speaking from personal experience, I already know exactly what I’m getting with containers. Same with Postgres.
anilgulecha 4mo ago
No per-request billing, portable devops - easier multicloud, known semantics (env variables, entrypoint, websocket lifecycle).

unix1 4mo ago

> 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-details/workers-connections/ https://developers.cloudflare.com/containers/platform-detail...

sofixa 4mo ago
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.

csomar 4mo ago

I think you have it the other way around? D1, DO, KV are lockin. The worker is not lockin as it's just JavaScript/WASM and can run in a regular browser.