VPS Sunucum Firecracker microVM Destekliyor mu?

VPS sunucunuz Firecracker microVM çalıştırabilir mi?

VPS sunucunuz, yalnızca /dev/kvm sağlıyorsa Firecracker microVM çalıştırabilir. Firecracker, Linux içindeki sanallaştırma katmanı olan KVM (kernel-based virtual machine) üzerine inşa edilmiş bir VMM'dir (sanal makine monitörü) ve KVM, CPU'dan sanallaştırma komutlarına ihtiyaç duyar. Bir VPS üzerinde bu komutları yalnızca sağlayıcı bunları konuk sisteminize aktardığında alırsınız; çoğu plan bunu yapmaz.

Bu nedenle ilk soru, hangi microVM aracının kurulacağı değildir. Asıl soru, halihazırda ödeme yaptığınız makinenin bunu barındırıp barındıramayacağıdır. Bu bir barındırma sorusudur ve cevabını yaklaşık bir dakika içinde bulabilirsiniz.

Kurulumdan önce /dev/kvm dizinini kontrol edin

VPS üzerinde şu üç komutu çalıştırın.

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

MicroVM barındırabilen bir sunucu şu şekilde yanıt verir:

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

İlk satır, kvm grubuna ait olan KVM aygıt düğümüdür. İkinci satır, bu makinenin kendisinin KVM altında çalışan bir konuk olduğunu belirtir; bu durum bir VPS üzerinde normal ve beklenen bir davranıştır. Üçüncü satır, donanım sanallaştırma bayrağını bildiren CPU çekirdeklerini sayar; bu bayrak Intel üzerinde vmx, AMD üzerinde ise svm olarak görünür. Bir konuk sistem içerisinde sıfırdan büyük bir değer, hipervizörün size iç içe sanallaştırma (nested virtualisation) sunduğu anlamına gelir.

Ardından kullanıcınızın aygıtı açabildiğini doğrulayın. Bu, Firecracker'ın kendi başlangıç dokümanında yer alan testtir:

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

Düğüm mevcut olduğu halde FAIL hatası alıyorsanız, bu bir donanım sorunu değil, bir izin sorunudur. sudo setfacl -m u:${USER}:rw /dev/kvm komutu ile kendi kullanıcınıza erişim izni verin veya sudo usermod -aG kvm ${USER} komutu ile kendinizi gruba ekleyip tekrar giriş yapın.

Ubuntu, tüm bu kontrolleri iki satırlık bir çıktıda özetleyen bir araçla gelir:

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

Çalışan bir ana makine INFO: /dev/kvm exists ve ardından KVM acceleration can be used çıktısını verir. Çalışmayan bir ana makine ise INFO: Your CPU does not support KVM extensions ve ardından KVM acceleration can NOT be used çıktısını verir. Fiziksel bir makinede bunun yerine INFO: KVM (vmx) is disabled by your BIOS mesajını görebilirsiniz; bu durum donanım yazılımı (firmware) üzerinden düzeltilebilir. Bir VPS üzerinde bu mesaj nadiren görülür, çünkü gerçek bir donanım yazılımı ile etkileşimde değilsinizdir.

Her /dev/kvm yanıtı ne anlama gelir?

Düğüm mevcuttur ve bayrak sayısı sıfırdan büyüktür. Donanım sanallaştırmasına sahipsiniz, bu nedenle Firecracker çalışacaktır. Boyutlandırma bölümüne geçin, çünkü temel kısıtlamanız CPU özelliklerinden ziyade bellek miktarıdır.

