SSD Nodes Learn Hosting plans →
Gidsen Matt ConnorDoor Matt Connor · Bijgewerkt 2026-08-28

ARM VPS vs x86 VPS: wat zijn de verschillen?

Een ARM VPS is vaak goedkoper per core, maar compatibiliteit is cruciaal. Controleer of uw softwarestack arm64 ondersteunt met specifieke commando's voor uw Linux-omgeving.

Wat verandert er bij de overstap naar een ARM VPS

Een ARM VPS draait dezelfde Linux-distributie en dezelfde Nginx-versie als een x86 VPS, en is doorgaans goedkoper per core. Het risico bij de overstap is de compatibiliteit. Een programma dat is gecompileerd voor x86-64 kan niet draaien op arm64; elk onderdeel van uw softwarestack moet daarom een arm64-build aanbieden of herbouwbaar zijn.

De meeste moderne stacks doorstaan deze test zonder extra werk. Problemen concentreren zich op twee gebieden: container-images die uitsluitend voor één architectuur zijn gebouwd, en closed-source software waarvoor geen arm64-download beschikbaar is. De onderstaande commando's beantwoorden beide vragen voor uw eigen stack voordat u betaalt voor een instance. Als u nog aan het bepalen bent welk type server u nodig heeft, begin dan bij wat een VPS is en hoe deze verschilt van shared hosting.

arm64, aarch64, amd64: welke naam betekent wat

Voer deze commando's op elke instantie uit voordat u met andere taken begint.

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

uname -m geeft aarch64 weer op een ARM-machine en x86_64 op een Intel- of AMD-machine. dpkg --print-architecture geeft arm64 en amd64 weer voor diezelfde twee machines. Beide antwoorden zijn correct. De Linux-kernel en het Debian-pakketsysteem hebben verschillende namen gekozen voor dezelfde instructieset, waardoor aarch64 en arm64 het ene betekenen, en x86_64 en amd64 het andere. Docker gebruikt de namen in Debian-stijl, wat de reden is dat een image-platform linux/arm64 aangeeft.

Op arm64 staat er geen model name-regel in /proc/cpuinfo. In plaats daarvan krijgt u een Features-veld, waarin hardware-crypto verschijnt als vlaggen zoals aes pmull sha1 sha2. Dit zijn de ARMv8 Cryptographic Extensions; zij vervullen dezelfde taak als AES-NI op Intel- en AMD-onderdelen: ze versnellen TLS (transport layer security) en schijfversleuteling op hardwareniveau. Controleren op AES-hardwareversnelling op een VPS behandelt de test voor beide architecturen.

Waarom containers als eerste falen en hoe de foutmelding eruitziet

Elk Docker-image-manifest legt vast voor welke architectuur het is gebouwd. Als u een image met alleen een amd64-manifest naar een arm64-host haalt, slaagt het ophalen. De fout treedt op bij de eerste start van het proces:

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 betekent dat de kernel weigert het bestand uit te voeren, omdat de ELF-header (executable and linkable format) een machinetype specificeert dat deze CPU niet ondersteunt. Geen enkele instelling lost dit op. De instructies zijn niet aanwezig in de processor.

Controleer het manifest voordat u implementeert:

docker buildx imagetools inspect nginx:1.27

De uitvoer toont één Platform:-regel per image in de manifestlijst, zoals linux/amd64 en linux/arm64. Als linux/arm64 ontbreekt, zal die tag niet starten op een ARM VPS. docker manifest inspect --verbose nginx:1.27 toont dezelfde informatie, maar Docker documenteert docker manifest als een experimenteel commando waarvan het gedrag tussen releases kan veranderen; geef daarom de voorkeur aan imagetools.

Voor images die u zelf bouwt, bouwt u beide architecturen in één commando en pusht u een manifestlijst:

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

Bouwen voor een vreemde architectuur op één host vereist QEMU-gebruikersmodus-emulatie, geregistreerd bij de binfmt_misc-handler van de kernel:

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

