ARM VPS ve x86 VPS Arasındaki Farklar Nelerdir?

ARM VPS'e geçişte neler değişir

Bir ARM VPS, x86 VPS ile aynı Linux dağıtımını ve aynı Nginx sürümünü çalıştırır; genellikle çekirdek başına maliyeti daha düşüktür. Geçişteki risk uyumluluktur. x86-64 mimarisi için derlenmiş bir program arm64 üzerinde kesinlikle çalışamaz; bu nedenle yazılım yığınınızdaki her bileşenin bir arm64 sürümü olmalı ya da yeniden derlenebilir olmalıdır.

Modern yazılım yığınlarının çoğu bu testi sorunsuz geçer. Hatalar genellikle iki noktada yoğunlaşır: yalnızca tek bir mimari için oluşturulmuş container imajları ve arm64 sürümü bulunmayan kapalı kaynak kodlu yazılımlar. Aşağıdaki komutlar, bir sunucu için ödeme yapmadan önce kendi yığınınızın bu iki soruya yanıt verip vermediğini kontrol etmenizi sağlar. Hangi tür sunucuya ihtiyacınız olduğunu belirlemeye çalışıyorsanız, VPS nedir ve paylaşımlı hostingden farkı nelerdir konusuna göz atarak başlayın.

arm64, aarch64, amd64: hangi isim ne anlama gelir

Herhangi bir işlem yapmadan önce bunları her örnekte çalıştırın.

uname -m
dpkg --print-architecture
lscpu | head -n 12
getconf PAGESIZE

uname -m komutu, ARM makinede aarch64, Intel veya AMD makinede ise x86_64 çıktısını verir. dpkg --print-architecture komutu ise aynı iki makine için sırasıyla arm64 ve amd64 çıktısını üretir. Her iki yanıt da doğrudur. Linux çekirdeği ve Debian paketleme sistemi, aynı komut seti için farklı isimler seçmiştir; bu nedenle aarch64 ve arm64 bir şeyi, x86_64 ve amd64 ise diğerini ifade eder. Docker, Debian tarzı isimlendirmeyi kullanır; bu yüzden bir imaj platformu linux/arm64 olarak okunur.

arm64 üzerinde /proc/cpuinfo dosyasında model name satırı bulunmaz. Bunun yerine bir Features alanı alırsınız ve donanımsal şifreleme burada aes pmull sha1 sha2 gibi bayraklar olarak görünür. Bunlar ARMv8 Kriptografik Uzantılarıdır ve Intel ile AMD parçalarında AES-NI'nin yaptığı işi yaparlar: TLS (taşıma katmanı güvenliği) ve disk şifreleme işlemlerini donanım seviyesinde hızlandırırlar. Bir VPS üzerinde AES donanım hızlandırmasını kontrol etme konusu, her iki mimari üzerindeki testi de kapsamaktadır.

Konteynerler neden ilk aşamada hata verir ve hata çıktısı neye benzer

Her Docker imaj manifesti, hangi mimari için oluşturulduğunu kaydeder. Yalnızca amd64 manifestine sahip bir imajı arm64 bir ana makineye çekerseniz, çekme işlemi başarılı olur. Hata, ilk süreç başlatıldığında ortaya çıkar:

WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested
exec /usr/local/bin/docker-entrypoint.sh: exec format error

exec format error, çekirdeğin dosyayı çalıştırmayı reddetmesidir; çünkü ELF (executable and linkable format) başlığı, bu CPU'nun desteklemediği bir makine türünü belirtmektedir. Hiçbir ayar bunu düzeltemez. Talimatlar silikon seviyesinde mevcut değildir.

Dağıtım yapmadan önce manifesti kontrol edin:

docker buildx imagetools inspect nginx:1.27

