Tutoriales de VPS
¿Vale la pena comprar un VPS ARM (2026)? Cómo elegir entre VPS ARM y x86 y cómo comprobar la compatibilidad
Los VPS ARM suelen ser más baratos, consumen menos energía y van bien para contenedores y servicios web, pero no todos los proyectos deberían comprarlos sin pensar. Este artículo explica, de forma que un usuario normal pueda seguirla, las diferencias entre un VPS ARM y un VPS x86, los escenarios adecuados para cada uno, la compatibilidad con Docker, los comandos de comprobación antes de comprar y cuándo conviene gastar más y elegir x86.
Últimamente, cuando reviso planes de VPS, me encuentro a menudo con una nueva pregunta: con los mismos 2 núcleos y 4 GB, la versión ARM es claramente más barata y la x86 cuesta un poco más, así que ¿cuál debería comprar?
La primera reacción de mucha gente es:
- ARM es barato, ¿no significa eso mejor relación calidad-precio?
- x86 es el veterano, ¿no es más estable?
- ¿Se puede ejecutar Docker?
- ¿Habrá problemas de compatibilidad con WordPress, Node.js, Python o bases de datos?
- Si compro ARM, ¿será complicado migrar luego a un VPS normal?
Este artículo no ensalza ARM ni menosprecia x86. Mi criterio es simple: puedes comprar un VPS ARM, pero primero confirma que tu stack de software puede con arm64.
Si solo ejecutas Nginx, Docker Compose, una API pequeña, un sitio estático, monitorización o herramientas personales, un VPS ARM es muy atractivo. Pero si ejecutas software antiguo de código cerrado, servidores de juegos, programas binarios raros, o simplemente no sabes qué hay en las dependencias de tu proyecto, x86 sigue siendo más seguro.
| Caso de uso | ¿Es adecuado un VPS ARM? | Motivo |
|---|---|---|
| Nginx / Caddy / sitios estáticos | Muy adecuado | Las imágenes y paquetes de sistema principales casi siempre tienen arm64 |
| Herramientas autoalojadas con Docker Compose | Adecuado, pero comprueba la imagen | Comprueba si la imagen admite linux/arm64 |
| Aplicaciones Node.js / Python / Go | Mayormente adecuado | El ecosistema ya es bastante maduro |
| WordPress / PHP / MySQL | Normalmente adecuado | Las imágenes oficiales tienen buen soporte; comprueba los plugins aparte |
| Bases de datos ligeras / Redis | Adecuado | Los servicios comunes tienen versión ARM |
| Servidores de juegos | Con precaución | Muchos binarios de servidor solo existen para x86 |
| Paneles de código cerrado / software pirateado | No recomendado | Es donde más fácilmente falla la compatibilidad |
| Tareas de alto rendimiento por núcleo | Depende | Mira el modelo concreto de CPU, no solo la arquitectura |
Mi consejo personal es:
- Proyectos nuevos, contenedorizados y sobre todo de código abierto: puedes priorizar ARM;
- Proyectos antiguos, programas de código cerrado, sin ganas de comprobar compatibilidad: elige x86;
- Cargas de producción que ya funcionan bien en x86: no fuerces un cambio de arquitectura solo por ahorrar unos dólares.
No hay que ver ARM como algo misterioso. Para un usuario normal de VPS, afecta principalmente a dos cosas:
- El conjunto de instrucciones de la CPU es distinto;
- Los paquetes de software, imágenes de Docker y archivos binarios que descargas deben tener la arquitectura correspondiente.
Los VPS x86 habituales usan amd64 o x86_64. Los VPS ARM suelen usar arm64 o aarch64. Puedes comprobarlo en el servidor así:
uname -m
El resultado será más o menos:
x86_64 # 常见 x86 VPS
aarch64 # 常见 ARM VPS
Si normalmente solo usas apt install nginx y docker compose up -d, muchas veces no notarás la diferencia. Los problemas suelen aparecer en estos puntos:
- Alguna imagen de Docker no tiene versión arm64;
- Algún script de instalación tiene codificado un enlace de descarga x86;
- Algún software de código cerrado solo publica paquetes amd64;
- Algún plugin antiguo depende de compilación local y la compilación falla;
- El README de algún proyecto solo se ha probado en x86.
Así que no es que no puedas comprar un VPS ARM, sino que tienes que hacer un paso más que al comprar x86: comprobar la compatibilidad primero.
La razón principal es muy práctica: coste y consumo energético.
Los proveedores de nube usan servidores ARM normalmente para obtener mejor rendimiento por vatio. Para el usuario, la sensación más directa es que, con la misma memoria y número de núcleos, los planes ARM suelen ser algo más baratos o dar más núcleos.
Cosas como Ampere A1 de Oracle Cloud y la serie CAX de Hetzner son la puerta de entrada por la que mucha gente conoce los VPS ARM. Instancias en la nube como AWS Graviton también han hecho que ARM sea cada vez más común en servidores en la nube.
Pero atención: barato no significa necesariamente rápido.
El rendimiento de un VPS también depende de:
- El modelo concreto de CPU;
- Si el proveedor hace overselling;
- El I/O de disco;
- La ruta de red;
- Si se limita la CPU sostenida;
- Si tu software soporta ARM de forma nativa.
Prefiero ver el VPS ARM como "una nueva opción de buena relación calidad-precio", no como un sustituto universal.
Si vas a comprar un VPS ARM, no mires solo el precio. Repasa primero esta lista.
Este es el punto más importante.
Muchos proyectos autoalojados se despliegan hoy con Docker. El soporte oficial de Docker para imágenes multiplataforma ya es maduro; la misma imagen puede admitir tanto linux/amd64 como linux/arm64. Pero no todas las imágenes de terceros están hechas para múltiples arquitecturas.
Puedes comprobar la arquitectura de una imagen con:
docker buildx imagetools inspect nginx:latest
Quieres ver algo así en el resultado:
linux/amd64
linux/arm64
Si solo aparece linux/amd64, entonces en un VPS ARM tendrás problemas. No es del todo imposible ejecutarlo, pero normalmente requiere emulación o compilarlo tú mismo, y ni el rendimiento ni el coste de mantenimiento merecen la pena.
Muchos scripts de un solo clic descargan paquetes automáticamente según la arquitectura del sistema, y esos normalmente no dan problemas.
Pero algunos scripts tienen codificado:
linux-amd64.tar.gz
x86_64.rpm
amd64.deb
Estos scripts suelen fallar directamente en ARM. Puedes buscar primero en el README de GitHub o en el script de instalación:
arm64
aarch64
amd64
x86_64
Si el proyecto no menciona ARM en absoluto, no lo lleves a producción con prisas.
Los servicios comunes no suelen dar problemas:
- MySQL / MariaDB
- PostgreSQL
- Redis
- MongoDB
- Nginx
- Caddy
- Node.js
- Python
- Go
Estos componentes principales ya son muy comunes en Linux ARM.
Lo que realmente hay que vigilar es "un panel de gestión antiguo envolviéndolo todo" o "algún plugin que trae un binario de código cerrado". Por ejemplo, algunas versiones antiguas de paneles comerciales, sondas de monitorización y herramientas de gestión de servidores de juegos pueden ofrecer solo paquetes x86.
Si el proyecto es tuyo y vas a compilar tú mismo las imágenes de Docker, lo mejor es admitir múltiples arquitecturas desde el principio.
Docker Buildx puede compilar así:
docker buildx build \
--platform linux/amd64,linux/arm64 \
-t yourname/yourapp:latest \
--push .
Así, con la misma etiqueta de imagen, tanto el VPS x86 como el VPS ARM pueden descargar la versión correspondiente.
Si no quieres complicarte con múltiples arquitecturas, al menos confirma que tu destino de despliegue es ARM y no cambies de ARM hoy a x86 mañana.
Los datos en sí normalmente no temen las diferencias de arquitectura. Por ejemplo, volcados de bases de datos, archivos estáticos, almacenamiento de objetos y archivos de configuración se pueden mover de ARM a x86 sin problema.
Lo complicado es el entorno de ejecución:
- Si la imagen se puede seguir descargando tras cambiar de arquitectura;
- Si hay que recompilar los artefactos compilados;
- Si hay que sustituir binarios locales;
- Si algunos plugins están ligados a una arquitectura.
Así que no hagas copia de seguridad solo del directorio del contenedor. Una forma más segura es:
# 数据库导出
mysqldump -u root -p app_db > app_db.sql
# 配置文件和 compose 文件打包
tar -czf app-config.tar.gz docker-compose.yml .env nginx/
Así, cuando más adelante migres de ARM a x86, no te quedarás atascado por algún contenedor antiguo.
Yo priorizaría el uso de un VPS ARM en estos escenarios.
Nginx, Caddy, Hugo, Astro, exportación estática de Next.js: todos son muy adecuados.
Si solo tienes un blog, un sitio de documentación o un sitio de enlaces, las ventajas del VPS ARM son evidentes: barato, ahorra recursos y bajo coste de mantenimiento.
Por ejemplo:
- Uptime Kuma
- Vaultwarden
- Gitea
- FreshRSS
- NocoDB
- n8n
- Miniflux
- Umami
Muchos de estos proyectos tienen imágenes ARM. Comprueba la arquitectura de la imagen antes de comprar y normalmente no habrá problema.
Si vas a desplegar n8n, quizá te interese este artículo: Montar flujos de automatización con n8n en un VPS (2026)
Los backends como Node.js, Python FastAPI, Go y Rust ya tienen un soporte de ARM muy maduro.
Especialmente Go y Rust, si los compilas tú mismo, son más cómodos entre arquitecturas. Lo que realmente hay que vigilar es si las dependencias incluyen extensiones nativas.
Los servicios de monitorización normalmente no exigen mucho rendimiento por núcleo; valoran más la estabilidad y el coste.
Para cosas como Prometheus + Grafana, Node Exporter o Uptime Kuma, usar un VPS ARM como nodo de monitorización ligero es bastante adecuado.
Aquí seré más conservador, porque comprar la arquitectura equivocada para ahorrar es más molesto que gastar unos dólares más al principio.
Minecraft Java Edition está bien, pero muchos binarios de servidores de juegos, componentes antitrampas y plugins de gestión pueden ofrecer solo arquitectura x86.
Si la documentación oficial no indica claramente soporte para ARM, por lo general no recomiendo usar un VPS ARM para un servidor de juegos en producción.
Por ejemplo, ciertos paneles con licencia, agentes de monitorización y herramientas de gestión antiguas solo ofrecen paquetes amd64. Es incómodo comprar ARM y descubrir entonces que no se instala.
Para estos proyectos, prioriza x86.
No es que ARM no pueda ejecutar bases de datos, sino que el rendimiento de una base de datos depende más del disco, la memoria, la CPU, los parámetros y la carga real.
Para una base de datos de producción, no migraría solo porque ARM sea más barato. Como mínimo, haría pruebas de carga y un simulacro de copia de seguridad y restauración antes de decidir.
Si aún no has hecho un simulacro de restauración, puedes leer esto: Cómo hacer un simulacro de copia de seguridad y restauración en un VPS (2026)
Este es el error más común.
Si el proyecto te lo ha pasado otra persona, lleno de scripts, plugins y archivos binarios, y no estás seguro de dónde vienen, no compres ARM primero solo para ahorrar.
x86 deja más margen de error.
Cuando recibo una máquina, hago tres cosas primero.
uname -m
lscpu
cat /etc/os-release
Confirma si es aarch64 y si el sistema es la versión de Ubuntu / Debian que esperabas.
docker image inspect nginx:latest --format '{{.Architecture}}'
Si la salida es:
arm64
significa que se descargó la imagen ARM.
YABS y Geekbench sirven de referencia, pero yo valoro más las cargas reales:
- Si el panel de WordPress va fluido;
- Si la API de Node.js responde de forma estable;
- Si los contenedores Docker se reinician correctamente;
- Si las consultas a la base de datos tienen fluctuaciones evidentes;
- Si la ruta de red empeora en horas punta de la noche.
Si solo miras la puntuación de CPU, es fácil pasar por alto el disco y la red. Las veces que un VPS realmente va mal no suelen ser porque falte CPU, sino porque el I/O fluctúa, la ruta se vuelve inestable y los vecinos acaparan recursos.
Si no quieres darle vueltas, puedes elegir según esta tabla.
| Tu situación | Elección recomendada |
|---|---|
| Proyecto nuevo, despliegue con Docker, la imagen admite arm64 | VPS ARM |
| Principalmente Nginx, Caddy, Node.js, Python, Go | Vale la pena probar primero el VPS ARM |
| Necesitas ejecutar software antiguo, de código cerrado o servidores de juegos | VPS x86 |
| El proyecto ya funciona de forma estable en x86 | No migres a ARM a la ligera |
| Presupuesto ajustado pero dispuesto a comprobar compatibilidad | VPS ARM |
| No entiendes Linux y solo quieres evitar problemas | El VPS x86 es más tranquilo |
| Quieres un entorno de producción a largo plazo | Prueba primero con poco tráfico y luego decide |
Mi costumbre personal es:
- Entornos de prueba y proyectos nuevos: con ARM puedes probar sin miedo;
- Servicios de producción ligeros: ARM se puede usar, pero haz antes copias de seguridad y plan de reversión;
- Negocio principal y proyectos que no conoces: prioriza x86.
Si la página no lo deja claro, puedes preguntar en un ticket así:
Hi,
Before ordering this ARM VPS, could you please confirm:
1. Is the CPU architecture arm64 / aarch64?
2. Can I reinstall Ubuntu 22.04 or 24.04 arm64 from the panel?
3. Are snapshots and backups supported for ARM instances?
4. Can I migrate or rebuild this instance to an x86 plan later if needed?
5. Are there any limitations compared with your x86 VPS plans?
Thank you.
Es decir:
- Si es arm64 estándar;
- Si se pueden reinstalar sistemas comunes;
- Si se admiten copias de seguridad por snapshot;
- Si se puede migrar a x86 más adelante;
- Si el plan ARM tiene límites ocultos.
Si el soporte no sabe responder ni a esto con claridad, yo sería más prudente.
Si vale la pena comprar un VPS ARM no depende de "si ARM es bueno", sino de "si tu proyecto encaja con ARM".
Yo lo valoraría así:
- Las imágenes y el software admiten arm64;
- La carga es un escenario convencional como web, API, autoalojamiento o monitorización;
- Estás dispuesto a hacer una comprobación de compatibilidad;
- Tienes un plan de copia de seguridad y reversión;
- El precio es realmente mejor que el de un x86 de la misma gama.
Si cumples estas condiciones, vale mucho la pena probar un VPS ARM.
Pero si te lanzas solo porque es barato, sin comprobar imágenes, sin mirar la arquitectura del software y sin preparar copias de seguridad, el dinero que ahorres con ARM probablemente lo pagarás después con tiempo.
Resumen en una frase:
Si sabes algo de Docker y Linux, un VPS ARM es una opción con gran relación calidad-precio; si solo quieres instalar software sin pensar, el VPS x86 sigue siendo más estable.