Cloudflare Containers: Sandbox Agent Start 6x Lebih Cepat

Cloudflare menerbitkan dua tulisan tentang Containers dengan selisih enam hari. Pada 24 September 2026, Cloudflare mengungkap bahwa pelanggan dengan akun Workers Paid bisa membaca sisa disk block yang ditinggalkan Containers milik tenant lain di host yang sama, celah yang saat itu sudah diperbaiki. Pada 30 September, Cloudflare mengumumkan bahwa Containers telah dibangun ulang untuk sandbox agent: start lebih dari enam kali lebih cepat, image dan instance type dipilih saat runtime, serta filesystem snapshot dalam public beta. Jika dibaca berdampingan, keduanya menggambarkan satu tekanan engineering dari dua sisi: memakai ulang host, disk, dan state yang sudah disiapkan seagresif mungkin, sambil tetap memisahkan antar-tenant.

Saya menjalankan job agent saya sendiri secara headless di satu VPS, jadi saya membaca pengumuman ini sebagai infrastructure engineer yang sedang memutuskan di mana sandbox sebaiknya berjalan. Saya belum men-deploy scheduling policy baru ini, dan tidak ada angka di sini yang merupakan hasil pengukuran saya. Tulisan ini membahas apa yang berubah, angka-angkanya dan apa yang sebenarnya diukur, bentuk API dengan kode yang dikutip dari tulisan Cloudflare, model snapshot, pengungkapan soal isolasi disk, migrasi yang dipaksa oleh tanggal 31 Desember 2026, serta hal-hal yang belum dijawab pengumuman itu. Setiap angka bisa ditelusuri ke tulisan Cloudflare atau dokumentasinya.

Apa yang berubah: Durable Object kini memegang sandbox

Sampai sekarang, sebuah Container application di Cloudflare mengunci image dan ukuran compute-nya saat deploy, dan setiap kombinasi keduanya menjadi application tersendiri dengan namespace Durable Object sendiri. Contoh dari Cloudflare sendiri memperlihatkan harganya: sandbox Node.js kecil dan sandbox build Python yang besar berarti dua application, dua namespace, dan logika routing di Worker. Scheduling policy durable_object yang baru mengubah kedua pilihan itu menjadi argumen yang dikirim kode saat sandbox dijalankan. Ada empat hal yang dirilis bersamaan:

• Pemilihan image dan instance saat runtime — satu class Durable Object bisa menjalankan sandbox Node.js dan Python dengan ukuran berbeda secara berdampingan, sehingga environment baru cukup berupa perubahan kode, bukan deployment baru.
• Jalur start yang lebih cepat — permintaan berawal dari Durable Object, dan runtime memulihkan virtual machine yang sudah disiapkan alih-alih mem-boot dari nol.
• Filesystem snapshot, dalam public beta — simpan workspace saat task dijeda lalu pulihkan nanti, atau jalankan banyak sandbox dari satu baseline yang sudah disiapkan.
• System image yang sudah didistribusikan lebih dulu, cloudflare/debian-trixie, berisi Debian Trixie Slim dan Node.js 24.20.0 LTS, sehingga agent bisa menjalankan sandbox Linux tanpa harus menulis Dockerfile terlebih dahulu.

Semua itu hanya tersedia lewat API native ctx.container di dalam Durable Object, bukan lewat wrapper class Container yang dipakai saat Containers pertama dirilis. Cloudflare mengakui bahwa Durable Object dulu sengaja disembunyikan di balik class itu agar sandbox terasa familier, dan bahwa hampir setiap tim yang mereka dampingi kemudian butuh sesuatu yang tidak disediakan lifecycle generik tersebut. Base44 dan Kilo Code dikutip sebagai pelanggan; Cursor Cloud Agents, Devin Outposts, OpenAI Agents API, dan Claude Managed Agents disebut sebagai integrasi. Scheduling policy-nya sendiri masih public beta.

Angka-angkanya, dan apa yang sebenarnya diukur

Angka utama berasal dari benchmark Burst TTI milik ComputeSDK, yang menjalankan 100 sandbox secara bersamaan dan mengukur time-to-interactive dari sisi client. Cloudflare menyebutnya independen, dan yang dibandingkan adalah jalur scheduling lama dengan policy baru:

Median adalah angka yang dipajang di judul, tetapi yang saya pedulikan adalah ekornya. Agent yang memecah satu task ke sepuluh sandbox harus menunggu yang paling lambat, jadi selisih antara median dan p99 itulah yang benar-benar dirasakan pengguna. Di jalur lama selisihnya 2,668 detik; di jalur baru 0,481 detik. Penyempitan itu lebih penting daripada angka 6x, karena itulah yang menentukan apakah fan-out ke sepuluh sandbox terasa seperti satu start atau seperti start terburuk dari sepuluh.

Angka kedua berbeda jenisnya. Dalam burst test internal yang oleh Cloudflare disebut masih awal, satu akun menjalankan 100.000 Containers dalam 5,387 detik di enam lokasi. Itu pengukuran vendor, bukan yang independen, dan tulisannya tidak menyebut instance type maupun image yang dipakai. Anggap itu bukti bahwa scheduler tidak tumbang di bawah beban burst, bukan throughput yang bisa dijadikan dasar perencanaan.

Dari mana kecepatannya: cache locality dan VM yang sudah disiapkan

Jalur lama menempatkan control plane global Cloudflare di depan setiap start: me-resolve konfigurasi application, mencari kapasitas, lalu mengoordinasikan penempatan. Dengan policy baru, permintaan berawal dari Durable Object, dan scheduler mencari kapasitas di mesin yang sama lebih dulu, baru kemudian memperluas pencarian di lokasi yang sama. Scheduler memprioritaskan host yang sudah menyimpan image atau snapshot Container itu di storage lokal, dan alih-alih mem-boot virtual machine baru, runtime memulihkan VM yang sudah disiapkan tetapi belum ditugaskan, sambil memakai ulang setup networking dan filesystem.

System image adalah ide yang sama yang didorong lebih jauh. Karena Cloudflare mengendalikan cloudflare/debian-trixie, image itu didistribusikan dan disiapkan di host yang memenuhi syarat sebelum ada permintaan masuk, sehingga start tidak pernah mengunduh atau membongkar base image sementara pengguna menunggu. Menjalankannya sama sekali tidak butuh deklarasi image di Wrangler — ini pemanggilannya seperti yang ditunjukkan tulisan Cloudflare:

// Quoted from Cloudflare's announcement. No named image in Wrangler:
// the Cloudflare-managed image is already prepared on eligible hosts.
this.ctx.container.start({
  image: "cloudflare/debian-trixie",
  instance: "standard-2",
  enableInternet: true,
  entrypoint: ["/bin/sleep", "infinity"]
});

Trade-off desainnya jelas begitu diuraikan: jalur cepat ini adalah jalur cache hit. Host yang sudah punya image atau snapshot Anda itulah yang mengubah empat detik menjadi jauh di bawah satu detik. Tulisan itu tidak menyebut image apa yang dipakai benchmark, jadi kasus yang akan saya ukur sebelum berkomitmen adalah start pertama dari custom image berukuran besar yang belum banyak di-cache host.

Memilih image dan instance type dari kode

Untuk application baru, ikut serta cukup dengan mengubah konfigurasi Wrangler. Anda menetapkan scheduling policy dan mendeklarasikan image yang boleh dipilih Durable Object; setiap key menjadi properti di this.ctx.container.images. Ini konfigurasi dari tulisan Cloudflare:

// wrangler.jsonc
{
  "containers": [
    {
      "class_name": "AgentSandbox",
      "scheduling_policy": "durable_object",

      "images": {
        "node": { "dockerfile": "./images/node/Dockerfile" },
        "python": { "dockerfile": "./images/python/Dockerfile" }
      }

    }
  ],
  "durable_objects": {
    "bindings": [{ "name": "SANDBOX", "class_name": "AgentSandbox" }]
  }
}

Pemilihannya terjadi saat task datang. Contoh Cloudflare memilih toolchain dan ukuran compute dari task itu sendiri — sesuatu yang dulu butuh application terpisah dan wrangler deploy terpisah kini cukup berupa satu kondisi:

import { DurableObject } from "cloudflare:workers";

export class AgentSandbox extends DurableObject {
  async startWorkspace(workspace) {
    if (this.ctx.container.running) {
      return;
    }

    const image =
      workspace.toolchain === "python"
        ? this.ctx.container.images.python
        : this.ctx.container.images.node;

    const instance =
      workspace.workload === "build"
        ? "standard-2"
        : "standard-1";

    this.ctx.container.start({
      image,
      instance,
      enableInternet: true,
    });
  }
}