Düğüm yok, systemd-detect-virt komutu kvm veya qemu çıktısını veriyor ve bayrak sayısı 0. VPS'niz, ana makinenin sanallaştırma yetkisini aktarmadığı bir sanal makinedir. Konuk sistem içine kuracağınız hiçbir şey bunu değiştirmez, çünkü bayrak, hipervizörün sizin için oluşturduğu sanal CPU'nun bir özelliğidir. sudo modprobe kvm_intel komutu modprobe: ERROR: could not insert 'kvm_intel': Operation not supported hatasıyla başarısız olur ve sudo dmesg | grep -i kvm eksik donanım desteğini kaydeder. Paylaşımlı VPS planlarında bu yaygın bir durumdur. Sağlayıcınıza planın iç içe sanallaştırmayı (nested virtualisation) destekleyip desteklemediğini sorun. Yanıt hayır ise, farklı bir komuta değil, farklı bir barındırma hizmetine ihtiyacınız vardır.

systemd-detect-virt komutu lxc, lxc-libvirt veya openvz çıktısını veriyor. Planınız konteyner sanallaştırmasıdır, bu nedenle ana makinenin çekirdeğini paylaşıyorsunuz. /dev/kvm hiçbir zaman görünmeyecektir, çünkü içine modül yükleyebileceğiniz kendi çekirdeğiniz yoktur. Hiçbir paket bunu düzeltemez.

Bayraklar mevcut ancak düğüm yok. Modül sadece yüklenmemiştir. sudo modprobe kvm_intel (veya AMD üzerinde kvm_amd) komutunu çalıştırın ve ls -l /dev/kvm dosyasını tekrar kontrol edin. Düğüm görünürse, yeniden başlatma sonrasında da kalıcı olması için modül adını /etc/modules-load.d/kvm.conf dosyasına yazın.

arm64 mimarisindesiniz. vmx ve svm x86 isimleridir, bu nedenle grep sayısı her arm64 makinesinde, çalışsa da çalışmasa da 0'dır. arm64 üzerinde cihaz düğümüne ve okuma/yazma testine güvenin.

Ajan çalışmaları için neden container yerine microVM

Container, kernel üzerinde çalışan ve namespaces ile cgroups tarafından sınırlandırılmış bir süreçtir. Tek bir kernel vardır ve bu kernel size aittir; dolayısıyla kernel seviyesinde bir kaçış doğrudan host sistemine erişim sağlar. Bir microVM ise donanım sanallaştırma sınırı içerisinde kendi kernel'ını başlatır ve host sisteminizin tüm sistem çağrısı yüzeyi yerine küçük, emüle edilmiş bir cihaz modeliyle iletişim kurar. Firecracker, bu modeli kasıtlı olarak küçük tutar; tasarımın temel amacı budur: daha az emüle edilmiş cihaz, dışarı çıkmak için daha az yol demektir.

Bu fark, kod yazan bir ajan için önemlidir çünkü ajanın çalıştırdığı kod, daha önce kimsenin okumadığı bir koddur. Paketler kurar, derleme betikleri çalıştırır ve bir şeyler başarısız olduğunda makine hızında tekrar dener. Ayrı bir kernel, hatalı bir adımın yalnızca silebileceğiniz bir makineye zarar vermesi ve başka hiçbir şeyi etkilememesi anlamına gelir.

Gereksinim, doğrudan mekanizmadan kaynaklanır. Donanım izolasyonu, donanım sanallaştırmasına ihtiyaç duyar ve donanım sanallaştırması, VPS planınızın size sunmayabileceği bir özelliktir. Container ise buna ihtiyaç duymaz; bu yüzden container'lar satılan her planda çalışır.

Dolayısıyla /dev/kvm eksik olduğunda, container tabanlı kodlama ajanları için tek kullanımlık VM doğru cevap olmaya devam eder ve bu bir teselli ödülü değil, gerçek bir kontrol mekanizmasıdır. Önem verdiğiniz hiçbir kimlik bilgisini barındırmayan bir host üzerinde çalışan, hatalı davrandığında snapshot üzerinden geri yüklenen tek kullanımlık bir container, gerçekte ters giden durumların çoğunu engeller. Aynı durum bir VPS üzerinde kodlama ajanı çalıştırma içindeki daha sade kurulum için de geçerlidir. Bir ajan saatlerce gözetimsiz çalışacaksa, incelemediğiniz kodları işleyecekse ve host sistemi tamamen sizin kontrolünüzdeyse microVM tercih edin.

