Deno Bergabung dengan Cloudflare: Tenggat Runtime, Deploy, dan JSR

Deno bergabung dengan Cloudflare. Pengumuman itu keluar 9 Oktober 2026 langsung dari Ryan Dahl, pencipta Deno, dan isinya lugas: seluruh tim Deno pindah ke Cloudflare. Bagi siapa pun yang menjalankan Deno di produksi, ada tiga tenggat nyata yang perlu dicatat. Runtime Deno masih didukung satu tahun lagi lewat rilis bulanan berisi perbaikan bug dan patch keamanan, setelah itu pengembangannya dihentikan. Deno Deploy beroperasi enam bulan lagi sebelum ditutup. JSR tetap jalan. Kode Deno aman dalam jangka pendek, tapi jangka panjangnya harus direncanakan dari sekarang.

TL;DR

• Seluruh tim Deno bergabung dengan Cloudflare, diumumkan 9 Oktober 2026 oleh Ryan Dahl.
• Runtime Deno didukung satu tahun lagi dengan rilis bulanan berisi bug fix dan patch keamanan, lalu development berhenti.
• Deno Deploy ditutup setelah enam bulan, dengan dukungan migrasi untuk pelanggan berbayar ke Cloudflare Workers.
• JSR tetap beroperasi dan Deno tetap open source, jadi siapa pun boleh melanjutkan pengembangannya.
• Arah fokus tim yang baru adalah celld, proyek yang dibangun di atas model pemrograman Cloudflare Workers.

Apa yang sebenarnya diumumkan Deno dan Cloudflare?

Yang diumumkan adalah perpindahan seluruh tim Deno ke Cloudflare, bukan sekadar kemitraan teknis. Ryan Dahl menulis sendiri di blog Deno bahwa keputusan ini adalah kelanjutan dari perjalanan panjang: dari Deno sebagai runtime, ke Deno Deploy sebagai layanan hosting, lalu ke celld sebagai model pemrograman terdistribusi. Dia menyebut bahwa Cloudflare akan menggabungkan kerja tim Deno dengan tim Workers dan Durable Objects.

Ambisi yang disebut Dahl adalah membuat model pemrograman itu menjadi cara default untuk membangun server, entah aplikasinya berjalan di jaringan Cloudflare atau di infrastruktur sendiri. Ini penting karena membedakan akuisisi ini dari sekadar pembelian talenta. Arah produknya eksplisit: satu platform bersama, bukan runtime terpisah plus layanan hosting terpisah.

Bagi komunitas, implikasinya ada di dua sisi. Sisi baiknya, Deno tetap open source dan kode yang sudah ada tidak mati mendadak. Sisi sulitnya, pengembangan runtime yang selama ini jadi pembeda Deno dari Node.js akan berhenti setelah satu tahun. Itu perubahan yang cukup konsekuensial untuk siapa pun yang memilih Deno justru karena runtime-nya.

Dahl menulis bahwa selama bertahun-tahun timnya mempertanyakan hal-hal mendasar: bagaimana modul seharusnya didistribusikan, jaminan keamanan apa yang bisa diberikan sebuah runtime JavaScript, apa saja yang pantas masuk ke dalam toolchain, dan bagaimana sebuah aplikasi bisa dikirim sebagai executable mandiri. Kompatibilitas dengan Node.js juga menjadi bagian penting dari kerja itu, karena pengguna ingin perbaikan dari Deno tanpa kehilangan ekosistem JavaScript yang sudah ada.

Pengumuman ini juga menjelaskan mengapa arahnya bergeser ke lapisan yang lebih dalam. Dahl mengaku bahwa membangun dan mengoperasikan Deno Deploy menunjukkan betapa besar kompleksitas yang masih tersisa di bawah pengalaman developer yang tampak mulus. Keinginan untuk menyederhanakan lapisan itulah yang melahirkan celld, dan dari situ masuk akal kalau tim akhirnya memilih bergabung dengan pihak yang sudah punya fondasi jaringan global.

Berapa lama lagi Deno runtime dan Deno Deploy bisa dipakai?

Runtime Deno didukung satu tahun lagi sejak pengumuman, dengan rilis bulanan yang berisi perbaikan bug dan patch keamanan. Setelah periode itu, pengembangan runtime Deno dihentikan. Sementara Deno Deploy, layanan hosting yang dikelola tim Deno, hanya beroperasi enam bulan lagi sebelum ditutup.

