Apakah VPS Anda Bisa Menjalankan Firecracker?

Dapatkah VPS Anda menjalankan microVM Firecracker?

VPS Anda hanya dapat menjalankan microVM Firecracker jika menyediakan /dev/kvm. Firecracker adalah VMM (virtual machine monitor) yang dibangun di atas KVM (kernel-based virtual machine), yaitu lapisan virtualisasi di dalam Linux. KVM memerlukan instruksi virtualisasi dari CPU. Pada VPS, instruksi tersebut hanya tersedia jika penyedia meneruskannya ke guest Anda, dan sebagian besar paket tidak menyediakannya.

Jadi, pertanyaan pertama bukan alat microVM yang harus diinstal. Pertanyaannya adalah apakah mesin yang sudah Anda bayar dapat menjadi host untuk microVM. Ini merupakan pertanyaan tentang layanan hosting, dan Anda dapat menjawabnya dalam waktu sekitar satu menit.

Periksa /dev/kvm sebelum menginstal apa pun

Jalankan tiga perintah berikut langsung pada VPS.

ls -l /dev/kvm
systemd-detect-virt
grep -cE '\b(vmx|svm)\b' /proc/cpuinfo

Server yang dapat menjalankan microVM memberikan output seperti ini:

crw-rw---- 1 root kvm 10, 232 Aug 10 09:12 /dev/kvm
kvm
16

Baris pertama adalah node perangkat KVM yang dimiliki oleh grup kvm. Baris kedua menunjukkan bahwa mesin ini sendiri adalah guest yang berjalan di bawah KVM. Kondisi ini normal dan diharapkan pada VPS. Baris ketiga menghitung core CPU yang melaporkan flag virtualisasi perangkat keras, yaitu vmx pada Intel dan svm pada AMD. Jumlah di atas nol di dalam guest berarti hypervisor menyediakan nested virtualisation untuk Anda.

Selanjutnya, periksa apakah user Anda dapat membuka perangkat tersebut. Ini adalah pengujian dari dokumen getting started milik Firecracker:

[ -r /dev/kvm ] && [ -w /dev/kvm ] && echo "OK" || echo "FAIL"

FAIL saat node tersebut ada menunjukkan masalah izin, bukan masalah perangkat keras. Berikan akses kepada user Anda sendiri dengan sudo setfacl -m u:${USER}:rw /dev/kvm, atau tambahkan diri Anda ke grup tersebut dengan sudo usermod -aG kvm ${USER}, lalu login kembali.

Ubuntu juga menyediakan pemeriksaan yang merangkum semua hal ini dalam dua baris output:

sudo apt update && sudo apt install -y cpu-checker msr-tools
sudo kvm-ok

Host yang berfungsi akan mencetak INFO: /dev/kvm exists, lalu KVM acceleration can be used. Host yang tidak dapat digunakan akan mencetak INFO: Your CPU does not support KVM extensions, lalu KVM acceleration can NOT be used. Pada mesin fisik, Anda mungkin melihat INFO: KVM (vmx) is disabled by your BIOS. Kondisi ini dapat diperbaiki di firmware. Pada VPS, pesan tersebut jarang muncul karena Anda tidak mengakses firmware fisik yang sebenarnya.

Apa arti setiap jawaban /dev/kvm?

Node ada dan jumlah flag lebih besar dari nol. Anda memiliki virtualisasi perangkat keras, sehingga Firecracker dapat berjalan. Lanjutkan ke bagian penentuan ukuran, karena batasan yang tersisa adalah memori, bukan fitur CPU.

Tidak ada node, systemd-detect-virt mencetak kvm atau qemu, dan jumlah flag adalah 0. VPS Anda adalah mesin virtual yang host-nya tidak meneruskan dukungan virtualisasi. Tidak ada yang dapat Anda instal di dalam guest untuk mengubahnya, karena flag tersebut merupakan properti CPU virtual yang dibuat hypervisor untuk Anda. sudo modprobe kvm_intel gagal dengan modprobe: ERROR: could not insert 'kvm_intel': Operation not supported, dan sudo dmesg | grep -i kvm mencatat bahwa dukungan perangkat keras tidak tersedia. Ini merupakan kasus umum pada paket VPS bersama. Tanyakan kepada provider apakah paket tersebut mendukung nested virtualisation. Jika tidak, Anda memerlukan hosting yang berbeda, bukan perintah yang berbeda.

