ARM VPS vs x86 VPS: what actually changes

What changes when you move to an ARM VPS

An ARM VPS runs the same Linux and the same Nginx as an x86 VPS, and it usually costs less per core. The risk in switching is compatibility. A program compiled for x86-64 cannot run on arm64 at all, so every piece of software in your stack has to ship an arm64 build or be something you can rebuild.

Most modern stacks pass that test with no work. The failures cluster in two places: container images that were only ever built for one architecture, and closed source software with no arm64 download. The commands below answer both questions for your own stack before you pay for an instance. If you are still working out what kind of server you need, start with what a VPS is and how it differs from shared hosting.

arm64, aarch64, amd64: which name means what

Run these on any instance before anything else.

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

uname -m prints aarch64 on an ARM machine and x86_64 on an Intel or AMD one. dpkg --print-architecture prints arm64 and amd64 for those same two machines. Both answers are correct. The Linux kernel and the Debian packaging system picked different names for the same instruction set, so aarch64 and arm64 mean one thing, and x86_64 and amd64 mean the other. Docker uses the Debian style names, which is why an image platform reads linux/arm64.

On arm64 there is no model name line in /proc/cpuinfo. You get a Features field instead, and hardware crypto appears there as flags like aes pmull sha1 sha2. Those are the ARMv8 Cryptographic Extensions, and they do the job AES-NI does on Intel and AMD parts: they make TLS (transport layer security) and disk encryption fast in hardware. Checking for AES hardware acceleration on a VPS covers the test on both architectures.

Why containers break first, and what the error looks like

Every Docker image manifest records the architecture it was built for. Pull an image that has only an amd64 manifest onto an arm64 host and the pull succeeds. The failure arrives at the first process start:

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 is the kernel refusing to run the file, because its ELF (executable and linkable format) header names a machine type this CPU does not implement. No setting fixes it. The instructions are not in the silicon.

Check the manifest before you deploy:

docker buildx imagetools inspect nginx:1.27

The output lists one Platform: line per image in the manifest list, such as linux/amd64 and linux/arm64. If linux/arm64 is absent, that tag will not start on an ARM VPS. docker manifest inspect --verbose nginx:1.27 shows the same information, but Docker documents docker manifest as an experimental command whose behaviour can change between releases, so prefer imagetools.

For images you build yourself, build both architectures in one command and push a manifest list:

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

Building for a foreign architecture on a single host needs QEMU user mode emulation registered with the kernel's binfmt_misc handler:

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

Use emulation to build and to test. Do not use it to serve traffic. Docker's own documentation states that emulation with QEMU "can be much slower than native builds, especially for compute-heavy tasks like compilation and compression or decompression", so an emulated x86 service on an ARM instance gives back the saving that made you move. Host setup for the native case is identical on both architectures: running Docker on a VPS covers it, and an existing Compose file works unchanged once every image in it has an arm64 manifest.

Will the packages I need exist on arm64?

Ubuntu and Debian build nearly the whole archive for arm64, so apt install nginx postgresql redis-server behaves the same on both architectures. Third party repositories are where the gaps are.

Ask apt directly, on the ARM instance:

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

apt-cache policy reporting Candidate: (none) means no enabled repository publishes a build of that package for this architecture. apt-get install -s simulates the install and writes nothing, and in the same case it ends with E: Unable to locate package.

Then read the output of apt update instead of scrolling past it. A vendor repository that is amd64 only says so:

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

The repository is configured and reachable, and it holds nothing this machine can install. Check the source entry itself too. A line pinned with [arch=amd64] is skipped on an arm64 host, so the package looks missing when the real cause is the pin.

Which workloads are safe, and which need a check first

Interpreted and bytecode runtimes are portable by design. PHP, Python, Ruby and Node.js all have arm64 packages in the main distributions. Go and Rust cross-compile to arm64 by setting one target. A LEMP stack, a Node API, a Go binary behind Nginx or a Postgres database is ordinary work on arm64.

A just in time (JIT) compiler produces machine code while the program runs, so it needs a code generator for the target architecture. Current versions have one: OpenJDK, .NET, the V8 engine inside Node.js and PyPy all support arm64 on Linux. Pinned old versions are the real hazard. A deploy script that installs a runtime release from several years ago should be checked against that release's notes for aarch64 support rather than assumed to work.

Libraries carrying hand written x86 assembly, or SSE and AVX intrinsics, are the quieter case. Most also have a NEON path (NEON is the ARM vector instruction set) or a plain C fallback, so they compile and run. Performance can differ from the x86 build in either direction. Measure that on your instance rather than predicting it from an article.

