Obelisk 0.42 dirilis 4 Oktober 2026 sebagai runtime workflow durabel dan deterministik untuk beban kerja agentic. Versi ini membagi konfigurasi keamanan menjadi tiga berkas dengan tiga pemilik berbeda, menambahkan mesin JavaScript V8 native yang mempercepat replay percakapan agen berisi 726 peristiwa dari 3,17 detik menjadi 128 milidetik, dan memperkenalkan aktivitas berbasis Linux VM. Arah proyeknya jelas: menjalankan kode yang dihasilkan model di dalam batas izin yang bisa direview manusia.
TL;DR
- Obelisk 0.42 dirilis 4 Oktober 2026 untuk beban workflow durabel dan agentic.
- Konfigurasi keamanan dipecah menjadi server.toml, app.toml, dan deployment.toml dengan pemilik berbeda.
- Replay 726 peristiwa turun dari 3,17 detik di Boa WASM menjadi 128 milidetik di V8 native.
- Aktivitas Linux VM ditambahkan dengan pilihan backend Bochs WASM, QEMU, dan Firecracker.
- Proyek ini tidak lagi dipublikasikan ke crates.io, jadi instalasi harus lewat kanal resmi.
Apa Itu Obelisk dan Kenapa Runtime Workflow Durabel Penting?
Obelisk adalah runtime workflow sumber terbuka yang menyimpan kemajuan workflow di dalam basis data. Kode workflow diputar ulang secara deterministik dari riwayat itu, memakai hasil aktivitas yang sudah tercatat sebelum mengerjakan hal baru. Kalau prosesnya berhenti, proses berikutnya bisa merekonstruksi posisi terakhir, dan riwayat yang sama memungkinkan kamu melihat apa yang berjalan serta men-debug-nya setelah kejadian.
Gagasan itu mengikuti prinsip yang mereka rangkum sebagai SQLite cukup untuk workflow durabel: simpan state durabel dekat dengan runtime, dan biarkan komputasi datang serta pergi. Agen yang sedang menunggu model, alat, atau manusia bisa direpresentasikan sebagai baris di basis data, tanpa perlu satu mesin virtual hidup untuk setiap sesi. Ini yang membuat ribuan sesi bersamaan secara teoretis lebih murah daripada model satu VM per percakapan.
Pada 0.42, fondasi itu diperluas untuk beban agentic: batas keamanan yang bisa direview untuk kode hasil generasi, mesin V8 native untuk replay JavaScript yang lebih cepat, aktivitas Linux VM untuk alat yang membutuhkannya, serta prototipe workflow-agent yang bisa men-deploy, menguji, dan memperbaiki aplikasi di instance Obelisk lain.
Bagaimana Model Keamanan Berlapisnya Bekerja?
Intinya adalah pemisahan tugas lewat tiga berkas. Pada 0.41, kebijakan operator tinggal di server.toml dan aplikasi di deployment.toml, sehingga satu berkas mengerjakan dua hal sekaligus: server.toml mendeskripsikan platform sekaligus apa yang boleh dilakukan aplikasi tertentu. Versi 0.42 memecahnya menjadi tiga berkas dengan tiga pemilik.
server.toml dipegang admin platform dan berisi batas resource, konfigurasi runtime, serta gerbang eksekusi di host. app.toml dipegang admin aplikasi dan memberikan akses ke rahasia, host tujuan, dan executable yang disetujui. deployment.toml dipegang pengembang dan agen, tempat kode meminta kapabilitas di dalam pemberian yang sudah ada. Izin efektifnya adalah irisan dari ketiganya: deployment bisa meminta lebih sedikit daripada yang diberikan app.toml, tidak pernah lebih, dan app.toml tidak bisa menyalakan aktivitas eksekusi kecuali server.toml mengizinkannya.
Untuk rahasia, nilai defaultnya tetap berupa placeholder yang digantikan runtime di tepi jaringan, sehingga kode komponen tidak pernah melihat nilai aslinya. Sebagian kode memang perlu teks asli, misalnya webhook yang memverifikasi tanda tangan HMAC. Pada 0.42, aktivitas WASM dan JavaScript, webhook, aktivitas eksekusi, serta aktivitas VM bisa memintanya lewat exposed_secrets, dan setiap permintaan butuh pemberian di app.toml yang terikat pada digest komponen beserta seluruh daftar rahasia yang dibuka.
Aturan digest itu penting untuk keamanan jangka panjang: kalau agen mengubah komponen atau meminta satu rahasia tambahan, digest berubah dan pemberian lama tidak lagi berlaku. Admin aplikasi harus menyetujui digest baru sebelum runtime membuka rahasia tersebut. Aktivitas eksekusi yang menjalankan proses host tanpa sandbox kini memerlukan persetujuan kedua admin, satu di server.toml dan satu di app.toml.
Seberapa Cepat Replay dan Aktivitas VM-nya?
Angka replay diukur pada prototipe workflow-agent memakai percakapan agen nyata berisi 726 peristiwa. Tim Obelisk membandingkan tiga mesin: Boa yang dikompilasi ke WASM, Rust di Wasmtime, dan V8 native. Median replay turun dari 3,17 detik di Boa WASM menjadi 128 milidetik di V8, sekitar 25 kali lebih cepat, dan 106 milidetik di Rust.
| Metrik | Boa WASM | Rust di Wasmtime | V8 native |
|---|---|---|---|
| Median replay 726 peristiwa | 3.171 ms | 106 ms | 128 ms |
| Rentang terukur | 3.122 sampai 3.255 ms | 105 sampai 117 ms | 123 sampai 140 ms |
| Peran | Mesin default | Workflow dalam Rust | Opsi mesin JavaScript |
Untuk latensi aktivitas VM, pengukuran mereka memakai kasus kecil dan besar. Kasus kecil mencetak string dengan Bash atau mengambil halaman lokal lewat jembatan HTTP Obelisk, sedangkan kasus besar adalah demo Playwright yang menjalankan Chromium, membuka sebuah situs, menjalankan Obelisk di dalam Linux VM, dan mengembalikan keluaran perintah.
| Beban | Firecracker | QEMU KVM | QEMU TCG | Bochs WASM |
|---|---|---|---|---|
| Bash mencetak string | 0,155 detik | 0,144 detik | 0,431 detik | 0,966 detik |
| Ambil halaman lokal | 0,180 detik | 0,187 detik | 0,694 detik | 2,342 detik |
| Chromium dan Obelisk | 13,713 detik | 13,124 detik | belum ada data publik | belum ada data publik |
Semua pengukuran dilakukan di host yang sama, yaitu Intel i9-14900HX, dengan citra runtime yang sudah di-cache dan run pemanasan sebelum pengambilan data. Tim Obelisk menyertakan catatan benchmark berisi pengukuran CSV, perintah, serta versi sumber dan runtime yang dipakai, sehingga angka-angka ini bisa diperiksa ulang.
Kapan Sebaiknya Memakai Obelisk?
Paling masuk akal ketika kamu menjalankan alur kerja panjang yang harus selamat dari restart, menunggu masukan manusia, atau memanggil alat eksternal yang bisa gagal. Kemampuan memutar ulang dari riwayat membuat pemulihan setelah kegagalan jauh lebih murah daripada membangun ulang mekanisme idempotensi sendiri di setiap layanan.
Kandidat kedua adalah platform yang menjalankan kode hasil generasi model. Model keamanan tiga berkasnya menjawab masalah nyata: bagaimana memberi agen ruang untuk mengubah kode tanpa memberi akses tak terbatas. Karena permintaan akses yang lebih luas harus muncul sebagai diff kebijakan kecil di app.toml, reviewer melihat perubahan izin secara eksplisit, bukan tersembunyi di dalam kode yang berubah.
Sebaliknya, kalau kebutuhannya hanya menjalankan beberapa tugas terjadwal sederhana, menambahkan runtime workflow durabel justru menambah lapisan yang harus dipelajari. Nilai Obelisk baru terasa ketika state, pemulihan, dan batas izin menjadi masalah yang benar-benar kamu hadapi, bukan sekadar kemungkinan di masa depan.
Bagaimana Obelisk Dipakai untuk Alur Kerja Agentic?
Ada dua jalur yang disebut tim Obelisk. Pertama, biarkan coding agent menghasilkan kode aplikasi, lalu deploy kode itu di dalam kebijakan keamanan aplikasi. Aplikasi hasil generasi yang tidak memanggil model tidak menghabiskan token tambahan saat berjalan, sebuah pola yang mengikuti gagasan Zero Token Architecture dari Kelsey Hightower di PlatformCon 2026: pakai model untuk membangun aplikasi, lalu jalankan kode hasilnya.
Kedua, jalankan agen itu sendiri sebagai workflow durabel, dengan panggilan model dan alat sebagai aktivitas. Pola ini berguna untuk agen perusahaan yang menunggu manusia atau sistem eksternal, dan untuk coding agent yang bekerja di dalam sesi Bash tersimulasi dengan filesystem virtual yang persisten. Agen perusahaan mewarisi hierarki agen induk dan anak, penjadwalan durabel, serta kemampuan jeda dan lanjut dari runtime.
Prototipe workflow-agent adalah contoh jalur kedua: antarmuka peramban plus loop agen durabel. Untuk coding agent, ruang kerjanya adalah sesi Bash murah dengan filesystem virtual persisten serta perintah Obelisk dan MCP yang terintegrasi. Agen itu juga mengekspos CLI obelisk tersimulasi yang bisa terhubung ke instance Obelisk lain sebagai target. Agen bisa membaca deployment target ke filesystem virtualnya, mengubah kode aplikasi, menerapkan deployment, lalu mengujinya dengan memanggil fungsi dan webhook.
Setelah itu agen bisa memeriksa riwayat eksekusi, log aplikasi, dan jejak HTTP yang tercatat untuk mendiagnosis kegagalan, memperbaiki kode, dan deploy lagi. Kemampuan introspeksi ini yang menutup lingkarannya: bukan hanya menulis aplikasi, tetapi memeriksa bagaimana aplikasi itu benar-benar berjalan. Untuk titik awal yang lebih kecil, ada demo-agent berisi loop agen JavaScript, aktivitas model bahasa, contoh alat, pertanyaan human-in-the-loop, dan antarmuka polling, dengan deployment tiruan yang berjalan tanpa kunci model.
Apa Saja Perubahan Breaking di 0.42?
Rilis ini memecahkan konfigurasi, API runtime JavaScript, paket WIT, dan sejumlah endpoint API. Langkah migrasinya jelas dan terdokumentasi, tetapi kalau kamu menjalankan versi lama di produksi, jangan naikkan versi tanpa membaca panduan migrasinya lebih dulu.
Beberapa perubahan yang paling perlu diperhatikan: pecah konfigurasimu, beri nama aplikasinya, impor obelisk:[email protected] alih-alih memakai objek obelisk global, ganti nama activity_exec.secrets menjadi exposed_secrets dan hasilkan pemberiannya, serta tinjau nilai default baru di bagian limits. Perintah deployment get kini bernama deployment pull.
Kalau kamu memakai direktori SQLite default, sematkan path yang ada atau pindahkan basis datanya sebelum restart. Proyek ini juga tidak lagi dipublikasikan ke crates.io, sehingga perintah pemasangan lewat registri itu tidak menerima versi baru; pilih kanal yang didukung dari panduan instalasi. gRPC dan gRPC-web ditandai usang karena API REST v1 sudah mencakup semua yang dulu mereka kerjakan.
Beberapa tambahan lain yang berguna: antarmuka web kini punya tema terang dan gelap, grafik deployment, serta layar baru untuk peristiwa sistem dan retensi, dan biner rilis 0.42 menyajikannya di port 8080 secara default. Perintah obelisk generate new membuat aplikasi JavaScript awal. Retensi dan pengumpulan sampah berjalan otomatis dengan default 30 hari dan bisa dikelola lewat perintah admin.
FAQ
Apakah Obelisk masih bisa dipasang lewat cargo install?
Tidak lagi. Sejak 0.42, proyek ini tidak dipublikasikan ke crates.io, jadi perintah cargo install dan cargo binstall tidak menerima versi baru. Pilih kanal instalasi yang didukung dari panduan resminya.
Apa perbedaan Boa dan V8 di Obelisk?
Boa adalah mesin default yang dikompilasi ke WASM, sedangkan V8 native diaktifkan lewat variabel lingkungan dan memberi setiap aktivitas isolate baru. Pada benchmark mereka, V8 sekitar 25 kali lebih cepat untuk replay percakapan 726 peristiwa.
Apakah aktivitas VM wajib memakai Firecracker?
Tidak. Ada empat pilihan: Bochs yang dikompilasi ke WASM, QEMU dengan TCG, QEMU dengan KVM, dan Firecracker. Bochs berjalan tanpa biner host tetapi paling lambat dengan tamu tetap 512 MiB, sementara Firecracker memerlukan akses ke perangkat KVM.
Apakah agen bisa menjalankan proses host tanpa sandbox?
Bisa, lewat aktivitas eksekusi, tetapi sejak 0.42 aktivitas itu memerlukan persetujuan dari admin platform di server.toml dan admin aplikasi di app.toml. Izin efektifnya adalah irisan dari pemberian kedua pihak.
Apakah rahasia bisa dibaca langsung oleh kode komponen?
Secara default tidak, karena nilai rahasia digantikan placeholder di tepi jaringan. Kode yang benar-benar perlu teks asli harus memintanya lewat exposed_secrets, dan setiap permintaan butuh pemberian di app.toml yang terikat pada digest komponen.
Sumber utama: pengumuman Obelisk 0.42, dokumentasi Obelisk, repositori obeli-sk/obelisk di GitHub, dan dokumentasi Firecracker microVM.
💬 Komentar (0)
Belum ada komentar. Jadilah yang pertama! 💬