VPS ARM frente a x86: qué cambia realmente

Qué cambia al pasar a un VPS ARM

Un VPS ARM ejecuta el mismo Linux y el mismo Nginx que un VPS x86, y normalmente cuesta menos por núcleo. El riesgo del cambio es la compatibilidad. Un programa compilado para x86-64 no puede ejecutarse en arm64, por lo que cada componente de su pila debe incluir una compilación para arm64 o poder recompilarse.

La mayoría de las pilas modernas superan esta comprobación sin trabajo adicional. Los fallos suelen concentrarse en dos puntos: imágenes de contenedor compiladas únicamente para una arquitectura y software de código cerrado sin descarga para arm64. Los comandos siguientes permiten comprobar ambos aspectos en su propia pila antes de pagar una instancia. Si todavía está determinando qué tipo de servidor necesita, empiece por qué es un VPS y en qué se diferencia del hosting compartido.

arm64, aarch64, amd64: qué nombre corresponde a cada arquitectura

Ejecute estos comandos en cualquier instancia antes de hacer nada más.

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

uname -m muestra aarch64 en una máquina ARM y x86_64 en una máquina Intel o AMD. dpkg --print-architecture muestra arm64 y amd64 en esas mismas dos máquinas. Ambas respuestas son correctas. El kernel de Linux y el sistema de paquetes de Debian eligieron nombres distintos para el mismo conjunto de instrucciones. Por eso, aarch64 y arm64 significan una cosa, y x86_64 y amd64 significan la otra. Docker usa los nombres del estilo de Debian, por eso la plataforma de una imagen aparece como linux/arm64.

En arm64 no existe una línea model name en /proc/cpuinfo. En su lugar, aparece un campo Features, y la criptografía acelerada por hardware se muestra allí mediante indicadores como aes pmull sha1 sha2. Son las extensiones criptográficas de ARMv8 y cumplen la misma función que AES-NI en los procesadores Intel y AMD: aceleran mediante hardware TLS (seguridad de la capa de transporte) y el cifrado de discos. Comprobación de la aceleración criptográfica AES en una VPS explica cómo realizar la prueba en ambas arquitecturas.

Por qué los contenedores fallan primero y cómo es el error

El manifiesto de cada imagen de Docker registra la arquitectura para la que se compiló. Si extrae en un host arm64 una imagen que sólo tiene un manifiesto amd64, la extracción se completa correctamente. El fallo aparece cuando se inicia el primer proceso:

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 es el kernel que rechaza ejecutar el archivo porque su cabecera ELF (formato ejecutable y enlazable) indica un tipo de máquina que esta CPU no implementa. Ninguna configuración lo corrige. Las instrucciones no están disponibles en el silicio.

Compruebe el manifiesto antes de desplegar:

docker buildx imagetools inspect nginx:1.27

La salida muestra una línea Platform: por cada imagen del manifiesto, como linux/amd64 y linux/arm64. Si falta linux/arm64, esa etiqueta no se iniciará en un VPS ARM. docker manifest inspect --verbose nginx:1.27 muestra la misma información, pero Docker documenta docker manifest como un comando experimental cuyo comportamiento puede cambiar entre versiones, por lo que se recomienda imagetools.

Para las imágenes que compile usted mismo, compile ambas arquitecturas con un solo comando y suba una lista de manifiestos:

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

Compilar para una arquitectura distinta en un solo host requiere que la emulación en modo de usuario de QEMU esté registrada con el controlador binfmt_misc del kernel:

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

Use la emulación para compilar y probar. No la use para servir tráfico. La documentación de Docker indica que la emulación con QEMU "puede ser mucho más lenta que las compilaciones nativas, especialmente en tareas con un uso intensivo de CPU, como la compilación y la compresión o descompresión", por lo que un servicio x86 emulado en una instancia ARM elimina el ahorro que motivó el cambio. La configuración del host para el caso nativo es idéntica en ambas arquitecturas: ejecutar Docker en un VPS lo explica, y un archivo de Compose existente funciona sin cambios cuando todas sus imágenes tienen un manifiesto arm64.

¿Existirán en arm64 los paquetes que necesito?

Ubuntu y Debian compilan casi todo el archivo para arm64, por lo que apt install nginx postgresql redis-server se comporta igual en ambas arquitecturas. Las diferencias aparecen en los repositorios de terceros.

Consulte directamente a apt en la instancia ARM:

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

Si apt-cache policy informa Candidate: (none), significa que ningún repositorio habilitado publica una compilación de ese paquete para esta arquitectura. apt-get install -s simula la instalación y no escribe nada; en el mismo caso, termina con E: Unable to locate package.

Después, lea la salida de apt update en lugar de pasarla por alto. Un repositorio del proveedor que sólo admite amd64 lo indica:

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

El repositorio está configurado y es accesible, pero no contiene nada que esta máquina pueda instalar. Revise también la propia entrada de origen. Una línea fijada con [arch=amd64] se omite en un host arm64, por lo que el paquete parece inexistente cuando la causa real es la fijación.

