Microsandbox - mesin virtual yang terasa dan bekerja seperti container

 (github.com/microsandbox)
13 poin oleh GN⁺ 2025-05-31 | 1 komentar | Bagikan ke WhatsApp
  • microsandbox menyediakan eksekusi kode pengguna dan kode AI yang tidak tepercaya secara aman dengan isolasi tingkat mesin virtual
  • Mengatasi kelemahan VM dan container tradisional dengan boot super cepat (di bawah 200 ms), kompatibilitas container OCI, dan self-hosting
  • Memaksimalkan efisiensi integrasi untuk pengembang dan alat AI melalui SDK untuk berbagai bahasa pemrograman serta alat CLI
  • Cocok untuk berbagai kasus penggunaan AI dan pengembangan seperti eksekusi kode, lingkungan pengembangan, analisis data, otomatisasi web, dan hosting aplikasi
  • Semua pekerjaan dapat dikelola berbasis proyek, serta mendukung instalasi sistem global dan lingkungan eksekusi dengan sesi yang dipertahankan/terisolasi
  • microsandbox adalah platform open source self-hosted yang dirancang untuk mengeksekusi kode pengguna atau kode AI yang tidak tepercaya secara aman (misalnya agen AI, kode kiriman pengguna, atau kode eksperimental)
  • Eksekusi lokal tradisional memiliki kelemahan seperti kerentanan keamanan, container memiliki isolasi yang tidak sempurna karena berbagi kernel, VM tradisional memiliki boot yang lambat, dan cloud kurang fleksibel
  • microsandbox mendukung isolasi proses sejati berbasis microVM (mesin virtual ultraringan), sambil tetap memberikan kecepatan start yang cepat seperti container dan pengalaman yang ramah pengembang
  • Dibedakan melalui boot dalam 200 ms setelah penyiapan lingkungan awal, kompatibilitas image container (OCI), integrasi AI berbasis MCP, dan kontrol penggunaan infrastruktur sendiri

Ringkasan fitur utama

  • Bulletproof Security: Berbasis microVM, memberikan keamanan tingkat mesin virtual yang secara mendasar memblokir kerentanan container seperti kernel escape
  • Instant Startup: Waktu boot awal di bawah 200 ms, menghadirkan kecepatan mulai eksekusi kode yang jauh lebih cepat dibanding VM tradisional
  • Self-Hosting & Full Control: Dapat dibangun dan dioperasikan langsung di lokal atau server sendiri tanpa ketergantungan pada cloud
  • Kompatibel dengan OCI: Dapat dijalankan langsung menggunakan image container standar, sehingga kompatibel dengan workflow Docker dan container yang sudah ada
  • AI-Ready (dukungan MCP) : Dapat terintegrasi dan diperluas secara alami dengan AI berbasis MCP seperti Claude dan Agno

Workflow pengembangan dan eksekusi cepat

1. Menjalankan server

  • Server microsandbox dapat dijalankan dan lingkungan pengembangan dapat disiapkan hanya dengan perintah sederhana
  • Server juga berfungsi sebagai server MCP, sehingga dapat dipanggil langsung dari alat AI seperti Claude

2. Instalasi SDK

  • Tersedia microsandbox SDK untuk bahasa utama seperti Python, JavaScript, dan Rust
  • Dukungan tambahan untuk berbagai bahasa lain (ekstensibilitas SDK) membuka peluang integrasi yang luas untuk pengembang dan AI

3. Menjalankan kode dengan aman

  • Dapat memilih dan menjalankan lingkungan sandbox terpisah untuk berbagai bahasa seperti Python, JavaScript, dan Rust
  • Setiap sandbox merupakan lingkungan eksekusi independen, sehingga keamanan sistem tetap terjaga saat menjalankan kode eksternal
  • Contoh SDK memudahkan implementasi proses eksekusi kode aman yang asinkron dan terotomatisasi

Manajemen lingkungan berbasis proyek

  • Sandboxfile (file konfigurasi) dibuat dan dikelola per proyek, mirip workflow package manager yang ramah pengembang
  • Beberapa lingkungan sandbox (misalnya bahasa atau konfigurasi berbeda) dapat ditambahkan ke proyek dan dikelola menurut versi/lingkungannya
  • Saat menjalankan project sandbox, file serta perubahan instalasi otomatis disimpan ke direktori lokal (./menv)
  • Opsi mengaktifkan sandbox sementara tersedia, sehingga semua riwayat dan status dihapus sepenuhnya serta tetap terisolasi saat sesi berakhir