Bir microVM aracısı ana makineden ne talep eder

Nehemiah, bu sınıfın güncel bir örneğidir: talep üzerine bir yapay zekaya gerçek bir Linux makinesi, makine başına bir Firecracker microVM sağlayan Apache-2.0 lisanslı bir daemon. README dosyası gereksinimi net bir şekilde belirtir: "/dev/kvm içeren bir Linux kutusu" ve daha kesin bir ifadeyle "root-SSH erişimine sahip, /dev/kvm (bare-metal veya iç içe sanallaştırma destekli bir VM) içeren Ubuntu 24.04, x86_64 veya arm64".

Belgelenen kurulum, bu kutuya yönelik tek bir komuttan ibarettir:

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, SSH üzerinden bir ön kontrol (preflight) gerçekleştirir ve kutu uygun olmadığında işlemi erkenden durdurur. Donanımla ilgili iki ret mesajı şöyledir:

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

Bu ilk metin dizisi, bu yazının temel konusudur. Yükleyici, sizin ls -l /dev/kvm ile sorduğunuz sorunun aynısını sorar ve çoğu VPS planında aynı hayal kırıklığı yaratan yanıtı alır.

Ön kontrol geçildikten sonra kurulum tüm kutuyu kapsar: Firecracker ve jailer'ı, bir Go araç zinciri, bir konuk çekirdeği ve kök dosya sistemi, bir Python konuk imajı, tarayıcı içeren isteğe bağlı bir masaüstü imajı ve nehemiahd.service ile boring-net.service adında iki systemd birimi. Daemon daha sonra 8080 numaralı port üzerinden yanıt verir ve başarısız bir sağlık kontrolü /healthz didn't return ok çıktısını üretir. SKIP_DESKTOP=1, README dosyasında oluşturulmasının yaklaşık 8 dakika sürdüğü belirtilen masaüstü imajını atlar.

Komutu yapıştırmadan önce uyarıları okuyun

Yeni bir sunucuda root SSH erişimi gerektirir. Yükleyici; sistem paketlerini, systemd birimlerini ve ağ yapılandırmasını root yetkileriyle yazar. Bu aracı, halihazırda sitenizi barındıran bir sunucuda değil, sıfırdan yeniden kurmayı göze aldığınız bir makinede çalıştırın.

Daemon varsayılan olarak 0.0.0.0:8080 portunu dinler. Bu porta erişebilen herkes makine oluşturabilir ve bu makineler, yükleyiciye verdiğiniz model anahtarını tüketir. Kimlik doğrulama zorunlu kılmak için NEHEMIAH_TOKEN ayarını yapın veya daemon'ın yalnızca 127.0.0.1 adresini dinlemesini sağlamak için BIND_LOCALHOST=1 ayarını kullanın; ardından servise ssh -N -L 8080:127.0.0.1:8080 root@YOUR_BOX_IP ile bir tünel üzerinden erişin. Bu anahtar, sunucudaki diğer tüm gizli verilerle aynı özeni hak eder; detaylar için bkz: gizli verileri yapay zeka ajanlarından uzak tutmak.

Her makine, internet erişimi olan ve ajanları önceden yüklenmiş bir bilgisayardır. README dosyası, konuk sistem içerisinde node, python ve git'in yanı sıra claude, codex, cursor ve pi araçlarını listeler. Proje, konuk sistemlerin bir çıkış güvenlik duvarı (egress firewall) arkasında yer aldığını ve izolasyon sınırının gerçek olduğunu belirtir. Yine de konuk sistem, tasarım gereği ağa erişebilir; çünkü paket indiremeyen bir kodlama ajanı işlevsizdir. Hava boşluğu (air gap) olduğunu varsaymak yerine, bu durumu planlarınıza dahil edin.

