Cloudflare, Containers'ı talep üzerine agent sandbox'ları için yeniden inşa etti: 6 kat daha hızlı başlatma

Cloudflare, Containers servisini yapay zeka agent'larının compute tüketme biçimine göre yeniden inşa etti: bir görev hâlâ çalışırken sandbox oluşturuluyor, sandbox tam olarak işin ihtiyaç duyduğu sürece var oluyor ve bir deployment pipeline tarafından değil, agent'ın kendi kodu tarafından yapılandırılıyor. Cloudflare blog'una göre bu yeniden çalışma, uygulamaların her sandbox'ın image'ini ve instance tipini runtime'da seçmesine olanak tanıyan bir scheduling policy getiriyor, container başlatma süresini altı kattan fazla kısaltıyor ve filesystem snapshot'larını herkese açık beta aşamasına taşıyor.

Runtime kararları koda taşınıyor

Containers daha önce uygulama deployment'ları etrafında yapılandırılmıştı: bir image ve compute tahsisi deploy anında sabitleniyor ve uygulamanın tamamına uygulanıyordu; yapılandırma instance başına değil uygulama başına yönetiliyordu. Cloudflare'a göre agent'lar bu modeli kırıyor, çünkü bir workspace bir görevin ortasında talep üzerine oluşturuluyor ve birkaç dakika yaşayabiliyor, istekler arasında uyuyabiliyor ya da günler sonra geri yüklenebiliyor; image, kaynaklar, araçlar ve başlangıç filesystem'i ise eldeki görev tarafından belirleniyor.

Yeni durable_object scheduling policy'si altında image ve instance tipi, sandbox başladığında kodun geçtiği argümanlar hâline geliyor. Önceden her image-instance kombinasyonu, önceden wrangler deploy ile hazırlanmış kendi Containers uygulamasını ve Durable Object namespace'ini gerektiriyordu; dolayısıyla küçük bir Node.js sandbox'ı ile büyük bir Python build sandbox'ını yan yana çalıştırmak iki uygulama ve bir Worker içindeki routing mantığı demekti. Cloudflare bunun yerine geçilen çözümü temelde bir Durable Object içindeki bir if ifadesi olarak tanımlıyor: tek bir class, farklı boyutlarda Node ve Python ortamlarını yan yana başlatabiliyor ve yeni bir ortam eklemek başka bir deployment değil, bir kod değişikliği oluyor.

Tasarım, Cloudflare'ın ürünü her zaman tanımladığını söylediği bir özelliğe dayanıyor: her container instance'ı, kendi Durable Object'ine bağlı — yanında çalışan, yaşam döngüsünü ve giden trafiğini yöneten kalıcı, programlanabilir bir controller. Daha fazla yetenek native ctx.container API'sine taşınıyor ki Durable Object, araya bir wrapper class koymadan container'ını yönetebilsin; aynı model Sandbox SDK 1.0'a da taşınıyor.

Daha hızlı başlatma ve snapshot desteği

Agent'lar sandbox'ları kullanıcı bir sonucu beklerken başlattığı için hız, yeniden tasarımın merkezinde yer alıyor. Yazıda atıf yapılan bağımsız bir ComputeSDK benchmark'ında medyan başlatma süresi dört saniyenin hemen üstünden 648 milisaniyeye düştü. Cloudflare'ın kendi ön burst testlerinde saniyeler içinde yüz binlerce container oluşturuldu. Artık herkese açık beta aşamasında olan filesystem snapshot'ları, bir workspace'in kaydedilip daha sonra geri yüklenmesini sağlıyor; bu da bir agent'ın ürettiği dosyaların oturumlar arasında kalıcı olması gereken uzun soluklu görevleri kapsıyor.

Rollout'lar uygulama mantığına dönüşüyor

Image seçiminin başlatma anına bırakılması rollout yapılandırmasını tamamen ortadan kaldırıyor. Bir container, kod durdurana kadar başlatıldığı image'i koruyor; o Durable Object bir dahaki sefere container başlattığında, kodun seçtiği herhangi bir image'i kullanıyor. Böylece rollout stratejisi, uygulama mantığının geri kalanının yanındaki birkaç satıra indirgeniyor: Durable Object ID'sini hash'leyerek yeni bir toolchain'i yeni sandbox'ların bir dilimine canary olarak sunmak, aktif projeleri mevcut image'lerine sabitlemek ki bir agent'ın ortamı görev ortasında değişmesin, bir workspace'i doğal bir checkpoint'te (bir sonraki oturum veya bir snapshot'tan sonra gibi) taşımak ve gelecekteki başlatmaların hangi image'i seçeceğini değiştirerek geri almak — tüm bunlar yapılandırma push'lamadan veya çalışan instance'ların boşalmasını beklemeden yapılabiliyor.

Benimsenme ve workload'lar

Cloudflare, bu örüntü için mevcut talebe işaret ediyor: Base44 her kullanıcının oluşturduğu uygulamaya, yapay zekasının komut çalıştırıp bağımlılık kurabileceği izole bir geliştirme ortamı veriyor; Kilo Code, Cursor Cloud Agents, Devin Outposts, OpenAI Agents API ve Claude Managed Agents entegrasyonlarının yanı sıra container'ları cloud-agent oturumları için kullanıyor. Farklı agent workload'ları farklı ihtiyaçları öne çıkarıyor — kodlama agent'ları repository, package manager, compiler ve geliştirme sunucuları istiyor; değerlendirme araçları bilinen bir durumdan başlayan sandbox'lar istiyor; pekiştirmeli öğrenme sistemleri çok sayıda ortamı hızla oluşturmak, puanlamak ve sıfırlamak istiyor.

Neden önemli

Bu değişim, agent workload'larının altyapıya yaklaşımındaki daha geniş bir dönüşü yansıtıyor: compute artık kalıcı bir deployment değil, istek anında sağlanan, görev biçimli geçici bir kaynak. Image ve instance seçiminin koda taşınması, eskiden bir operasyon sorunu olan şeyi — ayrı uygulamalar, namespace'ler ve rollout politikaları — sıradan uygulama mantığına çevirirken, saniye altı başlatma süresi, görev başına sandbox oluşturmayı agent'ların ortam havuzu oluşturmasına veya ön ısıtmaya gerek kalmayacak kadar ucuz hâle getiriyor. Cloudflare üzerinde inşa eden ekipler için Containers artık Workers, Dynamic Workers ve Durable Objects'in yanında tam bir Linux workspace olarak yer alıyor ve bu yeniden çalışma, agent altyapısının nereye gittiğinin net bir sinyali: runtime ortamının kendisi, kodun verdiği sıradan bir karara dönüşüyor.