Ada dua detail di contoh itu yang perlu diperhatikan. Pertama, start() sudah kembali sebelum Container siap menerima request, jadi dokumentasi meminta Anda menambahkan readiness check sendiri sebelum mengirim traffic atau memanggil exec(). Kedua, contoh itu memakai enableInternet: true, sementara contoh di dokumentasi scheduling policy memakai false. Untuk sandbox agent, akses outbound adalah kaki yang mengubah prompt injection menjadi eksfiltrasi data, jadi putuskan per task, jangan sekadar menyalin contoh.

Nama instance itu merujuk ke ukuran yang tetap. Pengumumannya tidak menyebutkan ukuran itu; halaman limits Cloudflare menyebutkannya, dan runtime hanya menerima lima nama ini:

Jika instance tidak diisi, Container mendapat lite. Runtime tidak menerima basic maupun alias lama dev dan standard. Ukuran custom diperbolehkan sebagai object berisi vcpu, memoryMib, dan diskMb, antara 1 sampai 4 vCPU, memori hingga 12 GiB dan disk hingga 20 GB, dengan minimal 3 GiB memori per vCPU. Jadi di contoh Cloudflare, standard-1 berarti setengah vCPU dengan 4 GiB, dan standard-2 satu vCPU penuh dengan 6 GiB.

Snapshot: simpan workspace-nya, bukan proses setup-nya

Meng-clone repository dan meng-install dependency bisa jauh lebih lama daripada menjalankan Container, dan hasil kerja agent layak disimpan antar-sesi. Filesystem snapshot, dalam public beta, menjawab keduanya: tangkap filesystem, simpan handle-nya di storage milik Durable Object, lalu kirimkan kembali ke start() nanti. Contoh dari Cloudflare:

async saveWorkspace() {
  const snapshot = await this.ctx.container.snapshotContainer({
    name: "project-ready",
  });

  await this.ctx.storage.put("workspace-snapshot", snapshot);
}

async restoreWorkspace() {
  const snapshot = await this.ctx.storage.get("workspace-snapshot");

  if (!snapshot) {
    throw new Error("No workspace snapshot found");
  }

  this.ctx.container.start({
    containerSnapshot: snapshot,
    instance: "standard-2",
    enableInternet: true,
  });
}

Cloudflare menjabarkan dua pola. Satu workspace bisa berlanjut lintas sesi — simpan saat pengguna berhenti, lalu pulihkan repository, dependency, build cache, dan perubahan keesokan harinya. Karena snapshot bersifat immutable dan bisa dipakai ulang, satu snapshot juga bisa menjadi titik awal bersama untuk banyak sandbox, dan itulah yang dibutuhkan evaluasi agent: repository, tool, dan input yang sama untuk setiap run, sehingga satu-satunya variabel adalah prompt, model, atau versi agent.

• Snapshot terikat pada image tempat ia dibuat. Setelah image diperbarui, Anda perlu membuat snapshot baru dari Container yang menjalankan image tersebut.
• image dan containerSnapshot saling eksklusif di start(), karena snapshot sudah menentukan filesystem yang akan dipulihkan.
• Ukuran snapshot maksimal 20 GB, dan snapshot disimpan selama 30 hari sejak dibuat atau sejak terakhir kali dipulihkan.

Cloudflare menyebutnya filesystem snapshot, dan namanya sekaligus menunjukkan cakupannya: yang kembali adalah file, sehingga development server atau interpreter yang sudah hangat harus dijalankan ulang setelah restore. Biaya start itu harus ikut dihitung dalam setiap estimasi berapa lama sebuah resume berlangsung.

Pengungkapan soal isolasi disk, dibaca berdampingan dengan snapshot

Pada 4 September 2026, Oren Yomtov dari Accomplish melaporkan lewat program HackerOne milik Cloudflare bahwa pelanggan dengan akun Workers Paid bisa memulihkan sisa disk block yang sebelumnya dipakai Containers milik pelanggan lain di host yang sama. Cloudflare memublikasikan detailnya pada 24 September. Setiap Container berjalan di dalam virtual machine Firecracker miliknya sendiri, tetapi writable root disk-nya berasal dari thin pool Linux device-mapper (dm-thin) yang dipakai bersama lintas akun pelanggan dan dikonfigurasi dengan skip_block_zeroing.