systemd-detect-virt mencetak lxc, lxc-libvirt, atau openvz. Paket Anda menggunakan virtualisasi berbasis container, sehingga Anda berbagi kernel milik host. /dev/kvm tidak akan pernah muncul, karena Anda tidak memiliki kernel sendiri untuk memuat module. Tidak ada package yang dapat memperbaikinya.

Flag tersedia, tetapi node tidak ada. Module tersebut hanya belum dimuat. Jalankan sudo modprobe kvm_intel (atau kvm_amd pada AMD), lalu periksa kembali ls -l /dev/kvm. Jika node muncul, tuliskan nama module ke dalam /etc/modules-load.d/kvm.conf agar module tersebut dimuat kembali setelah reboot.

Anda menggunakan arm64. vmx dan svm adalah nama x86, sehingga jumlah grep adalah 0 pada setiap mesin arm64, baik yang berfungsi maupun yang tidak. Pada arm64, gunakan device node serta uji baca dan tulis sebagai acuan.

Mengapa microVM, bukan container, untuk pekerjaan agent

Container adalah proses pada kernel Anda yang dibatasi oleh namespace dan cgroups. Hanya ada satu kernel, dan kernel itu milik Anda. Karena itu, jika terjadi escape pada tingkat kernel, proses tersebut dapat masuk ke host. microVM melakukan boot pada kernel miliknya sendiri di dalam batas virtualisasi perangkat keras. microVM juga berkomunikasi dengan model perangkat yang diemulasikan dan berukuran kecil, bukan dengan seluruh antarmuka system call host. Firecracker sengaja mempertahankan model tersebut tetap kecil. Inilah inti desainnya: semakin sedikit perangkat yang diemulasikan, semakin sedikit jalur untuk keluar.

Perbedaan ini penting bagi coding agent karena kode yang dijalankan agent belum dibaca siapa pun sebelumnya. Agent memasang package, menjalankan build script, dan mengulangi percobaan dengan kecepatan mesin ketika terjadi kegagalan. Kernel terpisah berarti langkah yang salah hanya merusak mesin yang dapat Anda hapus, bukan sistem lain.

Persyaratan ini mengikuti mekanismenya secara langsung. Isolasi perangkat keras memerlukan virtualisasi perangkat keras, dan virtualisasi perangkat keras mungkin tidak tersedia pada paket VPS Anda. Container tidak memerlukan hal tersebut. Karena itu, container dapat berjalan pada setiap paket yang pernah dijual.

Jadi, ketika /dev/kvm tidak tersedia, VM disposable untuk coding agent berbasis container tetap menjadi pilihan yang tepat. Ini adalah kontrol yang nyata, bukan sekadar pengganti sementara. Container throwaway pada host yang tidak menyimpan kredensial penting bagi Anda, lalu dipulihkan dari snapshot setiap kali mengalami masalah, dapat mencegah sebagian besar hal yang benar-benar dapat terjadi. Hal yang sama berlaku untuk setup yang lebih sederhana dalam menjalankan coding agent pada VPS. Gunakan microVM ketika agent akan berjalan tanpa pengawasan selama berjam-jam pada kode yang belum Anda tinjau, dan ketika host tersebut berada di bawah kendali Anda.

Persyaratan host agen microVM

Nehemiah adalah contoh terkini dari kelas ini: daemon berlisensi Apache-2.0 yang menyediakan mesin Linux nyata untuk AI sesuai permintaan, dengan satu microVM Firecracker untuk setiap mesin. Pada 10 August 2026, README-nya menyatakan persyaratan tersebut secara tegas: "a Linux box with /dev/kvm", dan lebih tepatnya "Ubuntu 24.04, x86_64 or arm64, with /dev/kvm (bare-metal, or a VM with nested virtualization) that you can root-SSH into".

Persyaratan tersebut kemudian berubah. Pada 11 August 2026, proyek ini mengganti dokumentasi penyiapan mandiri dengan runbook untuk host terkelola. README yang diperiksa pada 11 October 2026 tidak lagi memuat baris persyaratan tersebut atau instalasi satu perintah. Host kini disediakan dari artefak rilis bertanda tangan ke server bare-metal Latitude.sh dengan infra/latitude/provision.sh. Ini adalah proses manual yang dijalankan operator untuk host yang telah disetujui, lalu control plane proyek mendaftarkan host tersebut. Canary dalam runbook tetap menolak host tanpa /dev/kvm yang dapat digunakan, sehingga persyaratan tersebut tidak dihapus. Persyaratan itu dipindahkan ke bare metal.

