VPS ARM o x86: cosa cambia davvero

Cosa cambia quando passi a un VPS ARM

Un VPS ARM esegue lo stesso Linux e lo stesso Nginx di un VPS x86 e, in genere, costa meno per core. Il rischio principale del passaggio è la compatibilità. Un programma compilato per x86-64 non può essere eseguito su arm64, quindi ogni componente dello stack deve disporre di una build arm64 oppure deve poter essere ricompilato.

La maggior parte degli stack moderni supera questa verifica senza interventi. I problemi si concentrano in due aree: le immagini dei container disponibili per una sola architettura e il software closed source per cui non esiste un download arm64. I comandi seguenti consentono di verificare entrambe le condizioni nel proprio stack prima di pagare un'istanza. Se stai ancora valutando quale tipo di server ti serve, inizia da che cos'è un VPS e in cosa differisce dall'hosting condiviso.

arm64, aarch64, amd64: quale nome indica cosa

Esegui questi comandi su ogni istanza prima di qualsiasi altra operazione.

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

uname -m restituisce aarch64 su una macchina ARM e x86_64 su una macchina Intel o AMD. dpkg --print-architecture restituisce arm64 e amd64 sulle stesse due macchine. Entrambe le risposte sono corrette. Il kernel Linux e il sistema di pacchettizzazione Debian hanno scelto nomi diversi per lo stesso set di istruzioni: aarch64 e arm64 indicano una variante, mentre x86_64 e amd64 indicano l'altra. Docker usa i nomi nello stile Debian; per questo la piattaforma di un'immagine è indicata come linux/arm64.

Su arm64 non esiste una riga model name in /proc/cpuinfo. È presente invece un campo Features, nel quale la crittografia hardware compare come flag quali aes pmull sha1 sha2. Si tratta delle ARMv8 Cryptographic Extensions e svolgono la stessa funzione di AES-NI sui processori Intel e AMD: accelerano in hardware TLS (Transport Layer Security) e la crittografia dei dischi. Verifica dell'accelerazione hardware AES su un VPS descrive il test per entrambe le architetture.

Perché i container si interrompono per primi e come appare l'errore

Ogni manifest di un'immagine Docker registra l'architettura per cui l'immagine è stata compilata. Se esegui il pull di un'immagine che contiene soltanto un manifest amd64 su un host arm64, il pull termina correttamente. L'errore si verifica al primo avvio del processo:

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 indica che il kernel rifiuta di eseguire il file, perché l'header ELF (executable and linkable format) specifica un tipo di macchina che questa CPU non implementa. Nessuna impostazione può risolvere il problema. Le istruzioni necessarie non sono presenti nell'hardware.

Controlla il manifest prima del deploy:

docker buildx imagetools inspect nginx:1.27

L'output elenca una riga Platform: per ogni immagine contenuta nella manifest list, ad esempio linux/amd64 e linux/arm64. Se linux/arm64 è assente, quel tag non si avvierà su una VPS ARM. docker manifest inspect --verbose nginx:1.27 mostra le stesse informazioni, ma la documentazione Docker indica docker manifest come un comando sperimentale il cui comportamento può cambiare tra le release; quindi preferisci imagetools.

Per le immagini che compili autonomamente, compila entrambe le architetture con un solo comando e pubblica una manifest list:

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

La compilazione per un'architettura diversa da quella dell'host richiede l'emulazione QEMU in user mode, registrata nel kernel tramite il gestore binfmt_misc:

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

Usa l'emulazione per compilare e testare. Non usarla per servire traffico. La documentazione Docker afferma che l'emulazione con QEMU "può essere molto più lenta delle build native, soprattutto per attività a elevato uso di CPU come la compilazione e la compressione o decompressione"; di conseguenza, un servizio x86 emulato su un'istanza ARM annulla il risparmio che aveva motivato la migrazione. La configurazione dell'host per il caso nativo è identica su entrambe le architetture: eseguire Docker su una VPS la descrive e un file Compose esistente funziona senza modifiche, una volta che ogni immagine utilizzata contiene un manifest arm64.

