Status
With the 2026 Ubuntu LTS release, we’re seeing evolution instead of revolution across the board. Mostly small version updates, a recent kernel in version 7, and many updates under the hood.
An overview of available software versions for the most commonly used services can be found in our documentation.
What Does It Take to Implement a New Ubuntu Version?
Have you ever asked yourself what it takes us to implement a new Ubuntu LTS version in our ecosystem? It’s a little more complicated than imaging a USB stick. We’ll take you through our implementation journey.
An Early Look
On April 23, 2026, Ubuntu Resolute was publicly released, with a “Beta” preview a month prior.
Shortly after the Beta release, we had a first look at the new release. With clarity about the used Ruby version, we knew what it would take to update our self-service tools such as nine-manage-vhosts, nine-manage-databases, and FTPAdmin2. We also run some tools not directly used by customers but of importance to us and our automation landscape.
Following our first hands-on, we created the backlog items we considered mandatory for the implementation.
Step by Step
The first issue to solve was around the package manager and package sources. With some deprecations in apt 3.1, updates for our automation around our package mirrors (we mirror the Canonical repositories for all Ubuntu versions) as well as package sources became necessary.
After addressing these first issues, we needed to build a “packagebuilder” image for the new Ubuntu version. This container image is used in automated pipelines to build Debian packages like nine-manage-vhosts and nine-manage-databases, but also Prometheus exporters.
Prometheus is used for monitoring at Nine, and exporters are the metrics source our alerting is based on. We build more than 20 exporters that aren’t uniformly designed and need customisations in their build processes.
To test these packages in a “real” system environment (as opposed to a container, where things like systemd are missing), we built a VirtualBox VM image of Ubuntu Resolute, which we use to run tests of our self-built packages.
Once we had finished building our automation and monitoring tools, we could dive deeper into the automation of our Managed Services.
With Ubuntu Resolute, many services got updated systemd units and AppArmor profiles. This improves security but also required some changes and tests, for example to our Apache and MariaDB automation.
One of the changes to systemd resulted in /tmp partitions or folders that are no longer backed by system storage. Instead, /tmp uses a tmpfs partition type, which uses system memory to store data.
System memory is valuable, and many applications and services use /tmp for short-lived data that might require quite some storage. A tmpfs partition doesn’t meet our requirements for a server environment, so we reverted to a storage-based solution.
Most of these tasks are independent of the type of system, virtual or dedicated. But of course, we also needed to adapt our automated dedicated server provisioning for Ubuntu Resolute.
A Little Revolution
In the past years, the companies behind Elasticsearch and Redis have tried to further commercialise their open-source services and changed the licensing model of their software.
Although both companies have since returned to open-source licenses, rebuilding lost trust is difficult. In the meantime, the open-source ecosystem has continued to evolve.
In our offering, Elasticsearch has since been superseded by OpenSearch.
After Redis announced a license change in 2024, we thought we were prepared, as we had already implemented KeyDB as an alternative a year before. What looked promising at first (e.g. Redis compatibility, the possibility to run multi-primary replication) has turned out to be a dead end: the KeyDB project has since been abandoned.
In 2024, following the license change, another Redis fork named Valkey was released. Broad support from industry leaders such as AWS, Google Cloud, Percona, Oracle, and more has helped Valkey gain momentum quickly and establish itself as the de facto alternative to Redis.
With Ubuntu Resolute, Valkey 9 has found its way into the Ubuntu “main” repository. The main repository contains software that’s supported by Canonical during the entire lifecycle of the Ubuntu release.
As Valkey in version 9 is fully compatible with Redis 7.2.4, and Redis remains in the “universe” repository (a “community maintained” repository), the decision to use Valkey from Ubuntu Resolute onward was an easy one for us: fully compatible with the latest Redis version we offered (7.0 in Ubuntu Noble), but actively supported throughout all lifecycle phases of Ubuntu.
Engineering Summary
This implementation journey doesn’t just provide a broad overview of some technical challenges, it also gives an idea of how Nine engineers work and which tools and processes we use.
Many of the backlog items iteratively built on each other. Besides the engineering and quality control effort, we also need to ensure that changes don’t cause side effects on older Ubuntu versions, since all versions are automated through the same codebase.
After 76 merge requests linked to 20 backlog items, the first Ubuntu Resolute systems were delivered to our customers on June 29, 2026.