Mekanismenya kecil tetapi instruktif. Pool itu memakai thin block berukuran 64 KiB. Satu write 4 KiB ke region yang belum di-map membuat dm-thin mengalokasikan satu block 64 KiB utuh yang dipakai ulang, dan karena zeroing dimatikan, 60 KiB sisanya masih menyimpan apa pun yang ditulis pemilik sebelumnya, yang bisa dibaca lewat raw read ke device tersebut. Para peneliti menemukan sisa data di 18 dari 24 placement dan 20 dari 22 node di empat benua, termasuk struktur direktori, database page, dan database SQLite yang strukturnya utuh. Mereka tidak bisa memilih korban ataupun menyentuh disk yang sedang terpasang.

Responsnya cepat dan, menurut pembacaan saya, menyeluruh. Cloudflare me-merge fix runtime di hari yang sama, selesai menghapus skip_block_zeroing di seluruh fleet pada 7 September, lalu melangkah lebih jauh dari yang dituntut patch: zeroing untuk alokasi baru tidak membersihkan block yang sudah ter-map di disk yang sedang berjalan atau di cache snapshot dm-thin untuk image layer di setiap host, jadi Cloudflare mempensiunkan disk tersebut dan mengosongkan cache itu, selesai pada 19 September. Tinjauan atas telemetri disk-I/O yang tersimpan tidak menemukan aktivitas yang cocok dengan teknik itu selain dari para peneliti dan engineer Cloudflare sendiri, dan pelanggan tidak perlu melakukan apa pun.

Saya mengangkatnya di sini bukan sebagai nilai minus untuk rilis baru, tetapi karena kasus ini menunjuk lokasi risikonya dengan tepat. Celah itu berada di storage pool bersama dan cache lokal host berisi state disk yang sudah disiapkan — lapisan yang justru makin diandalkan jalur start baru, lewat image yang di-cache, snapshot yang di-cache, dan virtual machine yang sudah disiapkan. Pengumuman itu tidak menjelaskan bagaimana VM yang disiapkan atau storage snapshot dibersihkan antar-tenant. Melihat cara pengungkapan ini ditangani, saya menduga jawabannya ada dan bagus; tetap saja, itu pertanyaan pertama yang akan saya ajukan ke account team sebelum menyimpan workspace pelanggan di snapshot.

Migrasi sebelum 31 Desember 2026: dua langkah, bukan satu

Cloudflare akan memelihara class Container dan class Sandbox lama sampai 31 Desember 2026. Deployment tetap berjalan setelah tanggal itu, tetapi class tersebut tidak lagi mendapat pembaruan, dan setiap kemampuan baru hanya tersedia secara native. Jebakannya: migrasi berarti dua perubahan terpisah, dan hanya yang kedua yang membuka start lebih cepat dan snapshot:

1. Pindahkan kode ke ctx.container. Menurut Cloudflare, ini biasanya berarti mengganti extends Container menjadi extends DurableObject dan memanggil this.ctx.container secara langsung, lalu membangun ulang helper yang dulu disediakan class itu — port readiness check, request proxying, dan sleep timeout.
2. Buat application pengganti untuk policy durable_object. Scheduling policy tidak bisa diubah pada application yang sudah ada, dan penggantinya butuh class serta namespace Durable Object yang baru.
3. Rencanakan perpindahan data sendiri. Migrasi ini tidak memindahkan Container instance yang sedang berjalan maupun storage Durable Object, dan karena policy default tidak punya snapshot, Anda tidak bisa membawa filesystem lewat snapshot.
4. Push image eksternal ke managed registry Cloudflare. Named image di policy baru harus berupa Dockerfile atau referensi digest-pinned di registry itu; referensi langsung ke Docker Hub, Amazon ECR, dan Google Artifact Registry tidak diterima.
5. Periksa apa yang hilang. max_instances, placement constraint, dan pengaturan rollout tidak didukung di application pengganti, dan instance type basic tidak punya padanan karena ukuran custom dimulai dari 1 vCPU.

// Wrong: flipping the policy on the live entry. The policy is immutable,
// and the deploy fails only after the new Worker version is already serving.
{
  "class_name": "Sandbox",
  "scheduling_policy": "durable_object",   // was "default"
  "image": "./container/Dockerfile"
}