Sebelum perubahan tersebut, penyiapan yang didokumentasikan hanya memerlukan satu perintah yang ditujukan ke mesin itu:

git clone https://github.com/boringcomputers/nehemiah
cd nehemiah && npm install
NEHEMIAH_ANTHROPIC_KEY=sk-ant-... ./infra/setup.sh root@YOUR_BOX_IP

Pada main saat ini, perintah tersebut tidak lagi menginstal apa pun. infra/setup.sh ditandai sebagai descoped dan berhenti pada langkah pertama dengan pesan bahwa bootstrap mandiri tidak lagi didukung, sebelum langkah preflight atau instalasi apa pun dijalankan. README menyatakan bahwa installer mandiri sebelumnya kini berhenti dan menampilkan rujukan ke runbook terkelola.

Pada commit yang menjadi dasar penulisan awal artikel ini, infra/setup.sh menjalankan preflight melalui SSH dan berhenti lebih awal jika mesin tersebut tidak memenuhi persyaratan. Dua pesan penolakan perangkat kerasnya adalah:

/dev/kvm missing — the box needs hardware/nested virtualization
box arch is ${ARCH}; nehemiahd needs x86_64 or aarch64

String pertama itulah inti artikel ini. Installer mengajukan pertanyaan yang sama seperti yang baru saja Anda ajukan dengan ls -l /dev/kvm, dan pada sebagian besar paket VPS jawabannya sama-sama mengecewakan. Runbook terkelola juga mengajukan pertanyaan tersebut.

Setelah preflight, prosesnya menginstal seluruh komponen pada mesin: Firecracker dan jailer, toolchain Go, kernel guest dan root filesystem, image guest Python, image desktop opsional dengan browser, serta dua unit systemd bernama nehemiahd.service dan boring-net.service. Pemeriksaan kesehatan yang gagal menampilkan /healthz didn't return ok, sedangkan SKIP_DESKTOP=1 melewati image desktop, yang menurut README pada tanggal tersebut memerlukan waktu sekitar 8 menit untuk dibuat. Tidak satu pun langkah, pesan, atau opsi tersebut dijalankan dari main saat ini. Daemon itu sendiri tetap menerima koneksi pada port 8080 secara default.

Baca catatan penting sebelum menempelkan perintah tersebut

Perintah itu memerlukan akses SSH sebagai root pada host baru. Installer mandiri menulis paket sistem, unit systemd, dan konfigurasi jaringan sebagai root. Jika Anda tetap menjalankan commit yang tidak didukung tersebut, arahkan ke mesin yang siap Anda bangun ulang dari nol, bukan ke server yang sudah menjalankan situs Anda.

Daemon mengikat 0.0.0.0:8080 secara default. Siapa pun yang dapat menjangkau port tersebut dapat membuat mesin, dan mesin itu akan menggunakan model key yang Anda berikan kepada host. Atur NEHEMIAH_TOKEN untuk mewajibkan autentikasi, atau atur NEHEMIAH_ADDR=127.0.0.1:8080 (daemon juga menerima -addr 127.0.0.1:8080) agar daemon hanya mengikat 127.0.0.1, lalu akses melalui tunnel dengan ssh -N -L 8080:127.0.0.1:8080 root@YOUR_BOX_IP. Opsi BIND_LOCALHOST=1 milik installer lama tidak dibaca oleh daemon, sehingga tidak berpengaruh di luar script tersebut. Perlakukan key ini dengan kehati-hatian yang sama seperti secret lain di mesin, seperti yang dijelaskan dalam menyimpan secret di luar AI agent.

Setiap mesin adalah komputer dengan akses Internet dan agent yang sudah terpasang. README mencantumkan claude, codex, cursor, dan pi di dalam guest, bersama node, python, dan git. Proyek tersebut menyatakan bahwa guest berada di balik firewall egress, dan batas isolasinya memang nyata. Guest tetap dapat mengakses jaringan sesuai desain, karena coding agent yang tidak dapat mengambil paket tidak berguna. Rencanakan hal tersebut. Jangan berasumsi bahwa sistem ini memiliki air gap.

