Sprites - Sandbox Persisten dengan Penyimpanan Status

 (fly.io)
5 poin oleh GN⁺ 2026-01-11 | 1 komentar | Bagikan ke WhatsApp
  • Fly.io baru saja memperkenalkan ‘Sprites’, konsep komputer cloud persisten yang menggantikan sandbox sekali pakai yang ada selama ini
  • Dapat dibuat dalam 1~2 detik, serta menyediakan transisi idle otomatis, pemulihan checkpoint, dan penyimpanan tahan lama 100GB
  • Menyoroti bahwa model container stateless yang ada saat ini tidak efisien untuk agen AI (misalnya Claude), dan menekankan perlunya lingkungan persisten
  • Sebagai contoh nyata, ditunjukkan pengalaman Claude membangun dan menjalankan dalam jangka panjang aplikasi Go berbasis SQLite (MDM) di atas Sprite
  • Kesimpulan artikel: “Era sandbox telah berakhir, dan era komputer sekali panggil telah dimulai”

Sprites: komputer cloud persisten - https://sprites.dev/

  • Fly.io menyatakan bahwa model sandbox read-only yang ada saat ini sudah usang, lalu memperkenalkan ‘Sprite’ sebagai penggantinya
    • Dengan perintah sprite create, root shell Linux dibuat dalam waktu 1 detik
    • Sprite memiliki penyimpanan tahan lama 100GB, dapat otomatis masuk mode hemat saat idle lalu dipulihkan kembali
  • Dengan sprite-env checkpoints create, checkpoint seluruh sistem dapat dibuat seketika
    • Dengan sprite checkpoint restore v1, sistem dapat dipulihkan dalam 1 detik, memungkinkan version control tingkat sistem seperti Git
  • Fitur utama
    • Mudah membuat ratusan instance
    • Penghentian penagihan otomatis saat idle (Idle metering) untuk menghemat biaya
    • Menyediakan URL HTTPS melalui koneksi jaringan Anycast
    • Menjaga persistensi penuh dan tetap ada sampai dihapus secara eksplisit

Claude dan batasan container stateless

  • Saat ini sebagian besar lingkungan cloud berpusat pada arsitektur container stateless
    • Data hanya disimpan di DB eksternal, dengan tujuan menjaga kesederhanaan dan skalabilitas
  • Namun agen AI seperti Claude tidak cocok dengan struktur ini
    • Mereka cenderung berusaha mengakali atau keluar dari container, karena menginginkan akses ke seluruh “komputer”
  • Definisi “komputer” yang diajukan adalah durability dan lingkungan yang tidak hilang setelah pekerjaan selesai
    • Sandbox saat ini tidak memiliki kedua hal tersebut

Kesederhanaan menang (Simple Wins)

  • Dalam lingkungan persisten, membangun ulang lingkungan pengembangan (seperti node_modules) tidak lagi diperlukan
    • Industri saat ini menginvestasikan puluhan juta dolar ke teknologi snapshot untuk mengatasi masalah ini
  • Ada contoh infrastruktur nyata yang dibuat agar agen dapat mengakses resource eksternal seperti S3, Redis, RDS
    • Ini hanyalah solusi sementara untuk mengakali masalah non-persisten pada sandbox
  • Sprite menghapus kompleksitas ini dan menyediakan lingkungan tempat file yang ditulis akan tetap tersimpan
  • Sebagai contoh, dalam proyek Phoenix.new, agen berbasis Fly Machine mengamati log aplikasi secara langsung lalu memperbaiki error