Gebruik emulatie om te bouwen en te testen. Gebruik het niet voor het afhandelen van netwerkverkeer. De eigen documentatie van Docker stelt dat emulatie met QEMU "veel langzamer kan zijn dan native builds, vooral bij rekenintensieve taken zoals compilatie en compressie of decompressie". Een geëmuleerde x86-service op een ARM-instantie tenietdoet daarmee de kostenbesparing die de reden was voor uw overstap. De hostconfiguratie voor de native situatie is identiek op beide architecturen: Docker draaien op een VPS behandelt dit, en een bestaand Compose-bestand werkt ongewijzigd zodra elk image daarin een arm64-manifest heeft.

Zijn de benodigde pakketten beschikbaar voor arm64?

Ubuntu en Debian compileren vrijwel het gehele archief voor arm64, waardoor apt install nginx postgresql redis-server zich op beide architecturen identiek gedraagt. De hiaten bevinden zich doorgaans in externe repositories van derden.

Vraag het direct aan apt, op de ARM-instantie:

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

apt-cache policy met de melding Candidate: (none) betekent dat geen enkele ingeschakelde repository een build van dat pakket voor deze architectuur publiceert. apt-get install -s simuleert de installatie zonder wijzigingen aan te brengen, en in hetzelfde scenario eindigt dit met E: Unable to locate package.

Lees vervolgens de uitvoer van apt update in plaats van er doorheen te scrollen. Een repository van een leverancier die alleen amd64 ondersteunt, geeft dit aan:

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

De repository is geconfigureerd en bereikbaar, maar bevat niets wat deze machine kan installeren. Controleer ook de bronvermelding zelf. Een regel die is vastgezet met [arch=amd64] wordt op een arm64-host overgeslagen, waardoor het pakket onvindbaar lijkt terwijl de werkelijke oorzaak de pin is.

Welke workloads zijn veilig en welke vereisen eerst een controle

Geïnterpreteerde en bytecode-runtimes zijn inherent portable. PHP, Python, Ruby en Node.js beschikken allemaal over arm64-pakketten in de standaard distributies. Go en Rust kunnen naar arm64 cross-compileren door één target in te stellen. Een LEMP-stack, een Node API, een Go-binary achter Nginx of een Postgres-database zijn standaard werkzaamheden op arm64.

Een just-in-time (JIT) compiler genereert machinecode terwijl het programma draait; hiervoor is een codegenerator voor de doelarchitectuur nodig. Huidige versies beschikken hierover: OpenJDK, .NET, de V8-engine in Node.js en PyPy ondersteunen allemaal arm64 op Linux. Vastgezette oude versies vormen het werkelijke risico. Een deploy-script dat een runtime-release van enkele jaren geleden installeert, moet worden gecontroleerd aan de hand van de release notes voor aarch64-ondersteuning in plaats van ervan uit te gaan dat het werkt.

Bibliotheken die handgeschreven x86-assembly of SSE- en AVX-intrinsics bevatten, vormen het minder opvallende probleem. De meeste beschikken ook over een NEON-pad (NEON is de ARM-vectorinstructieset) of een standaard C-fallback, waardoor ze compileren en draaien. De prestaties kunnen in beide richtingen afwijken van de x86-build. Meet dit op uw eigen instance in plaats van dit te voorspellen op basis van een artikel.

Closed-source software is de echte blokkade. Een monitoring-agent van een leverancier, een gelicentieerde database-driver, een commercieel configuratiescherm of een anti-virus-daemon wordt geleverd als gecompileerde binary. Wanneer de leverancier geen arm64-build publiceert, kunt u hier niets aan veranderen. cPanel en WHM is het duidelijkste voorbeeld in hosting: de systeemvereisten vermelden x86_64 en noemen geen ARM. Een server met een configuratiescherm blijft daarom op x86 (gecontroleerd in augustus 2026; het is de moeite waard om dit opnieuw te lezen op de eigen vereistenpagina van de leverancier). Als dat het enige is dat u tegenhoudt, is de cPanel-alternatieven die het waard zijn om op een VPS te draaien het startpunt, en controleer bij elk daarvan op dezelfde wijze de architectuurondersteuning.

Kernels en paginagrootte: waar ARM-instances nog verschillen