Çıktı, manifest listesindeki her imaj için Platform: satırını listeler; örneğin linux/amd64 ve linux/arm64 gibi. Eğer linux/arm64 mevcut değilse, o etiket bir ARM VPS üzerinde başlamayacaktır. docker manifest inspect --verbose nginx:1.27 aynı bilgiyi gösterir, ancak Docker docker manifest komutunu davranışları sürümler arasında değişebilen deneysel bir komut olarak tanımlar, bu nedenle imagetools tercih edilmelidir.

Kendi oluşturduğunuz imajlar için her iki mimariyi tek bir komutla oluşturun ve bir manifest listesi gönderin:

docker buildx build --platform linux/amd64,linux/arm64 -t registry.example.com/app:1.4 --push .

Tek bir ana makinede yabancı bir mimari için derleme yapmak, çekirdeğin binfmt_misc işleyicisine kayıtlı QEMU kullanıcı modu emülasyonunu gerektirir:

docker run --privileged --rm tonistiigi/binfmt --install all

Emülasyonu derleme ve test için kullanın. Trafiğe hizmet vermek için kullanmayın. Docker'ın kendi belgeleri, QEMU ile emülasyonun "derleme, sıkıştırma veya sıkıştırma açma gibi yoğun hesaplama gerektiren görevlerde yerel derlemelerden çok daha yavaş olabileceğini" belirtir; bu nedenle bir ARM örneği üzerinde emüle edilen bir x86 servisi, sizi o mimariye geçmeye iten maliyet avantajını ortadan kaldırır. Yerel durum için ana makine kurulumu her iki mimaride de aynıdır: VPS üzerinde Docker çalıştırma konusu bunu kapsar ve içindeki her imajın bir arm64 manifesti olduğu sürece mevcut bir Compose dosyası hiçbir değişiklik yapılmadan çalışır.

İhtiyacım olan paketler arm64 üzerinde mevcut olacak mı?

Ubuntu ve Debian, arşivlerinin neredeyse tamamını arm64 için derler; bu nedenle apt install nginx postgresql redis-server her iki mimaride de aynı şekilde çalışır. Eksiklikler genellikle üçüncü taraf depolarda ortaya çıkar.

ARM örneği üzerinde doğrudan apt'ye sorgu gönderin:

apt-cache policy some-vendor-agent
apt-get install -s some-vendor-agent

apt-cache policy çıktısının Candidate: (none) döndürmesi, etkinleştirilmiş hiçbir deponun bu mimari için söz konusu paketin bir sürümünü yayınlamadığı anlamına gelir. apt-get install -s komutu kurulumu simüle eder ve hiçbir değişiklik yapmaz; aynı durumda işlem E: Unable to locate package ile sona erer.

Ardından, çıktıyı kaydırıp geçmek yerine apt update komutunun çıktısını okuyun. Sadece amd64 destekleyen bir üretici deposu bunu şu şekilde belirtir:

N: Skipping acquire of configured file 'main/binary-arm64/Packages' as repository 'https://repo.example.com/apt stable InRelease' doesn't support architecture 'arm64'

Depo yapılandırılmış ve erişilebilir durumdadır ancak bu makinenin kurabileceği hiçbir içeriğe sahip değildir. Kaynak girişini de kontrol edin. [arch=amd64] ile sabitlenmiş bir satır, arm64 ana bilgisayarında atlanır; bu nedenle asıl neden sabitleme (pinning) olduğu halde paket eksik görünebilir.

Hangi iş yükleri güvenlidir ve hangileri önceden kontrol edilmelidir

Yorumlanan ve bytecode ile çalışan çalışma zamanları (runtime) tasarımları gereği taşınabilirdir. PHP, Python, Ruby ve Node.js'in ana dağıtımlarda arm64 paketleri bulunur. Go ve Rust, tek bir hedef belirlenerek arm64 için çapraz derlenebilir (cross-compile). Bir LEMP yığını, bir Node API, Nginx arkasındaki bir Go binary dosyası veya bir Postgres veritabanı, arm64 üzerinde standart işlerdir.

