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.

Kebutuhan 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. README-nya menyatakan persyaratan tersebut tanpa ambigu: "kotak Linux dengan /dev/kvm", dan lebih tepatnya "Ubuntu 24.04, x86_64 atau arm64, dengan /dev/kvm (bare-metal, atau VM dengan nested virtualization) yang dapat Anda akses melalui root-SSH".

Penyiapan yang didokumentasikan hanya memerlukan satu perintah yang ditujukan ke kotak tersebut:

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

infra/setup.sh menjalankan pemeriksaan awal melalui SSH dan berhenti lebih awal jika kotak 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 pembahasan ini. Installer mengajukan pertanyaan yang sama seperti yang baru saja Anda ajukan dengan ls -l /dev/kvm, dan pada sebagian besar paket VPS, jawabannya juga sama-sama mengecewakan.

Setelah pemeriksaan awal selesai, proses ini menjadi instalasi pada seluruh sistem: Firecracker dan jailer-nya, 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. Daemon kemudian menerima koneksi pada port 8080, dan pemeriksaan kesehatan yang gagal menampilkan /healthz didn't return ok. SKIP_DESKTOP=1 melewati pembuatan image desktop, yang menurut README memerlukan waktu sekitar 8 menit.

Baca catatan penting sebelum menempelkan perintah tersebut

Perintah ini memerlukan akses SSH root pada host baru. Installer menulis paket sistem, unit systemd, dan konfigurasi jaringan sebagai root. Arahkan perintah ini ke mesin yang siap Anda bangun ulang dari awal, bukan ke server yang sudah menjalankan situs Anda.

Daemon mengikat 0.0.0.0:8080 secara default. Siapa pun yang dapat mengakses port tersebut dapat membuat mesin, dan mesin itu menggunakan model key yang Anda berikan kepada installer. Atur NEHEMIAH_TOKEN agar autentikasi diwajibkan, atau atur BIND_LOCALHOST=1 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. Lindungi key tersebut seperti secret lain di server, sebagaimana 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 ini menyatakan bahwa guest berada di balik firewall egress, dan batas isolasinya memang nyata. Guest tetap dapat mengakses jaringan karena itu merupakan bagian dari desainnya. Coding agent yang tidak dapat mengambil paket tidak berguna. Rencanakan hal tersebut, bukan menganggap lingkungan ini sebagai air gap.

Belum ada release yang diberi tag. Per 10 August 2026, repository tersebut sama sekali belum memiliki tag. Karena itu, cloning main akan mengambil apa pun yang masuk ke repository pada pagi itu. Pin ke commit tertentu, lalu baca script tersebut sebelum script 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, jadi perlakukan sebagai software yang masih baru. Baca kembali infra/setup.sh setiap kali Anda mengambil update, karena 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 sumber daya server yang dibutuhkan beberapa microVM?

Setiap microVM menjalankan kernel guest nyata serta memori yang Anda alokasikan, dan memori tersebut digunakan selama mesin berjalan. Karena itu, tentukan ukuran host berdasarkan ukuran guest dan jumlah guest yang ingin Anda jalankan secara bersamaan. Angka di bawah ini merupakan hasil perhitungan, bukan hasil pengukuran. Guest tanpa antarmuka grafis menggunakan 1 GB, sedangkan guest desktop dengan browser menggunakan 2 GB. Host menyisakan 2 GB untuk sistemnya sendiri, daemon, dan pembuatan image.

[
  {
    "label": "1 headless guest",
    "guests": 1,
    "guest_ram_gb": 1,
    "host_ram_gb": 3
  },
  {
    "label": "4 headless guests",
    "guests": 4,
    "guest_ram_gb": 1,
    "host_ram_gb": 6
  },
  {
    "label": "4 desktop guests",
    "guests": 4,
    "guest_ram_gb": 2,
    "host_ram_gb": 10
  },
  {
    "label": "8 desktop guests",
    "guests": 8,
    "guest_ram_gb": 2,
    "host_ram_gb": 18
  }
]

Satu mesin tanpa antarmuka grafis memerlukan sekitar 3 GB, yang dapat ditangani VPS kelas menengah jika menyediakan KVM. Empat mesin memerlukan 6 GB. Jalankan 8 mesin desktop, dan perhitungan yang sama memerlukan 18 GB sebelum Anda menghitung kebutuhan disk sedikit pun.

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

Inilah alasan jawaban yang jujur untuk pertanyaan "VPS mana yang dapat menjalankan Firecracker" sering kali adalah "kelas mesin yang berbeda". Bare metal menyediakan CPU flags tanpa hypervisor yang menghalangi, dan itulah kompromi dalam memilih antara VPS dan server dedicated. Beberapa provider memang menyediakan nested virtualisation pada paket virtual, dan nested virtualisation pada VPS menjelaskan cara memastikannya sebelum Anda membayar. Jika hardware tersebut sudah Anda miliki, Proxmox dibandingkan VPS biasa mengajukan pertanyaan yang sama dari sisi hypervisor.

Server juga merupakan bagian yang lebih murah. Setiap mesin yang Anda serahkan kepada agent menggunakan token model selama mesin tersebut berjalan. Karena itu, microVM yang idle tetap menggunakan memori, sedangkan microVM yang sibuk menggunakan memori dan biaya API. Paket 1 GB tidak dapat menampung host. Paket yang dapat menampung host tetap tidak akan membayar kunci tersebut.

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 dengan 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 pada modul kernel milik hypervisor, lalu diteruskan kepada Anda sebagai flag CPU pada prosesor virtual yang diberikan kepada Anda. 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 level kernel dapat mencapai host. Namun, container sekali pakai 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 tanpa antarmuka grafis dengan 1 GB dan cadangan host sebesar 2 GB memerlukan total sekitar 3 GB, sedangkan 8 guest desktop dengan masing-masing 2 GB memerlukan sekitar 18 GB. Disk merupakan kebutuhan terpisah yang mudah diremehkan karena host menyimpan kernel, root filesystem, satu image untuk setiap varian guest, dan satu snapshot untuk setiap mesin yang sedang berjalan.