I pacchetti necessari saranno disponibili per arm64?

Ubuntu e Debian compilano quasi tutto l'archivio per arm64, quindi apt install nginx postgresql redis-server si comporta allo stesso modo su entrambe le architetture. Le lacune riguardano soprattutto i repository di terze parti.

Interroga direttamente apt sull'istanza ARM:

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

L'output di apt-cache policy che segnala Candidate: (none) indica che nessun repository abilitato pubblica una build di quel pacchetto per questa architettura. apt-get install -s simula l'installazione e non scrive nulla; nello stesso caso termina con E: Unable to locate package.

Leggi quindi l'output di apt update invece di scorrerlo senza esaminarlo. Un repository del fornitore disponibile solo per amd64 lo indica esplicitamente:

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

Il repository è configurato e raggiungibile, ma non contiene pacchetti installabili su questa macchina. Controlla anche la voce del repository. Una riga contrassegnata con [arch=amd64] viene ignorata su un host arm64; di conseguenza il pacchetto sembra mancante, mentre la causa reale è il pin.

Quali carichi di lavoro sono sicuri e quali richiedono prima una verifica

I runtime interpretati e quelli basati su bytecode sono portabili per progettazione. PHP, Python, Ruby e Node.js dispongono tutti di pacchetti arm64 nelle principali distribuzioni. Go e Rust eseguono la compilazione incrociata per arm64 impostando un solo target. Uno stack LEMP, un'API Node, un binario Go dietro Nginx o un database Postgres sono attività ordinarie su arm64.

Un compilatore just in time (JIT) produce codice macchina durante l'esecuzione del programma, quindi richiede un generatore di codice per l'architettura di destinazione. Le versioni attuali ne includono uno: OpenJDK, .NET, il motore V8 integrato in Node.js e PyPy supportano tutti arm64 su Linux. Il rischio reale riguarda le versioni obsolete bloccate. Uno script di deploy che installa una release del runtime risalente a diversi anni fa deve essere verificato nelle note di quella release per il supporto aarch64, anziché essere considerato compatibile senza controlli.

Le librerie che includono assembly x86 scritto manualmente oppure intrinsic SSE e AVX rappresentano il caso meno evidente. Nella maggior parte dei casi dispongono anche di un percorso NEON (NEON è il set di istruzioni vettoriali ARM) o di un fallback in C standard, quindi vengono compilate ed eseguite. Le prestazioni possono differire dalla build x86 in entrambe le direzioni. Misurale sulla tua istanza invece di prevederle sulla base di un articolo.

Il software closed source è il vero ostacolo. Un agent di monitoraggio del fornitore, un driver di database con licenza, un pannello di controllo commerciale o un daemon antivirus viene distribuito come binario compilato; se il fornitore non pubblica una build arm64, non c'è nulla che tu possa fare. cPanel e WHM sono il caso più chiaro nell'hosting: i relativi requisiti di sistema indicano x86_64 e non elencano ARM, quindi un server con pannello di controllo resta su x86 (verificato ad agosto 2026; è comunque opportuno ricontrollare la pagina dei requisiti sul sito del fornitore). Se questo è l'unico fattore che ti impedisce di procedere, le alternative a cPanel che vale la pena eseguire su un VPS sono il punto di partenza; verifica il supporto all'architettura di ciascuna nello stesso modo.

Kernel e dimensione delle pagine: dove le istanze ARM presentano ancora differenze

I server x86-64 sono quasi intercambiabili. I server ARM sono meno uniformi e le differenze si trovano a un livello inferiore rispetto all'applicazione.