Tam zamanında (JIT) derleyici, program çalışırken makine kodu üretir; bu nedenle hedef mimari için bir kod üreteci gerektirir. Mevcut sürümlerin (OpenJDK, .NET, Node.js içindeki V8 motoru ve PyPy) tamamı Linux üzerinde arm64 desteğine sahiptir. Sabitlenmiş eski sürümler asıl tehlikeyi oluşturur. Birkaç yıl öncesine ait bir çalışma zamanı sürümünü yükleyen bir dağıtım betiği, çalışacağı varsayılmak yerine, o sürümün aarch64 desteğiyle ilgili notları açısından kontrol edilmelidir.

Elle yazılmış x86 assembly veya SSE ve AVX intrinsics içeren kütüphaneler daha sessiz bir sorundur. Çoğunun bir NEON yolu (NEON, ARM vektör komut setidir) veya düz bir C yedeği bulunur; bu sayede derlenir ve çalışırlar. Performans, x86 derlemesine göre her iki yönde de farklılık gösterebilir. Bunu bir makaleden tahmin etmek yerine kendi örneğiniz üzerinde ölçün.

Kapalı kaynak yazılımlar gerçek engeldir. Bir satıcı izleme ajanı, lisanslı bir veritabanı sürücüsü, ticari bir kontrol paneli veya bir antivirüs daemon'ı derlenmiş bir binary olarak gelir; satıcı bir arm64 derlemesi yayınlamadığında yapabileceğiniz hiçbir şey yoktur. cPanel ve WHM, barındırma hizmetlerinde en net örnektir: sistem gereksinimleri x86_64 belirtir ve ARM listelemez; bu nedenle bir kontrol paneli sunucusu x86 üzerinde kalır (Ağustos 2026 itibarıyla kontrol edilmiştir ve satıcının kendi gereksinimler sayfasından tekrar okunması önerilir). Sizi engelleyen tek şey buysa, VPS üzerinde çalıştırılmaya değer cPanel alternatifleri başlangıç noktasıdır; her birinin mimari desteğini aynı yöntemle kontrol edin.

Çekirdekler ve sayfa boyutu: ARM örneklerinin hala farklılık gösterdiği noktalar

x86-64 sunucular neredeyse birbirinin yerine kullanılabilir durumdadır. ARM sunucular ise daha az standarttır ve farklılıklar uygulamanızın altında yatar.

Sayfa boyutu, üretime etki eden bir konudur. Çoğu arm64 çekirdeği, x86-64 ile aynı olan 4 KiB boyutunda sayfalar kullanır. Bazıları ise 64 KiB kullanır. Red Hat Enterprise Linux 8, aarch64 için varsayılan olarak 64 KiB sayfa boyutuna sahip bir çekirdek ile sunulmuştu; RHEL 9 ise daha büyük boyuta ihtiyaç duyan iş yükleri için ayrı bir kernel-64k paketi tutarak varsayılanı tekrar 4 KiB değerine çekti. 64 KiB sayfa boyutu, çok sayıda küçük eşlemeye sahip bir süreç için bellek tabanını yükseltir; çünkü çekirdeğin verebileceği en küçük parça on altı kat daha büyüktür. Örnek üzerinde getconf PAGESIZE komutunu çalıştırın ve varsayımda bulunmak yerine değeri okuyun.

Bilinmesi gereken birkaç küçük fark daha mevcuttur. arm64 üzerinde işletim sistemi CPU mikro kod paketi bulunmaz, bu nedenle aygıt yazılımı güncellemeleri apt üzerinden değil, sağlayıcınızdan gelir. ARM sunucular UEFI (unified extensible firmware interface) aracılığıyla önyükleme yapar ve donanımlarını ACPI (advanced configuration and power interface) aracılığıyla tanımlar. AMD SEV bellek şifrelemesi ve Intel GVT-g aracılı GPU'lar dahil olmak üzere bazı x86 özelliklerinin ARM tarafında hiçbir karşılığı yoktur.

ARM sunucu platformu olgunlaştı mı?