Perbedaan tenggat ini yang paling sering salah dibaca. Runtime dan platform hosting bukan hal yang sama. Runtime adalah perangkat lunak yang bisa dijalankan di mana saja, termasuk di server sendiri. Deno Deploy adalah layanan terkelola. Jadi meski Deploy ditutup lebih cepat, runtime-nya masih bisa dipakai lebih lama, dan tetap open source setelah dukungan resminya berakhir.

Berikut ringkasan nasib tiap komponen sesuai pengumuman resmi:

Komponen	Status	Tenggat	Catatan
Runtime Deno	Didukung, rilis bulanan	Satu tahun	Setelah itu development dihentikan, tetap open source
Deno Deploy	Beroperasi, lalu ditutup	Enam bulan	Dukungan migrasi untuk pelanggan berbayar ke Cloudflare Workers
JSR	Terus beroperasi	Tanpa tenggat diumumkan	Infrastrukturnya dipindahkan
celld	Aktif dikembangkan	Berjalan	Dibangun di atas model Cloudflare Workers

Yang perlu digarisbawahi dari tabel di atas: JSR tidak ikut ditutup. Registry paket yang jadi andalan Deno itu tetap hidup, sehingga dependensi yang dipublikasikan lewat JSR tidak hilang. Bagi banyak proyek, ini yang paling menentukan apakah migrasi terasa mendesak atau tidak.

Apa itu celld dan kenapa ini arah baru tim Deno?

celld adalah proyek yang dibangun di atas model pemrograman Cloudflare Workers, dan menurut Dahl, scaling-nya sudah menjadi bagian dari model pemrograman itu sendiri, bukan infrastruktur yang harus dirakit tiap aplikasi. Dia menyebut bahwa Deno Deploy mengajarkan satu hal mahal: di balik pengalaman developer yang sederhana, ada kompleksitas besar yang harus dikelola.

Itu sebabnya fokusnya bergeser. Alih-alih mempertahankan runtime dan layanan hosting yang berdiri sendiri, tim memilih menyatukan kerja mereka ke dalam satu platform yang sudah punya jaringan global, model isolasi, serta primitif penyimpanan dan koordinasi. Kombinasi dengan tim Workers dan Durable Objects menunjukkan arah itu: komputasi, penyimpanan, dan komunikasi disatukan dalam satu model.

Untuk developer yang belum pernah menyentuh Deno, ini sebenarnya kabar netral. Untuk yang sudah berinvestasi di Deno Deploy, ini alarm halus. Layanan yang mereka pakai punya tanggal kedaluwarsa, dan migrasi ke Cloudflare Workers jadi jalur yang disiapkan penyedianya sendiri.

Yang menarik, celld dibangun di atas model yang sama dengan Workers, bukan di atas Deno. Artinya tim Deno sendiri memilih bertumpu pada primitif yang sudah matang alih-alih mempertahankan lapisan runtime yang mereka kembangkan bertahun-tahun. Keputusan itu konsisten dengan pernyataan Dahl bahwa scaling seharusnya menyatu dengan model pemrograman, bukan sesuatu yang dirakit ulang oleh tiap aplikasi.

Konsekuensi praktisnya untuk pengguna Deno Deploy: jalur migrasi yang paling didukung adalah Cloudflare Workers, karena di situlah tim inti Deno akan bekerja. Bagi yang menilai biaya perpindahan, itu kabar baik karena tujuan migrasinya sudah jelas. Bagi yang tidak ingin terikat satu penyedia, ini justru alasan untuk mempertimbangkan alternatif yang lebih netral.

Apa yang sebaiknya dilakukan pengguna Deno sekarang?

Langkah paling masuk akal adalah memisahkan dua pertanyaan yang sering dicampur: seberapa mendesak migrasinya, dan ke mana harus pindah. Karena runtime masih didukung setahun dan tetap open source, proyek yang jalan di server sendiri tidak perlu panik. Yang perlu segera dipetakan justru bagian yang bergantung pada layanan terkelola.

Praktisnya, audit tiga hal. Pertama, cek apakah aplikasi benar-benar memakai Deno Deploy atau hanya runtime Deno di VPS sendiri. Kedua, daftar dependensi yang berasal dari JSR, karena registry itu tetap hidup sehingga risikonya rendah. Ketiga, tandai skrip build dan tooling yang bergantung pada Deno sebagai runtime utama, karena itulah yang paling terpengaruh ketika pengembangan berhenti.