Etiketlenmiş bir sürüm bulunmamaktadır. 10 Ağustos 2026 itibarıyla depoda hiçbir etiket yoktur; bu nedenle main üzerinden klonlama yapmak, o sabah depoya eklenen en güncel kodu almanıza neden olur. Bir commit değerini sabitleyin ve betiği sunucunuzda root yetkisiyle çalıştırmadan önce mutlaka okuyun:

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

Depo Haziran 2026 sonunda oluşturulmuştur, bu nedenle yazılımı yeni olarak değerlendirin. Her güncellemeden sonra infra/setup.sh dosyasını tekrar okuyun; çünkü onayladığınız şey bir kütüphane sürüm güncellemesi değil, bir makineye root erişimi verilmesidir.

KVM'in çalıştığını kurulum aracını suçlamadan önce doğrulayın

Kurulum başarısız olursa ve sorunun KVM kaynaklı olup olmadığını anlamak isterseniz, Firecracker'ı tek başına test edin. Aşağıdaki adımlar upstream indirme işlemlerini içerir:

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

Alınan çıktı, binary dosyasının mimarinizle uyumlu olduğunu ve çalıştığını kanıtlar. Bu, KVM erişimini kanıtlamaz; bu nedenle testi daha önce belirtilen /dev/kvm üzerindeki okuma ve yazma testi ile birlikte gerçekleştirin. Bu iki test, barındırma kaynaklı bir sorunu paketleme kaynaklı bir sorundan ayırır; böylece aslında doğru çalışan bir kurulum aracını hatalı şekilde ayıklamaktan kurtulursunuz.

Birden fazla microVM için ne kadar sunucu kaynağı gerekir?

Her microVM, kendisine atadığınız bellek miktarıyla birlikte gerçek bir konuk çekirdeği barındırır ve bu bellek, makine çalıştığı sürece rezerve edilir. Bu nedenle, sunucu boyutunu konukların boyutuna ve aynı anda çalıştırmak istediğiniz sayıya göre belirleyin. Aşağıdaki rakamlar ölçüm değil, aritmetik hesaplamalardır. Başsız (headless) bir konuk 1 GB, tarayıcı içeren masaüstü bir konuk ise 2 GB bellek kullanır. Sunucu; kendisi, daemon süreci ve imaj derleme işlemleri için sabit 2 GB belleği ayırır.

[
  {
    "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
  }
]

Aynı anda çalışan bir adet başsız makine yaklaşık 3 GB bellek gerektirir; bu miktar, KVM desteği sunan orta ölçekli bir VPS ile karşılanabilir. Dört adet başsız makine 6 GB bellek ister. 8 adet masaüstü makine çalıştırdığınızda, aynı aritmetik hesaplama disk alanını hesaba katmadan önce 18 GB bellek gerektirir.

Disk alanı, kimsenin planlamadığı bir konudur. Sunucu; bir konuk çekirdeği, temel bir kök dosya sistemi, her konuk türü için bir imaj, çalışan her makine için bir snapshot ve tarayıcı içeren masaüstü imajını saklar; bu imajlar arasında en büyük olanı masaüstü imajıdır. README dosyasında disk kullanımıyla ilgili bir rakam verilmemiştir, bu yüzden tahmine güvenmek yerine ilk derleme sırasında df -h / komutunu izleyin.

"Firecracker hangi VPS üzerinde çalışır?" sorusuna verilen dürüst yanıtın genellikle "farklı bir makine sınıfı" olmasının nedeni budur. Bare metal sunucular, araya giren bir hipervizör olmadan CPU bayraklarını doğrudan sunar; VPS ile dedicated sunucu seçimi arasındaki takas da budur. Bazı sağlayıcılar sanal planlarda iç içe sanallaştırma (nested virtualisation) sunar; VPS üzerinde iç içe sanallaştırma rehberi, ödeme yapmadan önce bunu nasıl doğrulayacağınızı açıklar. Donanım zaten size aitse, Proxmox ile standart VPS karşılaştırması hipervizör tarafında sorulan aynı sorudur.