Yazılım tarafında, evet. Debian, Ubuntu, Fedora ve RHEL artık birinci sınıf arm64 sürümleri yayınlamakta ve Docker Hub üzerindeki resmi imajlar doğal olarak çoklu mimari (multi-arch) desteğiyle sunulmaktadır.

Bunun en net güncel kanıtı Proxmox’tur. 5 Ağustos 2026 tarihinde Proxmox, Proxmox Virtual Environment’ın resmi olarak desteklenen ilk arm64 sürümü olan 9.2’yi duyurmuş; paket depolarını ve sürüm yaşam döngüsünü x86-64 sürümüyle birleştirmiştir. Bu sürüm; Debian 13.5, Linux 7.0, QEMU 11.0, LXC 7.0 ve ZFS 2.4 üzerine inşa edilmiş olup, mimariye özgü küçük bir dizi öğe dışında yapılandırma ve araçlar açısından x86-64 ile aynıdır.

Aynı duyurudaki uyarıları mutlaka okuyun; çünkü bu uyarılar, resmi olarak desteklenen ARM sunucu donanımının hala ne kadar kısıtlı olduğunu göstermektedir. Proxmox, NVIDIA ve Supermicro ile Grace Hopper donanımı üzerinde gerçekleştirilen ortak testlerin ardından, NVIDIA Grace ve NVIDIA Vera sistemlerini ilk günden itibaren doğrulamıştır. Diğer UEFI tabanlı ARMv8-A ve ARMv9-A donanımlar için "en iyi çaba" (best effort) desteği sunulmaktadır. Yalnızca device tree kullanan Raspberry Pi gibi tek kartlı bilgisayarlar desteklenmemektedir. Bir konuk (guest) yalnızca kendi mimarisine sahip bir düğüm üzerinde çalışabilir, canlı taşıma (live migration) yalnızca aynı mimariye sahip düğümler arasında gerçekleşebilir ve karma mimarili kümeler resmi olarak desteklenmemektedir.

Ağustos 2026 itibarıyla durum dürüstçe bu şekildedir. Bir hipervizör sağlayıcısının arm64 sürümünü x86-64 ile aynı yaşam döngüsünde sunması, platform için gerçek bir ilerlemedir. İlk gün desteklenen donanım listesi ise iki CPU ailesinden ibarettir.

Commit öncesi kontrol listesi

1. uname -m komutunu bir deneme örneği üzerinde çalıştırın ve aarch64 çıktısını verdiğini doğrulayın.
2. Compose dosyanızdaki her imaj için docker buildx imagetools inspect komutunu çalıştırın ve her biri için bir linux/arm64 platform satırı olduğunu doğrulayın.
3. ARM örneği üzerinde apt update komutunu çalıştırın ve ekrana yazdırdığı her Skipping acquire uyarısını okuyun.
4. Bağımlı olduğunuz her kapalı kaynak kodlu aracın indirme sayfasını açın ve isim bazında arm64 veya aarch64 yapısı olup olmadığını kontrol edin.
5. Bellek boyutlandırması yapmadan önce getconf PAGESIZE komutunu çalıştırın ve yanıtı not edin.
6. Seçim yapacağınız ARM planı ile x86 planı üzerinde kendi kıyaslama (benchmark) testinizi çalıştırın.

Bu yazının iddia etmedikleri

ARM ve x86 mimarileri arasında bir fiyat/performans oranı sunmuyoruz. Çekirdek başına maliyetler sağlayıcıya ve plana göre değişiklik gösterir; başkasının donanımı üzerinde ölçülen değerler sizin performansınızı öngörmez. Bunun yerine ölçüm yapın. VPS kıyaslama rehberimiz, sysbench ve fio araçlarını tekrarlanabilir bir yöntemle ele almaktadır; bir VPS'in gerçek maliyeti ise karşılaştırmanın fiyatlandırma tarafını açıklamaktadır. Depolama, CPU mimarisinden bağımsız bir karardır ve VPS üzerinde NVMe ile SATA SSD karşılaştırması bu konunun diğer yarısını incelemektedir. Mümkünse kendi iş yükünüzle her iki plan üzerinde de aynı testleri çalıştırın ve kararı rakamlarınıza bırakın.