Qué cargas de trabajo son seguras y cuáles requieren una comprobación previa

Los runtimes interpretados y de bytecode son portables por diseño. PHP, Python, Ruby y Node.js tienen paquetes arm64 en las distribuciones principales. Go y Rust compilan de forma cruzada para arm64 al establecer un destino. Una pila LEMP, una API de Node, un binario de Go detrás de Nginx o una base de datos Postgres son cargas de trabajo habituales en arm64.

Un compilador just in time (JIT) genera código máquina mientras se ejecuta el programa, por lo que necesita un generador de código para la arquitectura de destino. Las versiones actuales tienen uno: OpenJDK, .NET, el motor V8 incluido en Node.js y PyPy son compatibles con arm64 en Linux. El verdadero riesgo son las versiones antiguas fijadas. Un script de despliegue que instala una versión del runtime publicada hace varios años debe comprobarse en las notas de esa versión para confirmar la compatibilidad con aarch64, en lugar de asumir que funcionará.

Las bibliotecas que incluyen ensamblador x86 escrito manualmente o intrínsecos SSE y AVX son un caso menos evidente. La mayoría también tiene una ruta NEON (NEON es el conjunto de instrucciones vectoriales de ARM) o una alternativa en C estándar, por lo que compilan y se ejecutan. El rendimiento puede diferir del de la compilación para x86 en cualquiera de los dos sentidos. Mídalo en su instancia en lugar de predecirlo a partir de un artículo.

El software de código cerrado es el verdadero bloqueo. Un agente de monitorización del proveedor, un controlador de base de datos con licencia, un panel de control comercial o un daemon antivirus se distribuyen como binarios compilados. Si el proveedor no publica una compilación arm64, no hay nada que pueda hacer al respecto. cPanel y WHM es el caso más claro en hosting: sus requisitos del sistema indican x86_64 y no incluyen ARM, por lo que un servidor con panel de control debe permanecer en x86 (comprobado en agosto de 2026; conviene volver a leer los requisitos en la página del propio proveedor). Si esto es lo único que le impide cambiar, las alternativas a cPanel que merece la pena ejecutar en un VPS son un buen punto de partida. Compruebe la compatibilidad de arquitectura de cada una de la misma forma.

Kernels y tamaño de página: diferencias que todavía existen entre las instancias ARM

Los servidores x86-64 son casi intercambiables. Los servidores ARM son menos uniformes, y las diferencias están por debajo de la aplicación.

El tamaño de página es la diferencia que llega a producción. La mayoría de los kernels arm64 usan páginas de 4 KiB, igual que x86-64. Algunos usan 64 KiB. Red Hat Enterprise Linux 8 para aarch64 incluía de forma predeterminada un kernel con páginas de 64 KiB, y RHEL 9 devolvió el valor predeterminado a 4 KiB, aunque mantiene un paquete kernel-64k independiente para las cargas de trabajo que necesitan el tamaño mayor. Un tamaño de página de 64 KiB eleva el mínimo de memoria de un proceso con muchas asignaciones pequeñas, porque el bloque más pequeño que puede asignar el kernel es dieciséis veces mayor. Ejecute getconf PAGESIZE en la instancia y lea el valor en lugar de darlo por supuesto.

Conviene conocer algunas diferencias menores. En arm64 no existe un paquete de microcódigo de CPU del sistema operativo, por lo que las actualizaciones del firmware las proporciona el proveedor y no apt. Los servidores ARM arrancan mediante UEFI (unified extensible firmware interface) y describen su hardware mediante ACPI (advanced configuration and power interface). Algunas funciones de x86 no tienen ningún equivalente en ARM, como el cifrado de memoria AMD SEV y las GPU mediadas Intel GVT-g.

¿Ha madurado la plataforma de servidores ARM?

En el ámbito del software, sí. Debian, Ubuntu, Fedora y RHEL ofrecen compilaciones arm64 de primer nivel, y las imágenes oficiales de Docker Hub son multi-arquitectura de forma habitual.

La evidencia reciente más clara es Proxmox. El 5 de agosto de 2026, Proxmox anunció la primera edición arm64 con soporte oficial de Proxmox Virtual Environment, la versión 9.2, que comparte los repositorios de paquetes y el ciclo de versiones con la edición x86-64. Está basada en Debian 13.5 con Linux 7.0, QEMU 11.0, LXC 7.0 y ZFS 2.4. La configuración y las herramientas coinciden con las de x86-64, salvo por un pequeño conjunto de elementos específicos de la arquitectura.

Lea las limitaciones de ese mismo anuncio. Muestran lo reducido que sigue siendo el conjunto de hardware de servidores ARM con soporte oficial. Proxmox validó sistemas NVIDIA Grace y NVIDIA Vera desde el primer día, después de realizar pruebas conjuntas con NVIDIA y Supermicro en hardware Grace Hopper. El resto del hardware UEFI basado en ARMv8-A y ARMv9-A recibe soporte con el mejor esfuerzo posible. Los equipos de una sola placa basados únicamente en device tree, como Raspberry Pi, no tienen soporte. Una máquina virtual sólo se ejecuta en un nodo de su propia arquitectura. La migración en vivo sólo funciona entre nodos de la misma arquitectura. Los clústeres con arquitecturas mixtas no tienen soporte oficial.