x86-64-servers zijn vrijwel uitwisselbaar. ARM-servers zijn minder uniform en de verschillen bevinden zich onder uw applicatielaag.

De paginagrootte is een factor die invloed heeft op de productieomgeving. De meeste arm64-kernels gebruiken 4 KiB-pagina's, net als x86-64. Sommige gebruiken 64 KiB. Red Hat Enterprise Linux 8 voor aarch64 leverde standaard een kernel met 64 KiB-pagina's, terwijl RHEL 9 de standaard terugbracht naar 4 KiB, met behoud van een apart kernel-64k-pakket voor workloads die de grotere omvang vereisen. Een paginagrootte van 64 KiB verhoogt het minimale geheugengebruik voor een proces met veel kleine mappings, omdat het kleinste blok dat de kernel kan toewijzen zestien keer groter is. Voer getconf PAGESIZE uit op de instance en lees het getal af in plaats van er zomaar vanuit te gaan. De paginagrootte is niet de enige kernelbeslissing die u raakt, aangezien de versie die uw provider levert ook bepaalt hoe werk over cores wordt verdeeld, en de cache-aware scheduling toegevoegd in Linux 7.2 is zowel op arm64 als op x86-64 beschikbaar.

Enkele kleinere verschillen zijn het vermelden waard. Er is geen CPU-microcode-pakket voor het besturingssysteem op arm64, dus firmware-updates komen van uw provider en niet van apt. ARM-servers starten via UEFI (unified extensible firmware interface) en beschrijven hun hardware via ACPI (advanced configuration and power interface). Sommige x86-functies hebben helemaal geen ARM-tegenhanger, waaronder AMD SEV-geheugenencryptie en Intel GVT-g mediated GPU's.

Is het ARM-serverplatform volwassen geworden?

Wat betreft de softwarekant: ja. Debian, Ubuntu, Fedora en RHEL leveren allemaal volwaardige arm64-builds, en de officiële images op Docker Hub zijn tegenwoordig standaard multi-arch.

Het duidelijkste recente bewijs hiervoor is Proxmox. Op 5 augustus 2026 kondigde Proxmox de eerste officieel ondersteunde arm64-editie van Proxmox Virtual Environment aan, versie 9.2, die dezelfde pakketrepositories en release-lifecycle deelt met de x86-64-editie. Deze is gebouwd op Debian 13.5 met Linux 7.0, QEMU 11.0, LXC 7.0 en ZFS 2.4, waarbij de configuratie en tooling, op een kleine set architectuurspecifieke items na, overeenkomen met x86-64.

Lees de kanttekeningen in diezelfde aankondiging, want deze tonen aan hoe beperkt het aanbod van officieel ondersteunde ARM-serverhardware nog steeds is. Proxmox valideerde NVIDIA Grace- en NVIDIA Vera-systemen vanaf de eerste dag, na gezamenlijke tests met NVIDIA en Supermicro op Grace Hopper-hardware. Andere op UEFI gebaseerde ARMv8-A- en ARMv9-A-hardware krijgt ondersteuning op basis van 'best effort'. Single board computers die uitsluitend gebruikmaken van device tree, zoals de Raspberry Pi, worden niet ondersteund. Een guest draait alleen op een node van dezelfde architectuur, live migratie werkt alleen tussen nodes met dezelfde architectuur, en clusters met een gemengde architectuur worden officieel niet ondersteund.

Dat is de eerlijke stand van zaken per augustus 2026. Een hypervisor-leverancier die arm64 uitbrengt met dezelfde lifecycle als x86-64 is een reële vooruitgang voor het platform. De lijst met hardware die vanaf de eerste dag wordt ondersteund, bestaat uit twee CPU-families.

Een checklist om uit te voeren voordat u doorvoert

  1. Voer uname -m uit op een testinstantie en bevestig dat deze aarch64 weergeeft.
  2. Voer docker buildx imagetools inspect uit op elke image in uw Compose-bestand en bevestig dat er voor elk een linux/arm64 platformregel aanwezig is.
  3. Voer apt update uit op de ARM-instantie en lees elke Skipping acquire waarschuwing die wordt getoond.
  4. Open de downloadpagina voor elke closed-source agent waarvan u afhankelijk bent en zoek naar een arm64- of aarch64-build op naam.
  5. Voer getconf PAGESIZE uit en noteer het antwoord voordat u het geheugen toewijst.
  6. Voer uw eigen benchmark uit op zowel het ARM-abonnement als het x86-abonnement waartussen u kiest.