FAQ

Docker container'larım bir ARM VPS üzerinde çalışır mı?

Stack içindeki her imajın manifest dosyasında bir linux/arm64 girdisi varsa çalışırlar. Her birini docker buildx imagetools inspect <image> ile kontrol edin ve Platform: linux/arm64 satırını arayın. Docker Hub üzerindeki resmi imajlar genellikle çoklu mimari (multi-arch) desteğine sahiptir. Daha küçük sağlayıcılardan gelen imajlar ve x86 bir makinede kendi oluşturduğunuz imajlar genellikle bu desteğe sahip değildir. Kendi imajlarınız için, tek bir etiketin her iki mimariye de hizmet etmesini sağlamak amacıyla docker buildx build --platform linux/amd64,linux/arm64 ... --push ile yeniden derleme yapın.

Bir ARM sunucusunda exec format error ne anlama gelir?

Çekirdek, ELF başlığı farklı bir makine türünü belirten bir binary dosyasını çalıştırmayı denedi ve bunu reddetti. Bir arm64 ana bilgisayarda bu neredeyse her zaman bir x86-64 binary dosyası veya container imajı anlamına gelir. Docker, talep edilen imaj platformunun linux/amd64, algılanan ana bilgisayar platformu olan linux/arm64/v8 ile eşleşmediğini belirten bir uyarı verir. Çözüm, doğru mimari için derleme yapmaktır. Hiçbir yapılandırma değişikliği, bir x86-64 binary dosyasının ARM üzerinde yerel olarak çalışmasını sağlayamaz.

arm64 ile aarch64 aynı şey midir?

Evet. Bunlar 64-bit ARM komut seti için kullanılan iki farklı isimdir. Çekirdek aarch64 üzerinden uname -m raporunu verirken, Debian ve Ubuntu paketleme sistemleri ile Docker platform dizgeleri arm64 ifadesini kullanır. Aynı ayrım diğer tarafta da mevcuttur; burada uname -m ifadesi x86_64 değerini, paketleme ise amd64 değerini belirtir. Eğer bir indirme sayfası yalnızca aarch64 dosyaları sunuyorsa, bunlar dpkg --print-architecture tarafından arm64 olarak adlandırılan bir makine için doğru dosyalardır.

ARM VPS, x86 VPS'ten daha mı hızlıdır?

Bu sorunun genel bir cevabı yoktur ve okuduğunuz herhangi bir oran, sizin donanımınız olmayan bir sistem üzerinde ölçülmüştür. Hız; belirli CPU modeline, size tahsis edilen çekirdek sayısına, sağlayıcının kiracılar arasındaki çekişmeyi nasıl yönettiğine ve iş yükünüzün vektör komutlarını ne kadar verimli kullandığına bağlıdır. Seçim yapacağınız iki planı, mümkünse kendi iş yükünüzle kıyaslayarak test edin ve elde ettiğiniz değerleri karşılaştırın.

Bir üretim sunucusunu arm64'e taşımadan önce neleri kontrol etmeliyim?

Bu sırayla dört kontrol yapın. Her container imajının bir arm64 manifestine sahip olduğunu doğrulayın. Her üçüncü taraf apt deposunun binary-arm64 yayınladığını doğrulayın. Kapalı kaynak kodlu her aracın bir aarch64 indirme seçeneği olduğunu doğrulayın. Ardından hedef örnek üzerinde getconf PAGESIZE komutunu çalıştırın; çünkü 64 KiB sayfa boyutuna sahip bir çekirdek, çok sayıda küçük eşlemeye sahip süreçlerin bellek kullanımını değiştirir. Bu dört kontrolden herhangi birinde başarısız olan bir durum, o sunucuyu x86 üzerinde tutmak için yeterli bir nedendir.