Belum ada release bertag. Per 11 October 2026, repository tersebut tidak memiliki tag maupun release. Jadi, cloning main akan mengambil apa pun yang masuk ke repository pada pagi itu, dan saat ini isinya adalah kode khusus untuk deployment terkelola. Tetapkan commit secara eksplisit. Commit di bawah ini adalah commit yang digunakan saat artikel ini ditulis pada 10 August 2026, sehari sebelum installer mandiri ditarik, sehingga infra/setup.sh masih dapat melakukan instalasi. Proyek tersebut tidak lagi mendukung jalur itu. Jadi, baca script sebelum script tersebut dijalankan sebagai root di server Anda:

git clone https://github.com/boringcomputers/nehemiah
cd nehemiah
git checkout ae743fd5c05aecb6ae4bb52bac6bce198b01ebaa
less infra/setup.sh

Repository tersebut dibuat pada akhir June 2026 dan menarik instalasi mandirinya enam minggu kemudian. Jadi, perlakukan sebagai software yang masih baru dan jalur yang didukungnya dapat berubah sewaktu-waktu. Sebelum mengambil versi yang lebih baru, baca kembali README dan runbook. Hal yang Anda setujui adalah akses root ke sebuah mesin, bukan sekadar pembaruan versi library.

Buktikan KVM berfungsi sebelum menyalahkan installer

Jika penyiapan gagal dan Anda ingin mengetahui apakah KVM penyebabnya, uji Firecracker secara terpisah. Berikut langkah pengunduhan dari upstream:

ARCH="$(uname -m)"
release_url="https://github.com/firecracker-microvm/firecracker/releases"
latest=$(basename $(curl -fsSLI -o /dev/null -w %{url_effective} ${release_url}/latest))
curl -L ${release_url}/download/${latest}/firecracker-${latest}-${ARCH}.tgz | tar -xz
./release-${latest}-${ARCH}/firecracker-${latest}-${ARCH} --version

Versi yang ditampilkan membuktikan bahwa binary sesuai dengan arsitektur Anda dan dapat dijalankan. Namun, hal itu tidak membuktikan akses ke KVM. Karena itu, lakukan juga pengujian baca dan tulis pada /dev/kvm yang dijelaskan sebelumnya. Kedua pengujian ini membedakan masalah hosting dari masalah packaging. Dengan demikian, Anda tidak perlu men-debug installer yang sebenarnya sudah bekerja dengan benar.

Berapa kapasitas server yang diperlukan beberapa microVM?

Setiap microVM menjalankan kernel guest yang sebenarnya serta memori yang Anda alokasikan, dan memori tersebut digunakan selama mesin berjalan. Karena itu, tentukan ukuran host berdasarkan ukuran guest dan jumlah mesin yang ingin dijalankan secara bersamaan. Angka di bawah ini adalah hasil perhitungan, bukan hasil pengukuran. Guest tanpa antarmuka grafis memerlukan 1 GB, sedangkan guest desktop dengan browser memerlukan 2 GB. Host menyisihkan 3 GB untuk sistem, daemon, dan pembuatan image. Ini adalah reserve default daemon (NEHEMIAH_MEM_RESERVE_MB, 3072 MB). Daemon menolak mem-boot mesin baru jika mesin tersebut akan mengurangi reserve itu. Jadi, host yang terlalu kecil mencapai batas kapasitas, bukan kehabisan memori.

[
  {
    "label": "1 headless guest",
    "guests": 1,
    "guest_ram_gb": 1,
    "host_ram_gb": 4
  },
  {
    "label": "4 headless guests",
    "guests": 4,
    "guest_ram_gb": 1,
    "host_ram_gb": 7
  },
  {
    "label": "4 desktop guests",
    "guests": 4,
    "guest_ram_gb": 2,
    "host_ram_gb": 11
  },
  {
    "label": "8 desktop guests",
    "guests": 8,
    "guest_ram_gb": 2,
    "host_ram_gb": 19
  }
]

Satu mesin tanpa antarmuka grafis memerlukan sekitar 4 GB. Kapasitas ini dapat ditangani VPS kelas menengah jika VPS tersebut menyediakan KVM. Empat mesin memerlukan 7 GB. Jika Anda menjalankan 8 mesin desktop, perhitungan yang sama memerlukan 19 GB sebelum memperhitungkan satu gigabyte disk pun.