Wat dit artikel niet claimt

Wij geven u geen prijs-prestatieverhouding voor ARM versus x86. De prijzen per core variëren per provider en per abonnement, en een meting op andermans hardware is geen voorspelling voor uw situatie. Voer zelf metingen uit. Onze handleiding voor het benchmarken van een VPS behandelt sysbench en fio met een methode die u kunt herhalen, en wat een VPS werkelijk kost behandelt de prijszijde van de vergelijking. Opslag is een afzonderlijke beslissing ten opzichte van de CPU-architectuur, en hoe NVMe zich verhoudt tot SATA SSD op een VPS behandelt dat aspect. Voer dezelfde test uit op beide abonnementen, indien mogelijk met uw eigen werklast, en laat uw eigen cijfers de doorslag geven.

FAQ

Zullen mijn Docker-containers draaien op een ARM VPS?

Ze draaien als elke image in de stack een linux/arm64-vermelding in het manifest heeft. Controleer elke image met docker buildx imagetools inspect <image> en zoek naar een Platform: linux/arm64-regel. Officiële images op Docker Hub zijn meestal multi-arch. Images van kleinere leveranciers, en images die u zelf op een x86-machine hebt gebouwd, zijn dat vaak niet. Voor uw eigen images: bouw ze opnieuw met docker buildx build --platform linux/amd64,linux/arm64 ... --push zodat één tag beide architecturen ondersteunt.

Wat betekent exec format error op een ARM-server?

De kernel probeerde een binary uit te voeren waarvan de ELF-header een ander machinetype aangeeft, en weigerde dit. Op een arm64-host betekent dit bijna altijd een x86-64 binary of container-image. Docker geeft eerst een waarschuwing dat het gevraagde image-platform linux/amd64 niet overeenkomt met het gedetecteerde host-platform linux/arm64/v8. De oplossing is een build voor de juiste architectuur. Geen enkele configuratiewijziging zorgt ervoor dat een x86-64 binary native draait op ARM.

Is arm64 hetzelfde als aarch64?

Ja. Dit zijn twee namen voor de 64-bit ARM-instructieset. De kernel rapporteert aarch64 via uname -m, terwijl Debian- en Ubuntu-pakketten, en Docker-platformstrings, arm64 gebruiken. Dezelfde splitsing bestaat aan de andere kant, waar uname -m zegt x86_64 en pakketten amd64 gebruiken. Als een downloadpagina alleen aarch64-bestanden aanbiedt, zijn dat de juiste bestanden voor een machine die dpkg --print-architecture als arm64 aanduidt.

Is een ARM VPS sneller dan een x86 VPS?

Die vraag heeft geen algemeen antwoord, en elke verhouding die u leest is gemeten op hardware die niet de uwe is. Snelheid hangt af van het specifieke CPU-model, het aantal cores dat u krijgt, hoe de provider omgaat met strijd tussen huurders, en hoe goed uw workload gebruikmaakt van vector-instructies. Benchmark de twee plannen waar u daadwerkelijk tussen kiest, indien mogelijk met uw eigen workload, en vergelijk die cijfers.

Wat moet ik controleren voordat ik een productieserver verplaats naar arm64?

Vier controles, in deze volgorde. Bevestig dat elke container-image een arm64-manifest heeft. Bevestig dat elke externe apt-repository binary-arm64 publiceert. Bevestig dat elke closed-source agent een aarch64-download heeft. Voer daarna getconf PAGESIZE uit op de doelinstantie, omdat een kernel met 64 KiB-pagina's het geheugengebruik van processen met veel kleine mappings verandert. Alles wat voor een van deze vier controles faalt, is een reden om die specifieke server op x86 te houden.

#arm64#cpu-architecture#vps#docker#performance