// Right: keep the old application untouched and add a replacement with a
// NEW Durable Object class, so traffic can be routed back. (Shape follows
// Cloudflare's migration guide.)
{
  "containers": [
    // Existing application. Keep this entry unchanged.
    {
      "class_name": "Sandbox",
      "image": "./container/Dockerfile",
      "instance_type": "standard-2",
      "max_instances": 10,
    },
    // Replacement application.
    {
      "name": "sandbox-durable-object",
      "class_name": "DurableSandbox",
      "scheduling_policy": "durable_object",
      "images": {
        "base": {
          "dockerfile": "./container/Dockerfile",
        },
      },
    },
  ],
  "durable_objects": {
    "bindings": [
      { "name": "SANDBOX", "class_name": "Sandbox" },
      { "name": "DURABLE_SANDBOX", "class_name": "DurableSandbox" },
    ],
  },
  "exports": {
    "Sandbox": { "type": "durable-object", "storage": "sqlite" },
    // The new class must be SQLite-backed. No storage moves across with it.
    "DurableSandbox": { "type": "durable-object", "storage": "sqlite" },
  },
}

Ada dua perubahan packaging yang menyertainya. Sandbox SDK 1.0 menjadi kumpulan utility yang bekerja di dalam class Durable Object milik Anda sendiri, bukan base class yang Anda extend, dan @cloudflare/computer ditawarkan sebagai environment tingkat lebih tinggi yang menggabungkan Dynamic Workers dan Containers dengan filesystem yang tersinkronisasi.

Hal-hal yang belum dijawab pengumuman ini

Sebuah pengumuman ditulis untuk menjawab pertanyaan yang sudah diperkirakan penulisnya. Berikut pertanyaan yang dibiarkan terbuka, dan masing-masing layak dijawab sebelum berkomitmen ke production:

• Harga. Tulisan itu sama sekali tidak menyebut harga, dan baik tulisan itu maupun halaman limits tidak menjelaskan apakah storage snapshot ditagih, atau berapa tarifnya. Dengan batas 20 GB per snapshot dan masa simpan yang diperpanjang setiap kali restore, hal ini perlu diketahui sebelum Anda membuat snapshot di setiap sesi.
• Kondisi benchmark. Tulisan itu tidak menyebut dari mana client ComputeSDK dijalankan, image apa yang dijalankan, atau instance type apa yang dipakai, dan burst test-nya adalah pengujian internal Cloudflare yang disebut masih awal.
• Hubungan burst itu dengan limit Anda. Limit akun default yang terdokumentasi adalah 1.500 vCPU dan 6 TiB memori yang berjalan bersamaan. Bahkan dengan lite, ukuran terkecil dengan 1/16 vCPU, batas itu membuat satu akun mentok di 24.000 instance yang berjalan, jadi burst 100.000 Containers itu berjalan dengan limit jauh di atas default, atau tanpa semuanya berjalan bersamaan. Tulisan itu tidak menyebut yang mana.
• Isolasi jalur reuse yang baru. Pengumuman itu tidak menjelaskan bagaimana virtual machine yang disiapkan, cache snapshot lokal di host, atau storage snapshot dibersihkan antar-tenant — lapisan yang menjadi pokok pengungkapan bulan September.
• Residensi data dan akhir masa beta. Placement constraint tidak didukung di application durable_object, yang penting jika saat ini Anda mengunci workload ke region tertentu, dan belum ada tanggal kapan policy maupun snapshot keluar dari public beta.

Tidak satu pun dari ini alasan untuk mengabaikan rilisnya. Semua itu adalah pembeda antara beta yang menjanjikan dan sesuatu yang berani saya isi dengan kode pelanggan, dan masing-masing bisa dijawab dengan tes singkat atau pertanyaan langsung.

Aturan yang saya ambil dari rilis ini: di Cloudflare, sandbox agent kini adalah Durable Object yang menentukan Container-nya sendiri, dan semua yang layak dimiliki — start lebih cepat, image saat runtime, snapshot — hanya ada di jalur itu. Jika saat ini Anda memakai class Container atau Sandbox, rencanakan perpindahan sebagai application baru sebelum 31 Desember 2026, batasi jumlah instance di kode, jauhkan credential dari snapshot, dan ukur cold start image Anda sendiri sebelum memercayai median milik orang lain.

Bacaan terkait di situs ini:

• Sandboxing AI agent dan lethal trifecta — mengapa akses network sebuah sandbox itu penting
• Cloudflare Workers vs Vercel Edge — model compute tempat Containers ini berdampingan