Disk adalah kebutuhan yang sering tidak diperhitungkan. Host menyimpan kernel guest, root filesystem dasar, satu image untuk setiap jenis guest, dan satu snapshot untuk setiap mesin yang sedang berjalan. Image desktop dengan browser adalah image yang paling besar. README tidak mencantumkan kapasitas disk, jadi pantau df -h / selama pembuatan pertama, bukan mengandalkan perkiraan.

Karena itu, jawaban yang jujur untuk pertanyaan "VPS mana yang dapat menjalankan Firecracker" sering kali adalah "kelas mesin yang berbeda". Bare metal menyediakan CPU flags tanpa perantara hypervisor. Inilah trade-off dalam memilih antara VPS dan dedicated server. Beberapa provider memang menyediakan nested virtualisation pada paket virtual. Nested virtualisation pada VPS menjelaskan cara memastikannya sebelum Anda membayar. Jika hardware tersebut sudah menjadi milik Anda, Proxmox dibandingkan dengan VPS biasa membahas pertanyaan yang sama dari sisi hypervisor.

Server juga hanya mencakup sebagian biaya. Setiap mesin yang Anda serahkan kepada agent menggunakan token model selama mesin tersebut berjalan. Jadi, microVM yang idle tetap menggunakan memori, sedangkan microVM yang sibuk menggunakan memori dan biaya API. Paket 1 GB tidak dapat menampung host. Paket yang mampu menampung host tetap belum tentu mampu membayar key.

FAQ

Bagaimana cara memeriksa apakah VPS saya dapat menjalankan Firecracker?

Jalankan ls -l /dev/kvm, systemd-detect-virt, dan grep -cE '\b(vmx|svm)\b' /proc/cpuinfo pada VPS. Node perangkat yang dimiliki oleh grup kvm, disertai jumlah flag di atas nol, berarti Firecracker dapat berjalan. Node yang tidak ada dengan jumlah 0 berarti hypervisor tidak meneruskan virtualisasi, dan sudo kvm-ok dari paket cpu-checker mengonfirmasinya melalui KVM acceleration can NOT be used. Pada arm64, abaikan jumlah tersebut karena vmx dan svm adalah nama untuk x86.

Apakah saya dapat mengaktifkan virtualisasi bertingkat dari dalam VPS?

Tidak. Virtualisasi bertingkat diaktifkan oleh host, di modul kernel milik hypervisor, lalu diteruskan kepada Anda sebagai flag CPU pada prosesor virtual yang diberikan. Di dalam guest, sudo modprobe kvm_intel mengembalikan modprobe: ERROR: could not insert 'kvm_intel': Operation not supported karena CPU virtual tersebut tidak memiliki VMX untuk digunakan. Pilihan Anda adalah menggunakan provider yang menawarkan virtualisasi bertingkat pada paketnya, atau menggunakan mesin yang hypervisornya Anda miliki sendiri.

Apakah container cukup untuk melakukan sandbox pada coding agent?

Sering kali ya. Container menggunakan kernel yang sama dengan host, sehingga escape pada tingkat kernel dapat mencapai host. Namun, container yang dapat dibuang pada mesin yang tidak menyimpan kredensial penting menghilangkan sebagian besar risiko yang benar-benar Anda hadapi. Pilih microVM ketika agent berjalan tanpa pengawasan dalam waktu lama terhadap kode yang belum ditinjau, dan ketika Anda dapat memberinya host dengan /dev/kvm. Jika tidak dapat melakukannya, container yang Anda hapus setelah setiap tugas lebih baik daripada microVM yang tidak pernah berhasil Anda boot.

Berapa banyak RAM yang diperlukan host agent microVM?

Mulailah dari ukuran guest. Satu guest headless dengan ukuran 1 GB dan cadangan host sebesar 3 GB memerlukan total sekitar 4 GB, sedangkan 8 guest desktop dengan ukuran masing-masing 2 GB memerlukan sekitar 19 GB. Kebutuhan disk terpisah dan mudah diremehkan karena host menyimpan kernel, root filesystem, satu image untuk setiap varian guest, serta satu snapshot untuk setiap mesin yang sedang berjalan.