Galaxy Brain Win: peleburan pengembangan dan operasi

  • Penulis bersama Claude membangun aplikasi Go berbasis SQLite (MDM) di atas Sprite
    • Digunakan sebagai URL pendaftaran MDM melalui URL Anycast
    • Claude bahkan otomatis menangani konfigurasi sertifikat APNS
  • Aplikasi ini telah berjalan stabil di atas Sprite selama lebih dari sebulan
    • Ini mewujudkan konsep “lingkungan pengembangan adalah lingkungan produksi (dev is prod, prod is dev)”
  • Penulis berargumen bahwa sebagian besar aplikasi tidak membutuhkan traffic besar, dan aplikasi persisten yang dipersonalisasi justru lebih penting
    • Struktur yang memungkinkan pengguna langsung meminta fitur lalu segera diterapkan

Akhir era sandbox dan datangnya era komputer sekali panggil

  • Fly.io telah lama mengembangkan platform micro VM yang diskalakan secara horizontal, tetapi model sandbox kini telah mencapai batasnya
  • Sprite mirip dengan Fly Machines, tetapi memakai storage stack dan struktur orkestrasi baru, serta tidak memerlukan Dockerfile
  • Pertanyaan inti yang diajukan:
    > “Jika Anda bisa menjalankan agen, bukankah Anda lebih menginginkan instance EC2 yang bisa langsung dipanggil daripada sandbox read-only?”
  • Kesimpulan: “Era sandbox telah berakhir, dan era komputer sekali panggil telah dimulai.”

Bacaan terkait