Instalasi sandbox tingkat sistem

  • Lingkungan atau aplikasi yang sering digunakan dapat diinstal dan didaftarkan sebagai executable terpisah
  • Dari terminal, pengguna dapat langsung masuk ke lingkungan eksekusi sandbox hanya dengan satu baris perintah tanpa jalur proyek
  • Setiap sandbox dapat diberi nama dan dijalankan dengan beberapa konfigurasi berbeda, sementara status sesi juga tetap dipertahankan

Kasus penggunaan utama

Eksekusi kode AI dan lingkungan pengembangan

  • Saat AI mengotomatisasi build, eksekusi, hingga debugging source code secara nyata, sistem ini menyediakan lingkungan pengembangan yang cepat, terisolasi, dan dapat diulang
  • Cocok untuk otomatisasi kode seperti pembuatan web app, perbaikan bug, dan prototipe

Analisis data

  • Library data science utama seperti NumPy, Pandas, dan TensorFlow dapat digunakan dengan aman di dalam sandbox
  • Ideal untuk workflow analisis yang memerlukan perlindungan data pribadi atau data sensitif

Agen penjelajah web

  • AI dapat menjalankan tugas otomatisasi secara aman seperti menjelajah situs web, mengisi formulir, login, dan crawling data
  • Berguna untuk pengumpulan konten, perbandingan harga, dan pengujian otomatis

Hosting aplikasi instan

  • Alat, demo, kalkulator, dan visualisasi buatan pengguna dapat langsung dibagikan sebagai layanan
  • Setiap aplikasi berjalan di ruang isolasi terpisah, dengan dukungan pembuatan dan penghentian cepat untuk lingkungan sementara

Struktur sistem

  • Pengguna memanggil microsandbox SDK dari business logic mereka sendiri
  • Permintaan untuk mengirim dan mengeksekusi kode yang tidak tepercaya dikirim ke proses server (microsandbox server)
  • Di dalam server, setiap permintaan eksekusi dijalankan dalam microVM terpisah sehingga saling terisolasi
  • Setiap microVM dapat dikonfigurasi dengan lingkungan Python/Node yang independen

Kebijakan open source

  • Didistribusikan sebagai open source di bawah Apache License 2.0

Bacaan terkait

