The on-call rotation got paged at 11:47pm a few months ago because a critical kernel CVE dropped. We had three hours to either patch fifty Ampere Altra boxes (a 64-bit ARM server chip) running our CDN edge nodes or file an incident report with our auditors by morning. Three hours, a fleet, and the only sanctioned fix path was a reboot. I sat there with a coffee that had gone cold and a Slack channel full of angry SREs and thought, this is a stupid way to run a server. Canonical quietly shipped the answer to that problem last week, and if you run ARM64 Ubuntu in production, you should be paying attention.
The arithmetic that pushed me over the edge
We do the math every quarter. One unscheduled reboot on a single edge node costs us about twenty-five minutes of operator time, a measurable blip on the regional uptime metric, and a customer-facing status-page entry that the marketing team hates. Fifty nodes is roughly twenty hours of human coordination, three separate change-control windows, and a Friday evening where someone definitely works late. Multiply that by the cadence of critical kernel CVEs, which lands somewhere between four and eight times a year depending on whose advisory list you trust, and the annual cost of the old way is not subtle.
Live patching (a service that hot-swaps patched kernel functions into a running kernel without dropping workloads) has been available for x86 Ubuntu since 2018. Every x86 fleet I have worked on for the last six years has had it on by default, and the only complaint anyone ever has is that it costs money at scale. That is a solved problem on the x86 side. ARM64 was the gap. ARM is everywhere now: AWS Graviton instances (Amazon’s ARM-based cloud servers), Ampere Altra, the chips powering every CDN rack and retail kiosk I have visited in the last three years. The economics of skipping a reboot on those machines are even better than the x86 case, because the alternative is not an annoyed SRE in a comfortable office. The alternative is a truck roll to a remote site.
What is actually shipping
Canonical enabled the kernel infrastructure for live patching on ARM64 across their supported LTS kernels. The mechanism is the same one x86 has used for years. Under the hood, a daemon fetches binary patches built by Canonical, freezes specific functions in the running kernel image, swaps in the patched versions, and resumes execution. From your application’s perspective, the request that was in flight when the patch landed is the same request that completed after the patch landed. No dropped connections. No service interruption. No reboot window negotiated with three teams.
The patches cover security fixes and critical bug fixes. They do not cover new kernel features. If you want a 6.1 feature on your running 5.15 kernel, you still need to upgrade and reboot. The patch surface is narrower than the marketing suggests, and you should plan your kernel upgrades around that. The service also assumes you are on a stock Ubuntu LTS kernel. If you are running a vendor-patched kernel or a custom build, you are back to reboots until the vendor ships their own support.
What it costs and what it does not
The pricing model is the same one x86 has lived under for years. Up to three machines are free under a personal Ubuntu One account. Production fleets pay through Ubuntu Pro subscriptions, which is a per-machine annual fee. For our edge fleet, the math was clear before the announcement. We were already paying for Ubuntu Pro on every box to get extended security support and compliance reporting. Livepatch just showed up as an included feature once the ARM64 infrastructure landed. If you are not already on Ubuntu Pro, the livepatch line item is a real cost that has to live somewhere, and the size of that cost depends on how many machines you actually run.
The hidden cost is the one nobody talks about: you are now depending on Canonical’s patch delivery infrastructure to keep your fleet secure. If their patch servers have a multi-day outage during a critical CVE, you fall back to manual patching. For most teams that is fine. For teams in regulated industries with strict SLA reporting on patch latency, it is a thing you should think about before you rely on it for your most critical systems.
How to turn it on
The setup is genuinely ten minutes if you already have Ubuntu Pro attached. If you do not, the Pro attachment is the longest part. For ARM64 machines running 22.04 LTS or 24.04 LTS, the steps are straightforward.
First, attach the machine to a Pro subscription. The free personal-use token covers up to three machines. For larger fleets, you buy directly from Canonical or pull a subscription from the AWS marketplace if your fleet lives there. Graviton instances get live patching as part of the Pro subscription automatically, with nothing extra to configure.
Then install the livepatch client and authenticate with the token the Pro dashboard gives you. Confirm the daemon is running. That is the whole setup. Patches will start arriving automatically when Canonical publishes them. You can force a manual check if you want to verify right after enabling.
The exact commands are documented in Canonical’s docs, and they are stable across releases. The walkthrough has been the same for six years on x86 and it is the same now on ARM64.
When this is overkill and when it is not
For a single Ubuntu box at home or a hobby homelab, this is more subscription overhead than it is worth. You already reboot your laptop when the kernel updates, and nobody is monitoring your uptime SLA. Skip the Pro step and save yourself the configuration. The economics change at any point where reboots cost real money or real time. That includes most production ARM64 fleets, retail kiosks with on-site technician costs, CDN points of presence where a reboot is a measurable customer-facing event, and edge devices in hard-to-reach locations where a truck roll is the alternative to a software patch.
For our fleet, the call was easy. We were already paying for Pro. We were already losing hours every quarter to coordinated reboots. Livepatch on ARM64 turns those hours into a five-minute background operation that happens automatically. The first time a critical kernel vulnerability lands and our edge fleet just patches itself while the on-call sleeps, the subscription pays for itself for the year.
Trade-offs
Livepatch is not a substitute for kernel upgrades. You will still need to reboot when you move between major Ubuntu releases or when you need new kernel features. The patch surface covers security and critical bugs, not everything that changed between kernel versions. You also need to stay on supported LTS kernels. If you are running an obscure custom build or a heavily patched vendor kernel, you are back to the old way until the vendor ships their own support.
The other honest trade-off is the dependency on Canonical’s delivery infrastructure. Livepatch is not magic that lives inside your kernel. It is a client that pulls patches from Canonical’s servers on a regular cadence. If those servers have a sustained outage during a critical CVE, your fleet does not patch until either Canonical recovers or you fall back to manual patching and reboots. For most teams this is acceptable. For teams that need guaranteed patch latency even during vendor outages, this is something to plan around.
A quick decision rubric if you are on the fence:
- Single home server. Skip the Pro subscription and the livepatch client. You reboot when you feel like it and nobody is monitoring your SLA.
- Small homelab with a handful of boxes. The free personal-use token covers up to three machines and gives you hands-on experience without a budget line.
- Production ARM64 fleet. Subscribe to Ubuntu Pro and enable livepatch before the next CVE lands. The math on avoided reboots alone pays for it.
- Edge devices in hard-to-reach locations. This is the highest-value case. A truck roll costs more than a year of Pro subscription per device.
If you manage more than a handful of ARM64 Ubuntu boxes, attach them to Ubuntu Pro and turn this on before the next CVE drops. If you run a single home server and you reboot it whenever you feel like it, save yourself the subscription and skip it.