Linux server distributions: Ubuntu, AlmaLinux, Rocky Linux, Arch Linux and openSUSE

Our daily base is Debian, covered on its own dedicated page. This page covers everything else: Ubuntu Server, which we manage regularly, and the distributions we support on request - AlmaLinux, Rocky Linux, Arch Linux, openSUSE. We help you choose the family that suits your workload, keep it running with method, and migrate when a platform reaches end of life.

Overview

Server distributions fall roughly into three families, plus one exception. The Debian/Ubuntu family uses the apt package manager: a vast ecosystem, plentiful documentation, LTS releases with years of guaranteed support. The RHEL derivatives we support - AlmaLinux and Rocky Linux - use dnf and offer binary compatibility with the enterprise ecosystem and lifecycles around a decade long: the natural path for anyone coming from CentOS. openSUSE uses zypper and tools like YaST, with a tidy approach to configuration. Arch Linux is that exception: rolling release and always-current packages, a sensible choice only in specific scenarios and with closely watched updates.

Commands, repositories and release calendars change, but the principles we apply don’t: reproducible installs, planned updates, every choice written down somewhere. That’s why we can support different families without improvising: the method stays the same, only the syntax adapts.

Typical problems we solve

• CentOS has reached end of life and the servers no longer get patches → we convert them to AlmaLinux or Rocky Linux without reinstalling from scratch.
• The server fleet mixes three or four distributions and nobody knows them all → we consolidate onto a consistent base and document what remains.
• A new project is starting and the distro choice is stuck at opinions → we analyse workload, ecosystem and lifecycle and put the proposal in writing.
• Updates keep getting postponed for fear of breaking something → we schedule them in agreed windows and test them in staging first.
• An enterprise application requires an RHEL-compatible platform → we set up AlmaLinux or Rocky Linux with the correct repositories and hardening.
• The previous provider left servers with no documentation → we rebuild the inventory of packages, services and configurations and hand it over in writing.
• The release upgrade is years behind → we define a staged path, each step with a backup and a rollback plan.

What’s included

• Choosing the distribution: assessment of your real workload, application ecosystem and the years of support you need, with a reasoned, written opinion.
• Installation and provisioning: a clean base on bare-metal or cloud, partitioning, users and essential services configured with judgement.
• Package management: tidy repositories and controlled versions with apt, dnf, zypper or pacman, every install tracked.
• Updates and release upgrades: regular security patches and planned version advances, tested before they reach production.
• Migrations: converting CentOS to AlmaLinux or Rocky Linux, or consolidating mixed fleets onto a single family.
• Hardening and maintenance: hardened SSH, firewall, services trimmed to the minimum and correct permissions, with the same rigour on every family.

Stack and technologies

On Ubuntu Server we work with apt and favour LTS releases when longevity matters. On AlmaLinux and Rocky Linux we use dnf, the official repositories and EPEL where appropriate, leaning on RHEL binary compatibility for low-risk conversions. On openSUSE we manage packages with zypper, on Arch Linux with pacman. On top of these bases runs the stack our projects typically use: Nginx or Apache, PHP, MariaDB or PostgreSQL, Redis, with systemd governing services.

Provisioning goes through readable scripts or Ansible once the number of machines justifies it; Terraform comes into play only where infrastructure complexity genuinely makes it worthwhile. In the cloud, Google Cloud is the first choice, with AWS and DigitalOcean as alternatives; on request we also work on Hetzner and OVH. Versioned files and explained choices, on every family.

A real-world example

A software house had six CentOS 7 servers that had fallen out of support, with clients’ PHP applications still in production and no appetite for reinstalling everything. We inventoried packages, third-party repositories and active services, then trialled the conversion to AlmaLinux on a staging clone: an abandoned repository and two hand-compiled libraries turned up, and we fixed them before touching production.

The real machines were converted one at a time, in agreed windows, each with a full backup and a rollback plan. The applications needed no changes. In the end, the six servers were back inside a support cycle, with security updates active again, and the in-house team reused the documented procedure for the smaller machines.

Who it’s for

• Companies and teams that already have a distribution in house and want to manage it with method, without changing it just for the sake of it.
• Anyone coming from CentOS who needs to move to AlmaLinux or Rocky Linux before the lack of support turns into an incident.
• Software houses and agencies with mixed fleets looking for consistency and a single point of contact.
• Projects with enterprise constraints that require compatibility with the RHEL ecosystem or long lifecycles.

How we work

We start from the services that need to run and from your context, then propose the most suitable distribution with a reasoned opinion: if the right answer is to stay where you are, we’ll tell you. Installations, migrations and upgrades go through staging, with backups and a rollback plan ready before touching production, and wrap up with a report explaining what changed and why.

Standard coverage runs Monday to Friday, 10:00-18:00 , with priority triage described on the response times page. For recurring maintenance, hour packages that never expire are the better fit. Whichever family you choose, the system stays yours: open, documented configurations, with no lock-in.