VPS ARM o x86: cosa cambia davvero

Cosa cambia passando 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 avere una build arm64 oppure deve poter essere ricompilato.

La maggior parte degli stack moderni supera questo controllo senza interventi. I problemi si concentrano in due aree: le immagini dei container create per una sola architettura e il software closed source per cui non è disponibile un download arm64. I comandi seguenti consentono di verificare entrambe le condizioni sul proprio stack prima di acquistare un'istanza. Se non hai ancora definito 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 qualsiasi istanza prima di procedere.

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

uname -m stampa aarch64 su una macchina ARM e x86_64 su una macchina Intel o AMD. dpkg --print-architecture stampa arm64 e amd64 sulle stesse due macchine. Entrambi i risultati sono corretti. Il kernel Linux e il sistema di pacchettizzazione Debian hanno scelto nomi diversi per lo stesso set di istruzioni: aarch64 e arm64 indicano un'architettura, 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 è presente alcuna riga model name in /proc/cpuinfo. Al suo posto è presente un campo Features, nel quale la crittografia hardware è indicata da flag come aes pmull sha1 sha2. Si tratta delle estensioni crittografiche ARMv8. Svolgono la stessa funzione di AES-NI sui processori Intel e AMD: accelerano via hardware TLS (transport layer security) e la cifratura 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 si presenta 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 viene completato. 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 non sono presenti nel silicio.

Controlla il manifest prima del deploy:

docker buildx imagetools inspect nginx:1.27

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

Per le immagini che compili autonomamente, compila entrambe le architetture con un solo comando e invia 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 su un singolo host richiede l'emulazione in modalità user di QEMU, 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 gestire traffico. La documentazione ufficiale di Docker specifica che l'emulazione con QEMU «può essere molto più lenta rispetto alle build native, soprattutto per attività ad alta intensità di calcolo come la compilazione e la compressione o decompressione»; pertanto, 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 quando ogni immagine utilizzata contiene un manifest arm64.

I pacchetti necessari saranno disponibili per arm64?

Ubuntu e Debian compilano quasi l'intero 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.

Eseguire direttamente una richiesta ad apt sull'istanza ARM:

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

L'output di apt-cache policy con 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.

Leggere quindi l'output di apt update invece di scorrerlo senza esaminarlo. Un repository del fornitore disponibile soltanto per amd64 lo dichiara 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 alcun pacchetto installabile su questa macchina. Controllare anche la voce relativa al repository. Una riga con [arch=amd64] viene ignorata su un host arm64; di conseguenza il pacchetto sembra mancare, mentre la causa reale è il pin.

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

I runtime interpretati e quelli basati su bytecode sono progettati per essere portabili. 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) genera codice macchina durante l'esecuzione del programma, quindi richiede un generatore di codice per l'architettura target. 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 fissate nei deploy. Uno script di deploy che installa una release del runtime risalente a diversi anni prima deve essere verificato nelle note di quella release per il supporto aarch64, invece di presumere che funzioni.

Le librerie che includono assembly x86 scritto manualmente oppure intrinsics 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 correttamente. 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 blocco. Un agente di monitoraggio del vendor, un driver di database con licenza, un pannello di controllo commerciale o un demone antivirus viene distribuito come binario compilato. Se il vendor non pubblica una build arm64, non è possibile intervenire. cPanel e WHM è il caso più evidente nell'hosting: i requisiti di sistema indicano x86_64 e non elencano ARM, quindi un server con pannello di controllo deve restare su x86 (verificato ad agosto 2026; è comunque opportuno rileggere la pagina dei requisiti sul sito del vendor). Se questo è l'unico elemento 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 sottostante all’applicazione.

La dimensione delle pagine è la differenza che incide sull’ambiente di 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 delle pagine di 64 KiB aumenta il limite 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, senza basarti su un’ipotesi.

È utile conoscere anche alcune differenze minori. Su arm64 non esiste un pacchetto di microcodice della CPU per il sistema operativo; gli aggiornamenti del firmware provengono quindi dal provider e non da apt. I server ARM eseguono il boot 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 cifratura della memoria AMD SEV e le GPU mediate Intel GVT-g.

La piattaforma server ARM è maturata?

Dal punto di vista software, sì. Debian, Ubuntu, Fedora e RHEL rilasciano tutti build arm64 di primo livello e le immagini ufficiali su Docker Hub sono normalmente multi-arch.