Esta es la situación real en agosto de 2026. Que un proveedor de hipervisores ofrezca arm64 con el mismo ciclo de versiones que x86-64 representa un avance real para la plataforma. La lista de hardware con soporte desde el primer día incluye dos familias de CPU.

Lista de comprobación para ejecutar antes de decidir

1. Ejecuta uname -m en una instancia de prueba y confirma que muestra aarch64.
2. Ejecuta docker buildx imagetools inspect en cada imagen de tu archivo Compose y confirma que aparece una línea de plataforma linux/arm64 para cada una.
3. Ejecuta apt update en la instancia ARM y lee todas las advertencias Skipping acquire que muestra.
4. Abre la página de descarga de cada agente de código cerrado del que dependas y busca por nombre una compilación arm64 o aarch64.
5. Ejecuta getconf PAGESIZE y anota la respuesta antes de dimensionar la memoria.
6. Ejecuta tu propia prueba de rendimiento tanto en el plan ARM como en el plan x86 entre los que estás eligiendo.

Lo que esta publicación no afirma

No vamos a proporcionarle una relación precio-rendimiento de ARM frente a x86. El precio por núcleo varía según el proveedor y el plan, y una cifra obtenida en el hardware de otra persona no predice el rendimiento del suyo. Mídalo directamente. Nuestra guía para comparar el rendimiento de un VPS cubre sysbench y fio con un método reproducible, y cuánto cuesta realmente un VPS cubre el aspecto económico de la comparación. El almacenamiento es una decisión independiente de la arquitectura de CPU, y cómo se compara NVMe con SATA SSD en un VPS aborda esa parte. Ejecute la misma prueba en ambos planes, usando su propia carga de trabajo cuando sea posible, y deje que sus cifras determinen la elección.

FAQ

¿Se ejecutarán mis contenedores Docker en un VPS ARM?

Se ejecutarán si todas las imágenes de la pila tienen una entrada linux/arm64 en su manifiesto. Compruebe cada imagen con docker buildx imagetools inspect <image> y busque una línea Platform: linux/arm64. Las imágenes oficiales de Docker Hub suelen ser multiarquitectura. Las imágenes de proveedores pequeños y las imágenes que haya creado en una máquina x86 a menudo no lo son. Para sus propias imágenes, vuelva a compilarlas con docker buildx build --platform linux/amd64,linux/arm64 ... --push para que una etiqueta sirva para ambas arquitecturas.

¿Qué significa exec format error en un servidor ARM?

El kernel intentó ejecutar un binario cuyo encabezado ELF indica un tipo de máquina diferente y lo rechazó. En un host arm64, casi siempre significa que se trata de un binario x86-64 o de una imagen de contenedor x86-64. Docker muestra primero una advertencia: la plataforma de imagen solicitada linux/amd64 no coincide con la plataforma detectada del host linux/arm64/v8. La solución es compilar para la arquitectura correcta. Ningún cambio de configuración permite ejecutar de forma nativa en ARM un binario x86-64.

¿arm64 es lo mismo que aarch64?

Sí. Son dos nombres para el conjunto de instrucciones ARM de 64 bits. El kernel informa aarch64 mediante uname -m, mientras que los paquetes de Debian y Ubuntu y las cadenas de plataforma de Docker usan arm64. La misma diferencia existe en el otro lado: uname -m indica x86_64 y los paquetes indican amd64. Si una página de descargas ofrece sólo archivos aarch64, esos son los archivos correctos para una máquina que dpkg --print-architecture denomina arm64.

¿Un VPS ARM es más rápido que un VPS x86?

No existe una respuesta general, y cualquier proporción concreta que lea se midió en un hardware distinto del suyo. La velocidad depende del modelo específico de CPU, del número de núcleos que tenga asignados, de cómo gestione el proveedor la contención entre inquilinos y de lo bien que su carga de trabajo utilice las instrucciones vectoriales. Compare los dos planes que realmente está considerando mediante pruebas de rendimiento. Si es posible, use su propia carga de trabajo y compare esos resultados.

¿Qué debo comprobar antes de migrar un servidor de producción a arm64?

Debe realizar cuatro comprobaciones, en este orden. Confirme que cada imagen de contenedor tenga un manifiesto arm64. Confirme que cada repositorio apt de terceros publique binary-arm64. Confirme que cada agente de código cerrado tenga una descarga aarch64. Después, ejecute getconf PAGESIZE en la instancia de destino, porque un kernel con páginas de 64 KiB cambia la huella de memoria de los procesos con muchas asignaciones pequeñas. Cualquier elemento que falle una de esas cuatro comprobaciones es un motivo para mantener ese servidor concreto en x86.