1 komentar

 
GN⁺ 2026-01-11
Komentar Hacker News

  • Awalnya saya benar-benar suka, tetapi seperti pengalaman lain saat memakai Fly API, kali ini juga terasa ada yang rusak
    Jika menjalankan contoh perintah di dokumentasi https://sprites.dev/api apa adanya, respons yang muncul adalah {"error":"name is required"}
    Namun, jika memakai seluruh body request dari dokumentasi Create Sprite, semuanya berjalan normal
    Untuk workflow pribadi, mungkin saya masih bisa menerima bagian-bagian yang kasar seperti ini, tetapi untuk CI/CD yang berdampak ke seluruh tim, saya jadi ragu
    Saya ingin meminta tim Fly — tolong pastikan contoh di dokumentasi selalu diverifikasi dengan automasi pengujian

    • Mungkin karena header Content-Type tidak disertakan
    • Akan bagus jika masalah seperti ini bisa dilaporkan di issue tracker publik. Tidak harus GitHub, tetapi perlu ada ruang agar pengguna bisa berdiskusi secara terbuka

  • https://sprites.dev/ benar-benar menarik
    Ini menyelesaikan dua masalah yang saya sukai sekaligus

    1. Sandbox lingkungan pengembangan — lingkungan VM yang murah dan persisten untuk menjalankan Claude Code atau Codex CLI dengan aman
    2. Sandbox API — kode yang tidak tepercaya bisa dijalankan dalam lingkungan terisolasi hanya dengan panggilan JSON API sederhana
      Ada juga fitur snapshot, jadi setelah dijalankan kita bisa dengan mudah kembali ke keadaan sebelumnya
      Saya merangkum detailnya di blog saya → tulisan simonwillison.net

  • Secara filosofis saya menyukai Fly dan sudah menjadi pelanggan sejak awal
    Tetapi untuk pekerjaan terkait CLI, saya masih merasa takut. Bahkan jika hanya dipakai sekali setiap beberapa minggu, auto-update terlalu sering muncul dan memutus alur kerja
    Saya khawatir Sprite CLI akan mengulangi masalah yang sama

    • Saya juga meninggalkan Fly karena alasan yang sama dan pindah ke Digital Ocean. Katanya “just works”, tetapi terlalu sering justru tidak bekerja

  • Ini benar-benar menarik!
    Di kantor, kami memakai server pengembangan persisten dengan Claude yang terhubung lewat SSH, dan akan merepotkan jika git repo atau lingkungannya hilang
    Dengan Sprite, sepertinya kita bisa menyimpan data dengan sesuatu seperti SQLite, lalu membuat aplikasi sederhana yang diakses lewat URL
    Jika strukturnya otomatis hilang setelah waktu singkat, ini tampak sempurna untuk software pribadi sederhana
    Akan lebih bagus lagi jika ada fitur untuk melihat URL setelah autentikasi akun Fly, seperti lingkungan preview Vercel

  • Kelihatannya keren, tetapi produk-produk Fly lainnya bukan contoh yang baik dari sisi stabilitas atau kematangan
    Downtime API dan error sementara sering terjadi, dan masalah penagihan juga lambat ditangani
    Misalnya, instance yang sudah dihapus masih ditampilkan sebagai sedang dipakai, dan tarif per jam dihitung dua kali lipat dari yang seharusnya
    Mereka memang merilis produk AI baru seperti Phoenix.new dan Sprites, tetapi tampaknya lebih fokus pada produk baru daripada meningkatkan kualitas produk yang sudah ada

    • Kalau hanya melihat keandalan dan dukungan, saya rasa tidak ada alasan untuk memakai ini

  • Saya sudah lama menginginkan sandbox untuk pengembangan seperti ini — lingkungan yang tidak akan memakan biaya besar meski lupa dimatikan
    Namun ada beberapa masalah

    1. Error manpath: can't set the locale — mungkin pengaturan locale lokal ikut diteruskan apa adanya
    2. $SHELL disetel ke /opt/homebrew/bin/fish. Saya agak tidak nyaman karena sepertinya variabel lingkungan lokal terkirim diam-diam ke remote

  • Ini benar-benar keren. Inilah bentuk sandbox runtime dengan DX dan API yang selama ini saya tunggu
    Saya ingin bisa mengustomisasi image dasar atau VM agar hanya berisi binary yang saya butuhkan tanpa tool yang tidak perlu
    Atau akan bagus jika ada fitur untuk menggandakan sprite berdasarkan checkpoint. Saat ini saya belum melihat opsi seperti itu

    • Akan bagus jika ada fungsi seperti deployment Docker, di mana saya bisa mengunggah image sprite dasar sesuai keinginan lalu melanjutkan pekerjaan di atasnya

  • Sangat menyenangkan bekerja pada Sprites selama beberapa bulan terakhir
    Kami akan segera merilis sebagian sisi Elixir sebagai open source
    Ada juga video demo 5 menit → demo YouTube

    • Hal yang menarik adalah Claude mengendalikan Sprites sendiri. Saat server dijalankan, ia otomatis mendaftarkannya sebagai layanan lokal, dan jika ada perubahan besar, ia akan membuat checkpoint sendiri
      Sprite yang tidak dipakai hampir tidak memakan biaya. Setiap kali ada pekerjaan baru, Anda tinggal membuat yang baru saja
      Agak aneh rasanya memiliki lingkungan yang bisa dijalankan kapan saja tanpa perlu mengambil keputusan apa pun

  • Karena domainnya fly.io, awalnya saya mengira ini akan menjadi solusi lokal
    Meski bukan self-hosted, saya sempat berharap ini adalah wrapper VM lokal yang membungkus Docker atau bubblewrap

    • Untuk kebutuhan seperti itu, ada baiknya melihat proyek LXC/Incus → https://linuxcontainers.org/incus/
      Menjalankan IncusOS berbasis ZFS di hardware lokal akan menjadi lingkungan sandbox yang sangat kuat

  • Mungkin saya melewatkannya di dokumentasi, tetapi saya penasaran apakah sprite bisa di-fork/clone atau checkpoint bisa dipulihkan menjadi sprite baru
    Misalnya, saya ingin memakai satu sprite sebagai template untuk menjalankan banyak salinan, atau membiarkan Claude Code mengeksplorasi beberapa solusi lalu menyisakan satu dan membersihkan sisanya

    • Fitur itu akan segera ditambahkan. Minggu depan kami akan menjelaskan alasan dan strukturnya dalam posting “how this works”
      Sebenarnya kami ingin memasukkannya saat peluncuran, tetapi diputuskan untuk lebih dulu mengumpulkan sedikit lebih banyak data penggunaan nyata