La prova più evidente e recente è Proxmox. Il 5 agosto 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 di x86-64, fatta eccezione per un piccolo insieme di elementi specifici dell’architettura.

Leggere le limitazioni riportate nello stesso annuncio è importante, perché mostrano quanto sia ancora ristretto l’insieme dell’hardware server ARM ufficialmente supportato. Proxmox ha validato i sistemi NVIDIA Grace e NVIDIA Vera già dal primo giorno, dopo i test congiunti con NVIDIA e Supermicro sull’hardware Grace Hopper. Gli altri sistemi hardware UEFI basati su ARMv8-A e ARMv9-A ricevono supporto best effort. I single-board computer che usano esclusivamente un device tree, come Raspberry Pi, non sono supportati. Un guest può essere eseguito solo su un nodo della stessa architettura. La migrazione live funziona solo 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 vendor di hypervisor rilasci arm64 con lo stesso ciclo di vita di x86-64 rappresenta un progresso concreto per la piattaforma. L’elenco dell’hardware supportato dal primo giorno comprende due famiglie di CPU.

Checklist da eseguire prima di procedere

1. Esegui uname -m su un'istanza di prova e verifica che stampi aarch64.
2. Esegui docker buildx imagetools inspect su ogni immagine nel tuo file Compose e verifica la presenza di una riga di piattaforma linux/arm64 per ciascuna immagine.
3. Esegui apt update sull'istanza ARM e leggi ogni avviso Skipping acquire che stampa.
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 sostiene questo articolo

Non forniremo un rapporto prezzo/prestazioni tra ARM e x86. Il prezzo per core varia in base al provider e al piano, e un valore misurato sull'hardware di altri non consente di prevedere il risultato sul tuo. Esegui invece le misurazioni. La nostra guida al benchmarking di un VPS illustra l'uso di sysbench e fio con un metodo ripetibile, mentre quanto costa realmente un VPS tratta l'aspetto economico del confronto. Lo storage è una scelta distinta dall'architettura della CPU; come si confronta NVMe con SATA SSD su un VPS tratta questo aspetto. Esegui lo stesso test su entrambi i piani, usando se possibile il tuo carico di lavoro, e lascia che siano i tuoi dati a decidere.

FAQ

I miei container Docker verranno eseguiti su un VPS ARM?

Verranno eseguiti se ogni immagine dello stack contiene una voce linux/arm64 nel proprio manifest. Verifica ogni immagine con docker buildx imagetools inspect <image> e cerca una riga Platform: linux/arm64. Le immagini ufficiali su Docker Hub supportano generalmente più architetture. Le immagini di fornitori più piccoli e quelle che hai creato su una macchina x86 spesso non le supportano. Per le tue immagini, esegui nuovamente la build con docker buildx build --platform linux/amd64,linux/arm64 ... --push, in modo che un unico tag supporti 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 lo ha rifiutato. Su un host arm64 questo indica quasi sempre un binario o un'immagine container x86-64. Docker stampa prima un avviso: la piattaforma dell'immagine richiesta linux/amd64 non corrisponde alla piattaforma host rilevata linux/arm64/v8. La soluzione consiste nel creare una build 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 segnala aarch64 tramite uname -m, mentre i pacchetti Debian e Ubuntu e le stringhe delle piattaforme Docker usano arm64. La stessa distinzione esiste sull'altro lato: uname -m indica x86_64, mentre il sistema di pacchettizzazione usa amd64. Se una pagina di download offre solo file aarch64, questi sono i file corretti per una macchina che dpkg --print-architecture identifica come arm64.

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

Non esiste una risposta generale e qualsiasi rapporto singolo tu abbia letto è stato misurato su hardware diverso dal tuo. Le prestazioni dipendono dal modello specifico della CPU, dal numero di core assegnati, dalla gestione della contesa tra tenant da parte del provider e dal livello di utilizzo delle istruzioni vettoriali da parte del carico di lavoro. Esegui un benchmark sui due piani tra cui stai scegliendo, usando se possibile il tuo carico di lavoro, 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 distribuisca un download aarch64. Quindi esegui getconf PAGESIZE sull'istanza di destinazione, perché un kernel con pagine da 64 KiB modifica l'occupazione di memoria dei processi con molte mappature di piccole dimensioni. Qualsiasi elemento che non supera una di queste quattro verifiche è un motivo per mantenere quel determinato server su x86.