La dimensione delle pagine è la differenza che arriva in produzione. La maggior parte dei kernel arm64 usa pagine da 4 KiB, come x86-64. Alcuni usano pagine da 64 KiB. Red Hat Enterprise Linux 8 per aarch64 distribuiva per impostazione predefinita un kernel con pagine da 64 KiB, mentre RHEL 9 ha riportato l'impostazione predefinita a 4 KiB, mantenendo un pacchetto kernel-64k separato per i carichi di lavoro che richiedono la dimensione maggiore. Una dimensione di pagina di 64 KiB aumenta il fabbisogno minimo di memoria per un processo con molte mappature di piccole dimensioni, perché il blocco minimo che il kernel può allocare è sedici volte più grande. Esegui getconf PAGESIZE sull'istanza e leggi il valore invece di basarti su un'ipotesi. La dimensione delle pagine non è l'unica decisione del kernel che ti riguarda, perché anche la versione distribuita dal provider determina come il lavoro viene pianificato sui core; inoltre, la pianificazione consapevole della cache aggiunta in Linux 7.2 arriva sia su arm64 sia su x86-64.

È utile conoscere anche alcune differenze minori. Su arm64 non esiste un pacchetto di microcodice della CPU per il sistema operativo, quindi gli aggiornamenti del firmware provengono dal provider e non da apt. I server ARM vengono avviati tramite UEFI (unified extensible firmware interface) e descrivono l'hardware tramite ACPI (advanced configuration and power interface). Alcune funzionalità x86 non hanno alcun equivalente ARM, tra cui la crittografia della memoria AMD SEV e le GPU mediate Intel GVT-g.

La piattaforma server ARM ha raggiunto un livello di maturità sufficiente?

Sul piano software, sì. Debian, Ubuntu, Fedora e RHEL distribuiscono tutti build arm64 di prima classe e le immagini ufficiali su Docker Hub sono normalmente multi-arch.

La prova più evidente e recente è Proxmox. Il 5 August 2026 Proxmox ha annunciato la prima edizione arm64 ufficialmente supportata di Proxmox Virtual Environment, la versione 9.2, con gli stessi repository dei pacchetti e lo stesso ciclo di rilascio dell’edizione x86-64. È basata su Debian 13.5 con Linux 7.0, QEMU 11.0, LXC 7.0 e ZFS 2.4. La configurazione e gli strumenti corrispondono a quelli x86-64, salvo un numero limitato di aspetti specifici dell’architettura.

Leggete le limitazioni riportate nello stesso annuncio. Mostrano quanto sia ancora ristretto l’insieme di hardware server ARM ufficialmente supportato. Proxmox ha validato i sistemi NVIDIA Grace e NVIDIA Vera fin dal primo giorno, dopo test congiunti con NVIDIA e Supermicro su hardware Grace Hopper. Gli altri sistemi UEFI basati su ARMv8-A e ARMv9-A ricevono supporto best effort. I single-board computer basati soltanto su device tree, come Raspberry Pi, non sono supportati. Una macchina virtuale può essere eseguita solo su un nodo della stessa architettura. La migrazione live funziona soltanto tra nodi della stessa architettura. I cluster con architetture miste non sono ufficialmente supportati.

Questa è la situazione reale ad agosto 2026. Il fatto che un produttore di hypervisor distribuisca arm64 con lo stesso ciclo di rilascio di x86-64 rappresenta un progresso concreto per la piattaforma. L’elenco dell’hardware supportato fin dal primo giorno comprende due famiglie di CPU.

Una checklist da eseguire prima di procedere

1. Esegui uname -m su un'istanza di prova e verifica che restituisca aarch64.
2. Esegui docker buildx imagetools inspect su ogni immagine nel file Compose e verifica la presenza di una riga della piattaforma linux/arm64 per ciascuna immagine.
3. Esegui apt update sull'istanza ARM e leggi ogni avviso Skipping acquire restituito.
4. Apri la pagina di download di ogni agent closed source da cui dipendi e cerca una build arm64 o aarch64 indicata esplicitamente.
5. Esegui getconf PAGESIZE e annota la risposta prima di dimensionare la memoria.
6. Esegui il tuo benchmark sia sul piano ARM sia sul piano x86 tra cui stai scegliendo.

