ARM VPS vs x86 VPS: wat verandert er echt?

Wat verandert er bij de overstap naar een ARM VPS

Een ARM VPS draait dezelfde Linux-distributie en dezelfde Nginx als een x86 VPS, en is doorgaans goedkoper per core. Het risico bij de overstap is 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 aanpassingen. Problemen concentreren zich op twee gebieden: container-images die slechts 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 iets anders begint.

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

uname -m toont aarch64 op een ARM-machine en x86_64 op een Intel- of AMD-machine. dpkg --print-architecture toont arm64 en amd64 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. U krijgt in plaats daarvan een Features-veld, en hardwarematige cryptografie verschijnt daar als vlaggen zoals aes pmull sha1 sha2. Dit zijn de ARMv8 Cryptographic Extensions, en zij doen hetzelfde werk 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 bevinden zich niet in de hardware.

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 om netwerkverkeer af te handelen. De eigen documentatie van Docker stelt dat emulatie met QEMU "veel trager 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 dus de besparing die u deed overstappen. 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 pakketten die ik nodig heb beschikbaar voor arm64?

Ubuntu en Debian compileren vrijwel het gehele archief voor arm64, waardoor apt install nginx postgresql redis-server zich op beide architecturen hetzelfde 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 datzelfde geval eindigt het 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 dat 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 hebben allemaal 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 is standaardwerk op arm64.

Een just-in-time (JIT) compiler produceert machinecode terwijl het programma draait, dus deze heeft een codegenerator nodig voor de doelarchitectuur. 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 aan te nemen dat het werkt.

Bibliotheken die handgeschreven x86-assembly of SSE- en AVX-intrinsics bevatten, vormen het stillere probleem. De meeste hebben ook 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 een gecompileerde binary, en wanneer de leverancier geen arm64-build publiceert, kunt u daar niets aan veranderen. cPanel en WHM is het duidelijkste voorbeeld in hosting: de systeemvereisten noemen x86_64 en vermelden geen ARM, dus een server met een configuratiescherm blijft op x86 (gecontroleerd in augustus 2026, en het is de moeite waard om de eigen vereistenpagina van de leverancier opnieuw te lezen). 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 manier 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 de productieomgeving beïnvloedt. 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 afzonderlijk 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 toewijzingen, omdat het kleinste blok dat de kernel kan toewijzen zestien keer zo groot is. Voer getconf PAGESIZE uit op de instance en lees het getal af in plaats van er zomaar vanuit te gaan.

Enkele kleinere verschillen zijn het vermelden waard. Er is geen CPU-microcode-pakket voor het besturingssysteem op arm64, dus firmware-updates zijn afkomstig van uw provider en niet van apt. ARM-servers starten op 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-geheugenversleuteling en Intel GVT-g mediated GPU's.

Is het ARM-serverplatform volwassen geworden?

Wat betreft software: ja. Debian, Ubuntu, Fedora en RHEL leveren allemaal eersteklas 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 releasecyclus 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, en de configuratie en tooling komen overeen met x86-64, afgezien van een kleine set architectuurspecifieke items.

Lees de kanttekeningen in diezelfde aankondiging, want deze laten zien hoe beperkt de 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 UEFI-gebaseerde ARMv8-A- en ARMv9-A-hardware krijgt ondersteuning op basis van 'best effort'. Single-board computers die uitsluitend gebruikmaken van een device tree, zoals de Raspberry Pi, worden niet ondersteund. Een guest draait alleen op een node met 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 status per augustus 2026. Een hypervisor-leverancier die arm64 uitbrengt met dezelfde levenscyclus als x86-64 is een reële vooruitgang voor het platform. De lijst met hardware die vanaf de eerste dag wordt ondersteund, omvat 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 voor elk een linux/arm64 platformregel.
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 waar u tussen kiest.

Wat dit artikel niet claimt

Wij bieden 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 daarom 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 heeft in het manifest. 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 kunt u opnieuw bouwen 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 de 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. De 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 waaruit u daadwerkelijk 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 niet slaagt voor een van deze vier controles is een reden om die specifieke server op x86 te houden.