Untuk proyek baru, keputusannya lebih sederhana: memilih Deno sekarang berarti memilih runtime yang pengembangannya akan berhenti dalam setahun. Itu tidak berarti pilihan yang salah, tapi harus disengaja, bukan kebetulan. Dokumentasi resmi Deno dan blog Cloudflare adalah dua tempat pertama yang layak dipantau untuk jadwal migrasi resmi.

Ada satu hal yang sering dilewatkan: karena Deno tetap open source, kemungkinan fork komunitas tetap terbuka. Pola ini pernah terjadi pada runtime lain yang ditinggalkan pengembang intinya, dan hasilnya bergantung pada seberapa besar komunitas yang bertahan. Untuk proyek yang bergantung pada Deno sebagai tooling internal, memantau apakah muncul fork aktif dalam enam bulan pertama adalah sinyal yang layak diperhatikan.

Dahl secara eksplisit menyebut ini sebagai perubahan yang berdampak besar bagi orang-orang yang membangun di atas Deno, dan dia berterima kasih kepada siapa pun yang menyumbang kode, membangun bisnis di atasnya, melaporkan masalah, dan mempercayai arah yang dia tentukan. Kalimat itu penting dibaca apa adanya: pengumuman ini tidak menyembunyikan bahwa ada pihak yang dirugikan, terutama mereka yang menaruh taruhan jangka panjang pada runtime ini.

Yang juga perlu dicatat, seluruh tim pindah, bukan hanya sebagian. Itu berarti perbaikan bug dan patch keamanan selama satu tahun ke depan masih dikerjakan orang-orang yang sama yang menulis runtime-nya. Kualitas dukungan di periode transisi biasanya justru paling baik di awal, lalu menurun menjelang akhir ketika perhatian tim sudah berpindah ke proyek baru.

Bagi tim yang memakai Deno sebagai runtime produksi, periode satu tahun itu sebaiknya dibaca sebagai jendela kerja, bukan masa tenang. Rilis bulanan tetap keluar, tetapi fitur baru tidak lagi ditambahkan. Artinya, kebutuhan yang belum terpenuhi sekarang kemungkinan besar tidak akan terpenuhi oleh jalur resmi, sehingga rencana jangka panjang perlu mengandalkan kode sendiri atau fork komunitas.

FAQ

Apakah Deno akan mati sepenuhnya?

Tidak dalam arti mendadak. Deno tetap open source, jadi kode dan rilis lama tetap bisa dipakai. Yang berhenti adalah pengembangan resmi oleh tim inti setelah periode dukungan satu tahun. Siapa pun boleh melanjutkan pengembangan sebagai fork.

Apakah Deno Deploy langsung dimatikan hari ini?

Belum. Deno Deploy masih beroperasi sekitar enam bulan sejak pengumuman 9 Oktober 2026. Pelanggan berbayar mendapat dukungan migrasi ke Cloudflare Workers, sementara pengguna gratis sebaiknya mulai menyiapkan alternatif lebih awal.

Apakah JSR ikut ditutup?

Tidak. JSR tetap beroperasi, hanya infrastrukturnya yang dipindahkan. Registry ini tidak punya tenggat penutupan dalam pengumuman tersebut, sehingga dependensi yang dipublikasikan di sana relatif aman untuk sementara.

Apakah saya harus segera pindah ke Node.js?

Tidak harus. Karena runtime Deno masih didukung setahun, tidak ada urgensi teknis untuk buru-buru. Yang lebih penting adalah memastikan aplikasi tidak menggantungkan diri pada Deno Deploy, karena layanan itulah yang ditutup lebih dulu.

Apa hubungan celld dengan Deno?

celld adalah kelanjutan arah tim Deno di dalam Cloudflare, dibangun di atas model Cloudflare Workers. Fokusnya menyatukan komputasi, penyimpanan, dan komunikasi dalam satu model pemrograman, alih-alih runtime terpisah plus layanan hosting terpisah.

Sumber utama tulisan ini adalah pengumuman resmi di blog Deno, halaman blog Cloudflare, dokumentasi Cloudflare Workers, registry JSR, dan proyek celld.