Cosa non afferma questo articolo

Non forniremo un rapporto prezzo/prestazioni tra ARM e x86. I prezzi per core variano in base al provider e al piano. Inoltre, un valore misurato sull'hardware di qualcun altro non consente di prevedere i risultati sul tuo sistema. Esegui invece le misurazioni. La nostra guida al benchmarking di un VPS tratta sysbench e fio con un metodo ripetibile. L'articolo quanto costa realmente un VPS tratta invece l'aspetto economico del confronto. Lo storage è una scelta distinta dall'architettura della CPU. L'articolo come NVMe si confronta con SATA SSD su un VPS tratta questa parte. Esegui lo stesso test su entrambi i piani, usando ove possibile il tuo carico di lavoro, e basa la decisione sui risultati ottenuti.

FAQ

I miei container Docker funzioneranno su un VPS ARM?

Funzionano se ogni immagine nello stack contiene una voce linux/arm64 nel proprio manifest. Verifica ciascuna immagine con docker buildx imagetools inspect <image> e cerca una riga Platform: linux/arm64. Le immagini ufficiali su Docker Hub sono generalmente multi-architettura. Le immagini di fornitori più piccoli e quelle create autonomamente su una macchina x86 spesso non lo sono. Per le immagini create autonomamente, ricompila con docker buildx build --platform linux/amd64,linux/arm64 ... --push, così un unico tag serve entrambe le architetture.

Che cosa significa exec format error su un server ARM?

Il kernel ha tentato di eseguire un binario il cui header ELF indica un tipo di macchina diverso e ha rifiutato l'esecuzione. Su un host arm64 questo indica quasi sempre un binario x86-64 o un'immagine container x86-64. Docker stampa prima un avviso in cui indica che la piattaforma dell'immagine richiesta, linux/amd64, non corrisponde alla piattaforma host rilevata, linux/arm64/v8. La soluzione consiste nel compilare per l'architettura corretta. Nessuna modifica alla configurazione consente di eseguire nativamente su ARM un binario x86-64.

arm64 è la stessa cosa di aarch64?

Sì. Sono due nomi per il set di istruzioni ARM a 64 bit. Il kernel indica aarch64 tramite uname -m, mentre i pacchetti Debian e Ubuntu e le stringhe delle piattaforme Docker usano arm64. La stessa distinzione esiste dall'altra parte, dove uname -m indica x86_64 e i pacchetti usano amd64. Se una pagina di download offre soltanto file aarch64, questi sono i file corretti per una macchina che dpkg --print-architecture indica come arm64.

Un VPS ARM è più veloce di un VPS x86?

Non esiste una risposta generale e qualsiasi rapporto preso da una singola fonte è stato misurato su hardware diverso dal tuo. La velocità dipende dal modello specifico della CPU, dal numero di core assegnati, dalla gestione della contesa tra tenant da parte del provider e dall'efficienza con cui il carico di lavoro utilizza le istruzioni vettoriali. Esegui il benchmark dei due piani tra cui stai scegliendo, usando il tuo carico di lavoro se possibile, e confronta i risultati.

Che cosa devo verificare prima di spostare un server di produzione su arm64?

Esegui quattro verifiche, in quest'ordine. Verifica che ogni immagine container disponga di un manifest arm64. Verifica che ogni repository apt di terze parti pubblichi binary-arm64. Verifica che ogni agent proprietario e closed source disponga di un download aarch64. Esegui quindi getconf PAGESIZE sull'istanza di destinazione, perché un kernel con pagine da 64 KiB modifica l'occupazione di memoria dei processi con molti mapping di piccole dimensioni. Qualsiasi elemento che non supera una di queste quattro verifiche è un motivo per mantenere quel server su x86.