Closed source software is the genuine blocker. A vendor monitoring agent, a licensed database driver, a commercial control panel or an anti-virus daemon arrives as a compiled binary, and when the vendor publishes no arm64 build there is nothing you can do about it. cPanel and WHM is the clearest case in hosting: its system requirements name x86_64 and do not list ARM, so a control panel server stays on x86 (checked August 2026, and worth re-reading on the vendor's own requirements page). If that is the only thing holding you back, the cPanel alternatives worth running on a VPS is where to start, and check each one's architecture support the same way.

Kernels and page size: where ARM instances still differ

x86-64 servers are almost interchangeable. ARM servers are less uniform, and the differences sit below your application.

Page size is the one that reaches production. Most arm64 kernels use 4 KiB pages, the same as x86-64. Some use 64 KiB. Red Hat Enterprise Linux 8 for aarch64 shipped a 64 KiB page kernel by default, and RHEL 9 moved the default back to 4 KiB while keeping a separate kernel-64k package for workloads that want the larger size. A 64 KiB page size raises the memory floor for a process with many small mappings, because the smallest chunk the kernel can hand out is sixteen times bigger. Run getconf PAGESIZE on the instance and read the number rather than assuming it. Page size is not the only kernel decision that reaches you, because the version your provider ships also governs how work is scheduled onto cores, and the cache aware scheduling added in Linux 7.2 lands on arm64 and x86-64 alike.

A few smaller differences are worth knowing. There is no operating system CPU microcode package on arm64, so firmware updates come from your provider and not from apt. ARM servers boot through UEFI (unified extensible firmware interface) and describe their hardware through ACPI (advanced configuration and power interface). Some x86 features have no ARM counterpart at all, including AMD SEV memory encryption and Intel GVT-g mediated GPUs.

Has the ARM server platform matured?

On the software side, yes. Debian, Ubuntu, Fedora and RHEL all ship first class arm64 builds, and the official images on Docker Hub are multi-arch as a matter of course.

The clearest recent evidence is Proxmox. On 5 August 2026 Proxmox announced the first officially supported arm64 edition of Proxmox Virtual Environment, version 9.2, sharing package repositories and the release lifecycle with the x86-64 edition. It is built on Debian 13.5 with Linux 7.0, QEMU 11.0, LXC 7.0 and ZFS 2.4, and the configuration and tooling match x86-64 apart from a small set of architecture specific items.

Read the caveats in that same announcement, because they show how narrow officially supported ARM server hardware still is. Proxmox validated NVIDIA Grace and NVIDIA Vera systems on day one, after joint testing with NVIDIA and Supermicro on Grace Hopper hardware. Other UEFI based ARMv8-A and ARMv9-A hardware gets best effort support. Device tree only single board computers such as the Raspberry Pi are not supported. A guest only runs on a node of its own architecture, live migration works only between nodes of the same architecture, and mixed architecture clusters are not officially supported.

That is the honest position as of August 2026. A hypervisor vendor shipping arm64 on the same lifecycle as x86-64 is real progress for the platform. The day one supported hardware list is two CPU families.

A checklist to run before you commit

1. Run uname -m on a trial instance and confirm it prints aarch64.
2. Run docker buildx imagetools inspect on every image in your Compose file and confirm a linux/arm64 platform line for each one.
3. Run apt update on the ARM instance and read every Skipping acquire warning it prints.
4. Open the download page for each closed source agent you depend on and look for an arm64 or aarch64 build by name.
5. Run getconf PAGESIZE and note the answer before you size memory.
6. Run your own benchmark on both the ARM plan and the x86 plan you are choosing between.

What this post does not claim

We are not going to hand you a price to performance ratio for ARM against x86. Per core prices vary by provider and by plan, and a number measured on somebody else's hardware does not predict yours. Measure it instead. Our guide to benchmarking a VPS covers sysbench and fio with a method you can repeat, and what a VPS actually costs covers the pricing side of the comparison. Storage is a separate decision from CPU architecture, and how NVMe compares with SATA SSD on a VPS deals with that half. Run the same test on both plans, with your own workload where you can, and let your numbers decide.

FAQ

Will my Docker containers run on an ARM VPS?

They run if every image in the stack has a linux/arm64 entry in its manifest. Check each one with docker buildx imagetools inspect <image> and look for a Platform: linux/arm64 line. Official images on Docker Hub are usually multi-arch. Images from smaller vendors, and images you built yourself on an x86 machine, often are not. For your own images, rebuild with docker buildx build --platform linux/amd64,linux/arm64 ... --push so one tag serves both architectures.

What does exec format error mean on an ARM server?

The kernel tried to execute a binary whose ELF header names a different machine type, and refused. On an arm64 host this almost always means an x86-64 binary or container image. Docker prints a warning first, saying the requested image platform linux/amd64 does not match the detected host platform linux/arm64/v8. The fix is a build for the right architecture. No configuration change makes an x86-64 binary run natively on ARM.

Is arm64 the same thing as aarch64?

Yes. They are two names for the 64-bit ARM instruction set. The kernel reports aarch64 through uname -m, while Debian and Ubuntu packaging, and Docker platform strings, use arm64. The same split exists on the other side, where uname -m says x86_64 and packaging says amd64. If a download page offers only aarch64 files, those are the right files for a machine that dpkg --print-architecture calls arm64.

Is an ARM VPS faster than an x86 VPS?

That question has no general answer, and any single ratio you read was measured on hardware that is not yours. Speed depends on the specific CPU model, the number of cores you are given, how the provider handles contention between tenants, and how well your workload uses vector instructions. Benchmark the two plans you are actually choosing between, with your own workload if you can, and compare those numbers.

What should I check before moving a production server to arm64?

Four checks, in this order. Confirm every container image has an arm64 manifest. Confirm every third party apt repository publishes binary-arm64. Confirm every closed source agent has an aarch64 download. Then run getconf PAGESIZE on the target instance, because a 64 KiB page kernel changes the memory footprint of processes with many small mappings. Anything that fails one of those four checks is a reason to keep that particular server on x86.