Sunucu maliyeti, denklemin ucuz olan yarısıdır. Bir aracıya (agent) teslim ettiğiniz her makine, çalıştığı sürece model token'ları harcar; dolayısıyla boşta duran bir microVM sadece bellek maliyeti yaratırken, yoğun çalışan bir microVM hem bellek hem de API maliyeti yaratır. 1 GB'lık bir plan sunucuyu barındıramaz. Sunucuyu barındırabilecek bir plan bile anahtar maliyetini karşılamayacaktır.

FAQ

VPS'imin Firecracker çalıştırıp çalıştıramayacağını nasıl kontrol ederim?

VPS üzerinde ls -l /dev/kvm, systemd-detect-virt ve grep -cE '\b(vmx|svm)\b' /proc/cpuinfo komutlarını çalıştırın. kvm grubuna ait bir aygıt düğümü ve sıfırdan büyük bir bayrak sayısı, Firecracker'ın çalışabileceği anlamına gelir. Düğümün eksik olması ve sayacın 0 olması, hipervizörün sanallaştırmayı aktarmadığı anlamına gelir; bu durum cpu-checker paketindeki sudo kvm-ok aracı ile KVM acceleration can NOT be used çıktısı alınarak doğrulanabilir. arm64 mimarisinde sayacı dikkate almayın, çünkü vmx ve svm x86'ya özgü isimlerdir.

VPS'imin içinden iç içe sanallaştırmayı (nested virtualisation) etkinleştirebilir miyim?

Hayır. İç içe sanallaştırma, ana makine (host) tarafından, hipervizörün kendi çekirdek modülünde açılır ve size sanal işlemci üzerinde bir CPU bayrağı olarak ulaşır. Konuk (guest) sistemin içinde sudo modprobe kvm_intel komutu, sanal CPU'nun kullanabileceği bir VMX bulunmadığı için modprobe: ERROR: could not insert 'kvm_intel': Operation not supported çıktısını verir. Seçenekleriniz, planında iç içe sanallaştırma sunan bir sağlayıcı ile çalışmak veya hipervizörün sahibi olduğunuz bir makine kullanmaktır.

Bir kodlama aracını izole etmek için container yeterli midir?

Çoğu zaman evet. Bir container çekirdeğinizi paylaşır, bu nedenle çekirdek seviyesinde bir kaçış ana makineye erişim sağlar; ancak değerli kimlik bilgileri barındırmayan bir makinedeki tek kullanımlık bir container, karşılaştığınız risklerin çoğunu ortadan kaldırır. Bir aracı, incelenmemiş kodlar üzerinde uzun süre boyunca denetimsiz çalıştıracağınızda ve ona /dev/kvm özellikli bir ana makine sağlayabildiğinizde microVM tercih edin. Bunu yapamadığınız durumlarda, her görevden sonra yok ettiğiniz bir container, başlatmayı başaramadığınız bir microVM'den daha iyidir.

Bir microVM aracı ana makinesinin ne kadar RAM'e ihtiyacı vardır?

Konuk boyutundan başlayın. 2 GB ana makine yedeği ile 1 GB boyutunda tek bir başsız (headless) konuk, toplamda yaklaşık 3 GB RAM gerektirir; her biri 2 GB olan 8 adet masaüstü konuk ise yaklaşık 18 GB RAM ister. Disk alanı ayrı bir konudur ve genellikle hafife alınır; çünkü ana makine bir çekirdek, kök dosya sistemleri, her konuk türü için bir imaj ve çalışan her makine için bir anlık görüntü (snapshot) tutar.