1 komentar

 
GN⁺ 2025-05-31
Opini Hacker News
  • Ingin melihat semacam peringkat keamanan kontainer yang resmi
    1. Kurasi daftar semua kerentanan kontainer yang sudah diketahui
    2. Jalankan tiap kerentanan itu di berbagai lingkungan keamanan seperti berbasis permission, jail, Docker, emulator, dan lain-lain
    3. Lalu beri skor berdasarkan persentase eksploit yang berhasil diblokir
      Dengan pendekatan seperti ini, kontainer berbasis permission atau jail sederhana mungkin akan mendekati 0%, Docker di atas 50%, dan Microsandbox mungkin bisa mendekati 100%
      Ini sepertinya bisa menjawab rasa penasaran intuitif atas pertanyaan seperti “kenapa tidak pakai jail saja”
      Juga menarik kalau ada kontainer honeypot di web terbuka, lalu siapa pun yang berhasil meretas diberi hadiah tunai atau koin, sehingga bisa ‘membuktikan’ kontainer mana yang benar-benar mencapai 100%
      Belakangan ini, kerentanan seperti Rowhammer atau Spectre juga menunjukkan bahwa keamanan komputasi konvensional dan cloud sendiri mungkin perlu didefinisikan ulang
      Pada akhirnya, motivasinya adalah ingin mendapatkan wawasan tentang pengembangan kontainer 100% aman tanpa emulasi sempurna, serta pengamanan layanan dasar OS
  • Di lingkungan multi-tenant, masalahnya bukan “kerentanan kontainer”, melainkan struktur dasarnya yang berbagi kernel
    Kalau ada kerentanan kernel LPE (Local Privilege Escalation), itu langsung bisa berujung pada pelarian dari kontainer
    Biasanya tidak dilabeli sebagai container escape, tetapi di industri, kalau ada kernel LPE, maka keamanan kontainer dianggap otomatis runtuh
  • Untuk kontainer yang bersifat jahat, mustahil membangun lingkungan yang sepenuhnya aman hanya dengan runtime kontainer berbasis kernel Linux
    Alternatif yang terlihat adalah membatasi penggunaan system call (API) secara besar-besaran di dalam sandbox, tetapi dalam kasus ini kontainer tidak lagi menjadi platform serbaguna, dan harus dituning ulang tiap kasus, yang merepotkan
    Karena itu ada pandangan bahwa virtualisasi memang diperlukan
    Selama belum ada OS yang memory-safe dan tangguh, tampaknya ini satu-satunya jalan, dan bahkan jika OS seperti itu muncul, belum jelas apakah itu akan lebih cepat daripada menjalankan MicroVM di atas host Linux
  • Akan lebih bagus kalau konfigurasi mesin juga ikut ditampilkan
    Di Docker maupun systemd, tingkat keamanannya bisa berubah drastis tergantung berbagai pengaturan
    Rasanya dibutuhkan dataset eksperimen besar tentang pengaturan mana yang menghasilkan tingkat risiko/keamanan seperti apa
  • Sebenarnya kontainer sudah dijalankan sebagai honeypot dengan bounty tunai/koin
    Dalam kenyataan, lingkungan produksi sungguhan memang sudah menjadi target serangan banyak peretas
    Model insentif seperti ini bisa menarik, tetapi daya saing target peretasan nyata dan insentif finansialnya kemungkinan jauh lebih besar daripada lingkungan seperti itu
  • Penasaran kenapa VM tradisional butuh waktu lama untuk boot/start
    Misalnya saat menjalankan VM di Windows, harus menunggu beberapa detik sebelum apa pun mulai berjalan
    Yang dimaksud “tidak menjalankan apa pun” di sini adalah sebelum program pengguna dijalankan, bahkan sebelum instruksi pertama firmware dimulai
    Bahkan ada jeda panjang sebelum pekerjaan seperti mengosongkan file disk virtual dimulai, atau bahkan sebelum jendela VM muncul
    Penasaran kenapa bisa begitu
    • Boot kernel Linux dalam waktu kurang dari 1 detik cukup memungkinkan lewat optimisasi
      Tetapi dengan kernel standar, ada banyak operasi seperti timeout atau polling yang memang memakan waktu
      Pada sistem UEFI/CSM, persiapan hardware virtual dan inisialisasi lingkungan sistem juga memakan waktu lumayan
      WSL2 diduga memakai kernel khusus untuk menghilangkan overhead yang tidak perlu
      Startup berbagai layanan OS, persiapan filesystem, penyiapan cache, konfigurasi jaringan, dan lain-lain juga berpengaruh
      Cara tradisional juga memuat bootloader → initramfs → OS utama secara terpisah
      Untuk memangkas waktu boot secara ekstrem, dipakai pendekatan seperti Amazon Firecracker, yaitu langsung memuat image VM yang sudah diinisialisasi ke memori
      Pengenalan Firecracker MicroVM
      Di Windows, kecepatan boot juga berbeda tergantung hypervisor yang dipakai, seperti HyperV
      HyperV UEFI cukup lambat, dan banyak distribusi Linux tidak menyediakan kernel minimal yang dioptimalkan
    • Perlu info lebih lanjut tentang software VM yang dipakai
      Dalam kasus VirtualBox, gejala yang ditanyakan memang terlihat jelas, dan versi lama tidak punya delay seperti ini
      Jadi mungkin ini bukan keterbatasan hakiki dari “VM tradisional”, melainkan masalah software tersebut
    • Tidak selalu begitu
      Secara umum VM lambat karena mengemulasikan hal-hal yang tidak diperlukan
      Kalau hypervisor dibuat dengan fokus pada kecepatan boot dan bisa mengabaikan kompatibilitas legacy, maka boot dalam 125ms seperti Firecracker itu memungkinkan
    • Di Linux, penyebab utama lambatnya alokasi memori VM adalah saat mengalokasikan beberapa GB memakai page 4KB
      Kalau dialokasikan dalam unit 1GB, kecepatannya bisa meningkat drastis
      Windows mungkin juga punya pendekatan serupa
    • Mungkin memang masalah VirtualBox
      Saya sendiri pernah masuk ke Ubuntu 22 GUI lewat XRDP di Hyper-V dalam 10 detik, dan ke Ubuntu 22 server lewat SSH dalam kurang dari 3 detik
  • Menunjukkan ironi dari petunjuk instalasi yang menyuruh “pipe skrip instalasi jarak jauh langsung ke Bash” justru ketika konteksnya adalah menjalankan kode yang tidak tepercaya
    Meski begitu, ide dasarnya sendiri sangat menarik
    • Awalnya saya tidak paham maksudnya, tetapi skrip instalasi juga bisa diunduh terpisah lalu diverifikasi sendiri
      Dalam waktu dekat juga akan disediakan metode distribusi resmi
  • Mengucapkan terima kasih karena telah membagikan proyek ini, sekaligus menyebut bahwa dirinya adalah pembuat microsandbox
    Tujuannya adalah memudahkan pembuatan microVM seperti kontainer Docker
    Kalau ada pertanyaan, silakan tanya kapan saja
    • Saat ini saya sedang cukup nyaman memakainya sebagai library Python, tetapi ingin mempertahankan sandbox tetap hidup di beberapa panggilan terpisah
      Kadang muncul error seperti “Sandbox is not started. Call start() first”
      Pola di dokumentasi resmi adalah “async with”, tetapi cara pakai saya ingin instantiate sekali per class lalu terus digunakan di banyak method
      Penasaran rekomendasi atau best practice untuk kasus seperti ini
    • Saya sedang membangun jaringan pengujian software terdistribusi/terdesentralisasi (Valet Network), dan microsandbox sepertinya akan sangat berguna
      Penasaran bagaimana networking-nya bekerja
      Misalnya, apakah microvm bisa dibatasi agar hanya dapat mengakses public IP?
      Maksudnya, apakah bisa dibuat agar microvm tidak bisa mengakses IP jaringan lokal?
    • Proyek yang benar-benar keren, salut untuk appcypher
      Penasaran apakah fitur MicroVM bawaannya menyediakan antarmuka runtime OCI
      Ingin tahu apakah ini bisa dipakai di Docker/Podman sebagai pengganti runc/crun
    • Saya sempat scan readme dengan cepat, dan ada beberapa pertanyaan yang ingin dijelaskan lebih lanjut
      Kok bisa secepat itu?
      Trade-off apa yang ada dibanding VM tradisional?
      Apakah ada celah yang bisa merusak isolasi VM?
      Apakah bisa menampilkan GUI?
      Apakah ini dianggap sebagai Vagrant baru?
      Bagaimana input/output data dilakukan?
    • Terlihat sangat rapi
      Kalau saya memahaminya dengan benar, apakah backend juga bisa dijalankan secara real-time seperti server dengan ini?
      Daftar bahasa yang didukung mengesankan daftar bahasa yang didukung microsandbox
      Akan lebih baik kalau panduan kontribusinya lebih detail panduan kontributor
  • Kaget melihat dalam beberapa tahun terakhir muncul banyak opsi VM ultra-ringan yang nyaris sekali pakai
    Dulu saya punya pengalaman susah karena VM terasa lambat dan berat
    Ingin membandingkannya dengan Orbstack di macOS, terutama fitur “Linux machines”-nya
    Saya juga penasaran apakah Orb hanya mendaur ulang satu VM saja
  • Selamat
    Menyalakan VM dalam hitungan milidetik adalah peningkatan yang sangat penting
    Tetapi hal serupa juga bisa dicapai dengan CloudHypervisor atau Firecracker
    Keunggulan kontainer atas VM ada pada performa runtime
    Hal yang membuat VM melambat adalah emulasi perangkat IO
    Terutama untuk workload agen AI, overhead itu kemungkinan akan terasa di level aplikasi
    Penasaran bagaimana rencana menangani isu performa ini
    • Itu poin yang benar
      Microsandbox memakai libkrun, dan libkrun menggunakan virtio-mmio untuk block, vsock, dan virtio-fs guna mengurangi overhead performa
      Firecracker pada dasarnya juga mirip, dan proyek E2B memakai Firecracker untuk menangani workload agentic AI
      Untuk saat ini, selain isu filesystem, belum ada rencana peningkatan performa besar
  • Secara selera pribadi, teknologi kontainer terasa membuat OS jadi terlalu diperluas
    Cukup jalankan perintah mount sekali, dan akan langsung paham maksudnya
    Informasi yang seharusnya disembunyikan jadi terekspos, sehingga kegunaan perintah sederhana yang sudah ada menurun
    Masalah yang lebih serius adalah pengguna bisa langsung menyentuh struktur data internal
    Rasanya seperti memberi pengguna hak peek dan poke sekaligus
    Ide kontainernya sendiri bagus, tetapi selama kernel belum didesain ulang, pendekatan saat ini terasa cuma solusi sementara
    • Saya kurang paham isi komentarnya
      Bisa jelaskan apa yang begitu fatal ketika menjalankan mount di dalam kontainer?
      Apakah host mount benar-benar terekspos ke kontainer?
      Setahu saya, biasanya itu hanya mungkin jika volume atau semacamnya memang secara eksplisit dipasang ke kontainer
  • Kelihatannya sangat menarik sampai bikin saya ingin langsung mencobanya
    Saya juga cukup banyak bersenang-senang dengan CodeSandbox SDK, E2B, dan sejenisnya, jadi penasaran apa perbedaannya dan ke mana arah pengembangannya
    Juga ingin tahu apakah di dalamnya memakai Firecracker
    • Microsandbox tidak menyediakan solusi cloud
      Strukturnya adalah self-hosted
      Seperti E2B, ini memudahkan menjalankan sandbox berbasis microVM di lingkungan lokal (Linux, macOS, Windows akan datang), dan transisi ke lingkungan produksi juga sederhana
      Menggunakan libkrun, bukan Firecracker
    • Hal yang paling ingin saya tahu memang apakah memakai Firecracker, jadi itu yang paling menarik perhatian saya
      Saya penasaran soal isu pemeliharaan solusi microVM seperti ini, dan apakah audit keamanan akan terus dilakukan secara konsisten
      Menyiapkan Firecracker dan image OCI itu sulit, jadi saya menyambut baik munculnya alternatif seperti ini
      Kata container juga sulit ditangani
  • Setiap kali proyek seperti ini muncul, saya selalu tertarik
    Keunggulan terbesar kontainer adalah bisa dijalankan cepat tanpa harus menentukan resource secara rinci seperti ukuran disk atau jumlah core CPU
    Lalu statusnya bisa dibandingkan dengan image dan diff-nya, sehingga bisa dilihat juga perubahan apa yang dilakukan program terhadap sistem saat berjalan
    Akan bagus kalau sandboxing yang lebih aman bisa dicapai lewat VM super-kecil dengan kemudahan seperti ini
    Kadang saya juga memakai bwrap, tetapi itu bukan tool yang cocok untuk command line
    • Resource (kapasitas disk, CPU, dan sebagainya) cukup dideklarasikan sekali dalam file YAML
      Bisa juga memakai template atau pembuatan jarak jauh/otomatis
  • Agak keluar topik, tetapi saya sedang mengerjakan proyek yang memang harus menjalankan kode JavaScript tidak tepercaya
    Berkat microsandbox, saya jadi punya harapan bahwa kode seperti ini bisa dijalankan secara aman dan terisolasi
    Delay boot 200ms pun bisa diatasi dengan pool sandbox live
    Karena kompatibel dengan OCI, seluruh lingkungan sandbox juga bisa disediakan
    Penasaran apakah ini memang use case yang sangat cocok, atau ada alternatif yang lebih baik
    • runsc/gVisor juga layak dipertimbangkan
      Engine runsc bisa dijalankan juga di dalam Docker/Docker Desktop
      Namun, performa gVisor untuk hal seperti paralelisme jaringan hanya sekitar 1/3 dari docker
    • Justru kasus seperti inilah penggunaan microsandbox yang ideal
      Saya membuat microsandbox sendiri karena tidak menemukan alternatif yang lebih baik