Here is a number that should get your attention: at Hetzner, a 4 vCPU / 8 GB ARM server (the CAX31, running Ampere Altra cores) launched at €11.99 per month, while the equivalent x86 CPX31 (4 vCPU AMD EPYC, 8 GB) sat at €16.49 (Better Stack). Same vCPU count, same RAM, roughly 27% cheaper. Hetzner announced price rises effective April 2026 that moved those figures to €15.99 and €21.49 respectively, and the gap barely budged. At the time of writing, choosing ARM still saves you about €5.50 per month per server, or around 26%.
That discount is not a promotion or a loss leader. It reflects a real difference in how much these chips cost to buy and power. And it raises an obvious question for anyone running Laravel in production: is there a catch, or are we all overpaying for x86 out of habit?
The honest answer is that it depends on the shape of your traffic, and most articles on this topic skip that part. ARM cores are typically 15 to 20% slower per single thread, which matters for PHP because each request runs on exactly one thread. But your server does not handle one request. It handles dozens of concurrent requests across a fleet of PHP-FPM workers, and that is a parallel workload where ARM's core count economics shine.
We've provisioned both architectures for Laravel apps enough times to have opinions grounded in production behavior rather than synthetic benchmarks alone. This post walks through the price math, the performance trade-off that actually matters for PHP, the state of arm64 compatibility in 2026, and a migration path that will not take your app down.
Why Did ARM Servers Suddenly Get Cheap?
ARM chips have dominated phones for two decades because they deliver more compute per watt. Servers were a different story for years: the software ecosystem assumed x86, and nobody wanted to be the first to port everything. Two things broke that logjam.
First, AWS built Graviton. Amazon started shipping its own ARM server chips in 2018 and priced Graviton instances aggressively below their x86 equivalents. That forced the entire ecosystem, from Linux distributions to Docker to database vendors, to treat arm64 as a first-class target. When the largest cloud provider on earth bets on an architecture, package maintainers follow.
Second, Ampere started selling ARM server chips to everyone else. The Ampere Altra, the chip inside Hetzner's CAX line, packs up to 80 cores on a single socket with predictable per-core performance and dramatically lower power draw than comparable x86 parts. For a hosting company, electricity and cooling are among the biggest line items in the datacenter budget. A chip that does comparable work on fewer watts translates directly into lower prices for you.
There's a third, quieter factor: your laptop probably already runs ARM. Every Apple Silicon MacBook since 2020 is an arm64 machine. Millions of developers have spent five years unknowingly stress-testing the arm64 ecosystem in local development, filing issues against every Docker image and PECL extension that did not build. The ecosystem hardened because of it. We'll come back to why that helps you in the compatibility section.
What Does the Price Gap Actually Look Like?
Let's put the Hetzner numbers side by side, since Hetzner is where the ARM value proposition is most visible in Europe. Both servers below offer 4 vCPUs and 8 GB of RAM. The only meaningful spec difference is the silicon.
CAX31 (ARM)
CPX31 (x86)
ARM Savings
CPU
4 vCPU Ampere Altra
4 vCPU AMD EPYC
-
RAM
8 GB
8 GB
-
Price before April 2026
€11.99/mo
€16.49/mo
€4.50/mo (~27%)
Price from April 2026
€15.99/mo
€21.49/mo
€5.50/mo (~26%)
Prices are at the time of writing and sourced from Better Stack's Hetzner Cloud review, which also covers the April 2026 adjustment. Even after the increase, the relative discount held steady at roughly a quarter off.
One server saving €5.50 a month is coffee money. But cost optimization compounds. If you run a web tier of three servers plus two queue workers, that is €27.50 a month, or €330 a year, for hardware that (as we'll see) may actually process more total requests for your workload. Scale that to an agency managing twenty client servers and the architecture choice starts paying a salary's worth of hosting bills over a few years.
The catch, and there is one, is that a cheaper server is only cheaper if it does the same job. Better Stack's analysis puts ARM instances at roughly 20 to 40% better price-performance for compatible parallel workloads, but around 15 to 20% lower single-thread scores (Better Stack). Both halves of that sentence matter for Laravel, so let's unpack them.
We've written before about why Hetzner in general is our value pick for European Laravel hosting in our Hetzner deep dive. The ARM line extends that logic one step further.
What Actually Matters for Laravel Performance?
Here is the mental model that cuts through the benchmark noise: a PHP request is single-threaded, but a PHP server is parallel.
When a request hits your Laravel app, nginx hands it to one PHP-FPM worker process. That worker executes your entire request on a single core: routing, middleware, Eloquent queries, view rendering, JSON serialization. PHP does not spread one request across multiple cores. So the latency of any individual request is bounded by single-thread performance, which is exactly where x86 keeps its edge.
But your server is not running one worker. A well-tuned 8 GB server typically runs 20 to 40 PHP-FPM workers side by side, each handling its own request on whatever core is free. Throughput, meaning how many requests per second the whole box can sustain, is a parallel problem. That is the game ARM was built to win. If you haven't tuned your worker pool, our guide to PHP-FPM worker and memory tuning is the place to start, because an untuned pool will mask any hardware difference entirely.
Where x86 Wins: Latency per Request
Strengths: Higher single-thread performance, typically 15 to 20% by synthetic measures and 20 to 30% in real PHP workloads (bitdoze benchmark). Every individual request completes faster, all else equal. Decades of compiler and library optimization targeting the architecture. Zero compatibility questions, ever.
Best for: Apps where the user experience hinges on a handful of heavy synchronous endpoints. Think report generation in the request cycle, complex Eloquent aggregations on the dashboard, or an API where a partner's SLA measures p95 latency in milliseconds. Also spiky, low-concurrency traffic: if you rarely have more than a few requests in flight, you cannot exploit parallelism, so per-core speed is all that counts.
Considerations: You pay roughly 26% more at Hetzner for the privilege, at the time of writing. If your slow endpoints are slow because of database queries or missing cache, and in our experience they usually are, a faster CPU buys you very little. Profile before you pay for silicon.
Where ARM Wins: Throughput per Euro
Strengths: Better Stack pegs ARM at 20 to 40% better price-performance for parallel workloads (Better Stack). Steady concurrent traffic across many FPM workers is the textbook parallel workload. Lower power draw means providers can keep prices low sustainably rather than as a teaser. Queue workers, schedulers, and Horizon fleets are throughput machines with no human waiting on any single job, which makes them close to a perfect fit.
Best for: Steady multi-user traffic where dozens of requests overlap. Queue-heavy applications processing thousands of jobs per hour. Worker fleets, cron-heavy apps, webhook receivers, and background processing tiers where total jobs per hour matters and per-job latency does not. Budget-sensitive projects where 26% off the hosting bill funds something else.
Considerations: Each individual request runs somewhat slower. On a typical Laravel page that spends most of its wall time waiting on MySQL and Valkey rather than burning CPU, the difference is often single-digit milliseconds and invisible. On a genuinely CPU-bound endpoint, it is measurable. You also take on a small compatibility checklist, covered below.
The genuinely balanced take: neither architecture "wins Laravel." ARM wins Laravel throughput per euro; x86 wins Laravel latency per request. Which one you should optimize for is a question about your users, not your stack.
Is ARM Compatibility Still a Problem in 2026?
For the standard Laravel stack, no. This was a real concern in 2021. It is mostly a solved problem now.
Everything a typical production Laravel server runs has mature arm64 builds: nginx, PHP (every supported version), MySQL, MariaDB, PostgreSQL, Valkey, Redis, Supervisor, certbot, Node.js for asset builds, and Composer, which is architecture-agnostic PHP anyway. Ubuntu publishes arm64 images with identical package coverage for everything above. The popular ondrej PPA, the de facto standard source for PHP on Ubuntu, ships arm64 packages, so PHP installation is literally the same commands:
sudo add-apt-repository ppa:ondrej/php -y
sudo apt update
sudo apt install -y php8.4-fpm php8.4-cli php8.4-mysql \
php8.4-redis php8.4-mbstring php8.4-xml php8.4-curl \
php8.4-zip php8.4-intl php8.4-gd php8.4-bcmath
Not one flag changes between architectures. Your composer install, your .env, your nginx vhost, and your Supervisor configs are all byte-identical. If you can tell which architecture you are on from inside a Laravel codebase, something unusual is going on.
When you do want to check, two commands answer the question:
uname -m # aarch64 on ARM, x86_64 on Intel/AMD
dpkg --print-architecture # arm64 or amd64 (Debian/Ubuntu)
What to Actually Check Before Switching
The remaining rough edges in 2026 cluster in three places, and you can audit all of them in an afternoon.
Closed-source binaries. Anything you download as a precompiled blob rather than install from a package manager deserves a look. Monitoring agents from smaller vendors, license-key-protected PHP tools, proprietary CLI utilities. Most major vendors ship arm64 builds now, but "most" is not "all." Check what you have:
file /usr/local/bin/your-vendor-tool
# ELF 64-bit LSB executable, x86-64 ... -> won't run on ARM
# ELF 64-bit LSB executable, ARM aarch64 -> you're fine
PECL extensions that compile from source. Common extensions like redis, imagick, xdebug, and swoole build cleanly on arm64. Obscure or unmaintained PECL packages occasionally have hand-written x86 assembly or outdated build scripts. If your php -m output contains anything exotic, test-compile it on a throwaway ARM instance before committing.
Docker images without arm64 manifests. If part of your stack runs in containers, verify each image publishes an arm64 variant:
docker manifest inspect ghcr.io/vendor/some-image:latest \
| grep -B1 -A1 '"architecture"'
Official images for PHP, nginx, MySQL, PostgreSQL, and Valkey are all multi-arch. The gaps show up in small vendor images and internal tooling built by a CI runner that only knows amd64.
Here's the twist we hinted at earlier: if your team develops on Apple Silicon Macs, you have been running your stack on ARM for years already. Every M-series MacBook running your app in Docker or Herd is an arm64 environment. The classic "works on my machine" architecture mismatch has quietly inverted. Deploying to an ARM server means production finally matches the laptops, and any arm64-incompatible dependency would have bitten your developers long before it bit production. The short version: M-series adoption did more for arm64 server viability than any vendor announcement.
How Honest Are the Benchmarks?
Benchmark methodology is where ARM-versus-x86 articles quietly mislead people, so let's be explicit about what different tests actually measure.
Synthetic benchmarks like Geekbench multi-core flatter ARM. They saturate every core with math-heavy work, which is the exact scenario Ampere designed for. Real PHP applications spend most of their time in memory access, I/O waits, and branchy interpreted code, not vectorized math loops.
Real-application benchmarks tell a more modest story. The bitdoze ARM vs x86 VPS benchmark, which tested WordPress-style PHP workloads on comparable instances, found x86 ahead by roughly 7 to 10% in raw throughput and 20 to 30% in single-thread performance. WordPress is a reasonable stand-in for PHP frameworks generally: interpreted PHP, MySQL queries, template rendering. Note what happened there: x86 won raw throughput too, just narrowly.
So why do we still say ARM wins throughput? Because the benchmark compares performance at equal specs, not at equal cost. If x86 delivers 7 to 10% more requests per second but costs 26% more, ARM delivers meaningfully more requests per euro. That is the number your hosting bill cares about. Better Stack's 20 to 40% price-performance advantage figure (Better Stack) is exactly this arithmetic applied across their test suite.
The other honesty check: benchmark your app, not someone else's. A Livewire dashboard, a JSON API, and a queue fleet have wildly different CPU profiles. Our methodology from load testing Laravel on a $5 server applies unchanged here: same codebase, same seed data, wrk or k6 against realistic endpoints, and watch p95 rather than averages. Run it against one ARM and one x86 instance for an hour each. The two servers together cost less than a pizza, and you will have real numbers instead of ours or anyone else's.
Which Workloads Fit ARM, and Which Don't?
Here is the decision table we walk through when someone asks us whether to provision CAX or CPX. It compresses everything above into workload shapes.
Workload
Better Fit
Why
Steady web traffic, many concurrent users
ARM
Parallel across FPM workers; per-request latency delta is invisible behind I/O waits
Queue workers / Horizon fleets
ARM
Pure throughput, nobody waits on an individual job; best price per job processed
Scheduled jobs, webhook receivers, cron-heavy apps
ARM
Background throughput, latency irrelevant
Staging, preview, and QA environments
ARM
Cost matters, performance barely does; also validates arm64 before production
Dedicated database server
Either
Databases are memory- and disk-bound first; buy RAM and fast storage, not architecture
Latency-critical API with strict p95 SLA
x86
Single-thread speed directly shortens every request
Spiky, low-concurrency traffic
x86
Few overlapping requests means no parallelism to exploit; per-core speed is everything
Heavy synchronous CPU work (PDF generation, image processing in-request)
x86
CPU-bound single requests feel the 20-30% single-thread gap directly
Anything depending on x86-only closed-source binaries
x86
Compatibility is binary; no discount fixes a tool that won't run
Two patterns fall out of that table. First, the further a workload sits from a waiting human, the better ARM fits. Second, mixed fleets are legitimate: plenty of teams run ARM queue and web tiers behind an x86 box that handles the one CPU-heavy synchronous service. Nothing forces a single architecture across your infrastructure, and if you're still choosing where that infrastructure lives, our cloud provider guide for Laravel developers maps which providers offer ARM at all.
Running ARM Servers on Deploynix
Since we get asked: yes, Deploynix provisions Hetzner's ARM CAX instances the same way it provisions any other server. You pick a CAX plan during server creation instead of a CX or CPX plan, and that is the entire difference in the workflow.
Under the hood, the provisioning stack detects the architecture and installs the identical stack from arm64 package sources: nginx, PHP-FPM (any supported version, or several side by side), MySQL, MariaDB or PostgreSQL, Valkey, and Supervisor. Firewall rules, deploy keys, SSL, zero-downtime deployment structure, all identical. Your deploy script does not know or care that it is running on Ampere cores. The same applies across providers: Hetzner, DigitalOcean, Vultr, Linode, AWS, and custom servers all land on the same stack layout, so an ARM box slots into an existing fleet without special handling.
The genuinely useful part for this article's question is monitoring. Deploynix tracks CPU, memory, and load metrics per server, which means you can run the before-and-after comparison with real data: note your x86 server's CPU utilization and load average under normal traffic, stand up the ARM twin, shift traffic, and compare the same charts a week later. In our experience that graph settles the ARM debate faster than any benchmark blog post, ours included.
How Do You Migrate a Laravel App from x86 to ARM?
You don't. You migrate to a new server that happens to be ARM. This distinction matters: there is no in-place architecture switch. Every binary on the machine is compiled for one instruction set, so the move is a reprovision, and that is actually good news, because reprovisioning is a well-understood, low-risk operation with a built-in rollback.
The shape is classic blue/green at the server level:
1. Provision the ARM server alongside the old one. New CAX instance, same region, same stack configuration. Your existing x86 server keeps serving traffic untouched.
2. Deploy the same release. Same repository, same branch, same .env values pointed at the same database (or a replica if you are moving the database too). Run composer install and your asset build on the new box; both are architecture-transparent.
3. Test against the server's IP directly. Hit the ARM server with your smoke tests and a short load test before any real user does. Edit your local /etc/hosts to point your domain at the new IP for full end-to-end checks. This is where any exotic PECL extension or x86-only binary would surface, safely, with zero user impact.
4. Cut over gradually or atomically. The simple path is a DNS cutover: drop your TTL to 60 seconds a day in advance, then repoint the A record. The cautious path is a load balancer in front of both servers, shifting traffic in stages: 10%, then 50%, then 100%, while you watch error rates and p95 latency. Deploynix's load balancer server type exists for exactly this kind of gradual shift, and it turns an architecture migration into a routing decision you can reverse in seconds.
5. Keep the x86 server warm for a week. It costs a few euros and it is the cheapest insurance you will ever buy. If anything subtle appears, cut DNS back. After a clean week, destroy it and pocket the ongoing savings.
Queue workers are even easier because they need no cutover at all. Point ARM workers at the same Redis or database queue, let both architectures consume jobs side by side, then retire the x86 workers. The queue does not care what processed the job. If you run Horizon, drain the old supervisor gracefully with horizon:terminate and let the ARM fleet absorb the backlog.
Total effort for a typical single-app setup: an afternoon of work spread across a week of caution. Compare that with the effort you'd spend shaving 26% off your hosting bill any other way.
When Should You Not Bother?
Cost optimization has a floor, and honesty demands we mark it.
Skip the switch if your total hosting spend is one small server. Saving €5.50 a month, at the time of writing, does not justify even an afternoon of migration work unless you are doing it for the learning. At that scale your bigger cost question is whether a VPS is right at all, which we tackled in the real cost math of Laravel Cloud's $5 plan vs a $5 VPS.
Skip it if you depend on an x86-only binary you cannot replace. A monitoring agent, a licensed PDF engine, a vendor CLI. One hard incompatibility outweighs any discount, and emulation layers like qemu on a production server are a support ticket generator, not a solution.
Skip it if your p95 latency is already tight against an SLA and your endpoints are CPU-bound. A 20 to 30% single-thread deficit (bitdoze) lands directly on exactly those requests. Buy the faster core; it is the correct tool.
And skip it, for now, if your provider's ARM availability is thin in your region. Hetzner's CAX line is not available in every location, and a cheaper server in the wrong region can cost you more in latency than it saves in euros. Check availability before you plan anything.
Everyone else, which in our experience is the majority of Laravel apps (steady traffic, I/O-bound endpoints, queue-heavy backends), is leaving 26% on the table out of inertia.
FAQ
Does Laravel officially support ARM servers?
Laravel doesn't target an architecture at all; it targets PHP. PHP has shipped first-class arm64 builds for years, and every part of the standard stack (nginx, MySQL/PostgreSQL, Valkey, Supervisor) has mature arm64 packages. If PHP runs, Laravel runs. There is no ARM-specific configuration anywhere in a Laravel codebase.
Will my Composer dependencies work on ARM?
Almost certainly. Composer packages are PHP source code, which is architecture-independent. The only risk lives in compiled PHP extensions (PECL) and any vendored native binaries. Check php -m for exotic extensions and file any bundled binaries. Mainstream extensions like redis, imagick, gd, and intl all build cleanly on arm64 in 2026.
Is ARM actually faster than x86 for Laravel?
Per request, no: x86 completes a single request roughly 20 to 30% faster in real PHP benchmarks (bitdoze). Per euro, yes: at Hetzner's roughly 26% lower ARM pricing at the time of writing, ARM delivers more total throughput for the same spend on concurrent traffic and queue work (Better Stack). Pick the metric that matches your bottleneck.
Can I mix ARM and x86 servers in one setup?
Yes, and it is often the best answer. Architectures share nothing at the HTTP or queue layer, so an ARM queue fleet can consume the same Redis queue as an x86 web tier, and a load balancer can split traffic across both. Many teams run ARM for throughput tiers and keep one x86 box for a CPU-bound service.
How risky is the migration?
Low, if you treat it as a blue/green server swap rather than an upgrade. You provision the ARM server alongside the old one, deploy the same release, test against the IP, shift traffic gradually, and keep the old server for a week as rollback. At no point is your app running on only an untested box.
The Verdict
ARM in 2026 is not a gamble; it is a pricing decision with a known trade-off. You accept 15 to 30% slower single-thread execution in exchange for roughly 26% lower cost at the time of writing, and because PHP-FPM's concurrency model spreads real traffic across many parallel workers, most Laravel workloads convert that trade into more throughput per euro, not less. The exceptions are real (latency-critical endpoints, CPU-bound synchronous work, x86-only binaries) but they are exceptions, and they are identifiable in an afternoon of auditing.
Your next step is cheap and concrete: provision one ARM instance, deploy your actual application to it, and load test it against your current server for a week. A CAX31 costs €15.99 a month at the time of writing, so the experiment costs a few euros and answers the question with your data instead of ours. Once it is up, wire it into your stack the standard way with our production-ready Laravel stack guide and let the monitoring graphs make the call.
