What Is AlmaLinux? How to Install It and Migrate From CentOS

What is AlmaLinux and what is it used for?

AlmaLinux is a free, open source enterprise Linux distribution that aims to stay binary compatible with Red Hat Enterprise Linux (RHEL). The community governs it through the nonprofit AlmaLinux OS Foundation. Most people run it on VPS and dedicated servers that host websites, databases and control panels, often as a CentOS Linux replacement.

In this guide we cover where AlmaLinux came from, which release you should pick, how to install it, what to harden first and how to move an existing CentOS server in place. We are Talha Aslan and team, a web design and digital marketing group, not a hosting company. So every technical step here comes from AlmaLinux's official documentation, its release notes and the README of the official migration tool.

We wrote it for two kinds of readers. The first is a site or store owner who wants to understand what their server runs and why it matters. The second is a developer who manages their own VPS and wants commands in the right order. For both, we also list the cases where you should not do this yourself.

Where did AlmaLinux come from?

The story starts with CentOS Linux. For years it was the free rebuild of RHEL source code and the default choice across the hosting industry. Then the project changed direction. According to the official CentOS page, CentOS Linux 8 reached end of life on December 31st, 2021. CentOS Linux 7 later reached its end of life too, and the CentOS name now lives on as CentOS Stream.

That shift left a lot of server owners without a stable, long-lived RHEL rebuild. AlmaLinux appeared to fill that gap. Today the AlmaLinux OS Foundation, a US nonprofit, runs the project. In other words, the future of the distribution does not hinge on one vendor's commercial plans; the foundation board and community processes set the direction.

In short, AlmaLinux positioned itself as "the thing that behaves like CentOS, but with community governance behind it". Rocky Linux appeared with a similar goal. We compare the two in a separate article, so here you will only get a short summary.

How compatible is AlmaLinux with RHEL?

This question matters because the answer changed in mid 2023. At first, AlmaLinux aimed to be a one to one, bug for bug copy of RHEL. After Red Hat changed how it shares source code, the AlmaLinux board picked a new path. According to the foundation's announcement from July 13, 2023, AlmaLinux now aims for binary (ABI) compatibility instead of an exact clone.

So what does that mean in practice? Software built for RHEL should still run on AlmaLinux. On the other hand, AlmaLinux can now ship a security or bug fix without waiting for Red Hat. Put simply, the bug for bug promise is gone, while the application compatibility promise stays.

For most site owners this change is invisible. WordPress, Laravel, Node.js or a hosting panel that runs on the RHEL family will also run on AlmaLinux. However, if you rely on certified enterprise software, such as a commercial database or a security agent, check that the vendor officially supports AlmaLinux before you commit.

Which AlmaLinux version should you choose?

AlmaLinux follows RHEL's major version numbers: 8, 9 and 10. Each major release first gets "active support" and then a longer phase with security updates only. The dates below come from the official AlmaLinux release notes. We still suggest you recheck that page before you decide.

Our advice is simple. For a new server, choose the newest major release that your control panel and your applications support. For example, if your panel vendor does not support 10 yet, start with 9. There is also AlmaLinux Kitten, a development stream that tracks CentOS Stream. That one is for testing and previews, not for a live website.

What do you need before installing AlmaLinux?

A few decisions up front will save you a reinstall later. If you rent a VPS, your provider almost certainly offers a ready AlmaLinux image in its control panel. In that case you can skip the ISO entirely and deploy in one click. For dedicated hardware or your own hypervisor, prepare the following:

• CPU architecture: check whether the machine is x86_64 or aarch64 (ARM) and download the matching ISO.
• Console access: your provider should offer VNC, IPMI or a similar remote console. That is what saves you when SSH drops.
• Disk layout: decide on a single disk or RAID before you start.
• Network details: have the static IP, gateway and DNS resolver values ready.
• Purpose: if you plan to install a control panel, pick the install type that the panel expects, which is usually a minimal install.

If you have not picked a server type yet, first read our guide to VPS vs cloud server vs VDS. The operating system decision comes after the server decision, not before.

How do you download and verify the AlmaLinux ISO?

Download the ISO only from the official AlmaLinux download page or from the official mirrors it lists. If you are curious how mirrors work, our Linux package mirror guide explains how dnf uses a mirrorlist to pick a nearby mirror. You will usually see three image types: a small "boot" image that installs over the network, a "minimal" image with core packages and a full "dvd" image. For a server, minimal is usually enough.

After the download, confirm that nobody tampered with the file. Grab the CHECKSUM file from the same folder and the GPG key from the official AlmaLinux repository. Then check the signature and the hash.

gpg --import RPM-GPG-KEY-AlmaLinux-9
gpg --verify CHECKSUM
sha256sum YOUR_IMAGE.iso

You are looking for two things. First, the gpg output should report a "Good signature". Second, the hash from sha256sum must match the line in the CHECKSUM file exactly. If either check fails, delete the file and download it again from another official mirror. Also note that the key file name follows the major release, so use the matching key for 10.

What are the AlmaLinux installation steps?

AlmaLinux ships with Anaconda, the graphical installer you may know from other RHEL family systems. After you attach the ISO to the server, or write it to a USB stick, follow these steps:

1. Boot the server from the ISO and choose the install option in the boot menu.
2. Pick language and keyboard. On a server, keeping the system language in English makes error messages easier to search.
3. Open Installation Destination and select the disk. If you are unsure, use automatic partitioning.
4. Open Network and Host Name, enable the network card, enter a static IP if needed and name the machine.
5. In Software Selection, choose Minimal Install or Server. A desktop environment only adds load and attack surface.
6. Set a root password and create a separate user with administrator rights.
7. Start the install, remove the ISO when it finishes and reboot.

If you used your VPS provider's image, the provider handles most of these steps for you. In that case, jump straight to the next section on first settings. Even with a ready image, though, review the root password, SSH keys and hostname on your first login.

Which settings should you change right after installation?

The first login checklist is short but important. First, update every package. Next, set the hostname and the time zone. After that, create an admin user for daily work instead of using root.

sudo dnf update -y
sudo hostnamectl set-hostname server.example.com
sudo timedatectl set-timezone Europe/London
sudo useradd -m -G wheel admin
sudo passwd admin

Here the "wheel" group gives the new user sudo rights. The clock also matters more than it looks, because a wrong time breaks SSL checks and makes log analysis painful. For proper time sync, see our NTP and chrony guide.

Then lock down SSH. Copy an SSH key from your own computer to the new user, test that key login works and only then turn off password login.

ssh-copy-id admin@203.0.113.10

Next, set PermitRootLogin and PasswordAuthentication to "no" in /etc/ssh/sshd_config, or in a drop in file under sshd_config.d depending on your release, and reload the SSH service. One warning: keep your current session open while you do this and test the new login from a second window.

Why should you keep SELinux enabled?

SELinux is the mandatory access control layer that AlmaLinux enables in "enforcing" mode by default. Even if an attacker takes over a service, SELinux limits that service to the files and ports it may use. Sadly, many older tutorials say "just disable SELinux" at the first error message. We recommend that you understand the problem instead.

getenforce
sestatus

If the first command returns "Enforcing", you are fine. When SELinux blocks an app unexpectedly, look at the audit log first. For example, if your web server cannot open a network connection to another service, a ready SELinux boolean covers exactly that case. If you moved files from another folder, restoring their labels often solves the issue.

sudo ausearch -m avc -ts recent
sudo setsebool -P httpd_can_network_connect on
sudo restorecon -Rv /var/www/html

In other words, turning SELinux off is like removing the hinges instead of locking the door. That said, some hosting panels set their own SELinux requirements during setup. In that case, follow the instruction in the panel's official install guide rather than guessing, and write the decision down.

How do you set up a basic firewall with firewalld?

firewalld is the default firewall manager on AlmaLinux. The idea is simple: it defines zones, and you add the services you allow to each zone. For a web server, SSH, HTTP and HTTPS are usually enough.

sudo systemctl enable --now firewalld
sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reload
sudo firewall-cmd --list-all

The "--permanent" option makes a rule persistent, and "--reload" applies the persistent rules. In the output of the last command you should see ssh, http and https. Do not expose your database port, such as MySQL, to the internet; if the app runs on the same server, you do not need to.

Things can change once you add a panel like cPanel. Some admins prefer a firewall that ships with or fits the panel instead of firewalld. We cover that option in our CSF firewall guide. We also suggest adding Fail2ban against brute force SSH attempts. Above all, never run two firewall managers at the same time, because they can overwrite each other's rules.

Should you automate AlmaLinux updates?

Automatic security updates are the step small teams skip most often, yet they pay off the most. On the RHEL family, the dnf-automatic package handles this. You install it, tell the config file to apply security updates only and then enable the timer.

sudo dnf install dnf-automatic
sudo systemctl enable --now dnf-automatic.timer

The config file lives at /etc/dnf/automatic.conf. There you set upgrade_type to "security" and apply_updates to "yes", so only security patches install on their own. Because package and timer names can change in new major releases, confirm them in the docs for your release.

So should you automate everything? Our approach is security patches on autopilot, while large upgrades and kernel changes stay under control. On a server that runs an online store, an update that forces a reboot at peak time means lost sales. Therefore, plan kernel reboots for your quietest hours.

Update speed also depends on your package repositories. By default, AlmaLinux uses a mirrorlist to pick a nearby mirror, and the dnf repolist command shows which repositories you have enabled.

Which path should you take to migrate from CentOS to AlmaLinux?

There is no single right way to move from CentOS to AlmaLinux. You decide based on your CentOS release, how much downtime you can accept and how much the server has been hand tuned over the years. The table below sums up the options:

Here is what we see as the practical rule. On a server that many developers have touched over the years, an in place migration tends to surface hidden surprises, so a fresh install usually causes less stress. In contrast, on a tidy, documented, single purpose server, the in place route is fast and safe.

How should you plan backups and testing before migrating?

Even the official migration tool's README carries a clear warning: its authors did not test every possible scenario, so something can go wrong. Therefore, a backup is not optional; it is the entry ticket. First, complete this list:

• On a virtual server, take a full snapshot from your provider's panel.
• Copy files and databases off the server. For the database side, use our mysqldump and pg_dump guide.
• Prove that the backup actually restores by testing it in a separate environment.
• Write down enabled repositories, third party packages and custom settings in a text file.
• Pick a maintenance window and tell your customers or team ahead of time if needed.

If you can, run the migration on a copy of the live server first. Spinning up a temporary server from the snapshot and migrating it shows most of the issues you would hit in production. For the bigger picture, our website backup strategy guide explains the 3-2-1 rule in detail.

How do you migrate in place with almalinux-deploy?

almalinux-deploy is the AlmaLinux team's official migration script. According to its README on GitHub, it converts CentOS Linux 8.4 or newer, CentOS Stream, RHEL, Oracle Linux and Rocky Linux to AlmaLinux of the same major release. We do not recommend the "download and run in one line" habit you see online. Instead, download the script, read it and then run it.

Start by updating the system and rebooting, so you migrate from the latest kernel.

sudo dnf update -y
sudo reboot

After you reconnect, open your session inside screen or tmux. The README recommends this, or a console such as IPMI, iLO or VNC, so the process survives a dropped SSH connection. Then download the script and look through it.

curl -O https://raw.githubusercontent.com/AlmaLinux/almalinux-deploy/master/almalinux-deploy.sh
less almalinux-deploy.sh

Once you have reviewed the repository URLs and the packages it removes and installs, run it and reboot when it finishes.

sudo bash almalinux-deploy.sh
sudo reboot

If the script hits an unsupported setup, such as a different bootloader, it stops with a warning. Do not try to force your way past that warning; fix the cause first.

What should you check after the migration?

A finished reboot does not mean a finished migration. Start with the two checks the README suggests: one shows the release file, and the other confirms that the default kernel is an AlmaLinux kernel.

cat /etc/almalinux-release
sudo grubby --info DEFAULT | grep AlmaLinux

Then move on to your services. The list below collects the points people miss most often:

1. Confirm with systemctl status that the web server, PHP and database services run.
2. Make sure no old CentOS repositories remain in the dnf repolist output.
3. Check that third party repositories such as EPEL point to the right release.
4. Test the home page and critical flows like login and checkout in a browser.
5. Confirm the SSL certificate still serves correctly with our SSL checker.
6. Watch scheduled jobs (cron) and outgoing email for a few hours.

If something breaks, do not panic. With a snapshot, rolling back takes minutes. For that reason, keep the snapshot until the server has run cleanly for several days.

What about servers still on CentOS 7?

A CentOS 7 server cannot move to AlmaLinux with almalinux-deploy, because the tool works within the same major release and needs CentOS 8.4 or newer. The official route for that release is ELevate, a project AlmaLinux runs. According to the ELevate documentation, it uses the Leapp utility to upgrade between major releases of RHEL rebuilds and supports CentOS 7 to AlmaLinux 8.

There is one critical detail. ELevate performs one step upgrades only. So if you want to go from CentOS 7 to the newest major release, you split the process: first 8, then test, then 9 and, if needed, 10. Each step needs its own backup, test and rollback plan.

Let us be frank here. On a CentOS 7 server that has gone without security updates for a long time, chaining several in place upgrades is rarely the most efficient path for a web project. We usually suggest a new AlmaLinux 9 or 10 server, a clean move of the app and data and then a DNS switch. During that move, double check that your DNS records point to the new IP address.

Does AlmaLinux work with cPanel and Plesk?

Yes, both panels support AlmaLinux, but the version details matter. The cPanel system requirements page lists AlmaLinux OS, CloudLinux, Rocky Linux and Ubuntu among the supported operating systems. Which major release it supports depends on the panel version, so check the relevant sub page before you install.

The same goes for in place migration. The almalinux-deploy README lists cPanel, Plesk (18.0.35 and later) and DirectAdmin as supported panels. Still, read the panel vendor's own migration notes before you start on a server that runs a panel. The reason is that the panel license, the panel's own repositories and its update mechanism can all react to the switch.

If you are on shared hosting, none of this falls on you, because your host manages the operating system. You still control site settings like the PHP version from the panel, so that is where your day to day changes happen.

How does AlmaLinux differ from Rocky Linux and CentOS Stream?

All three belong to the RHEL family, but they play different roles. AlmaLinux and Rocky Linux are RHEL compatible production distributions with long support windows. CentOS Stream, by contrast, is the development stream where changes land before the next RHEL minor release. In other words, Stream runs ahead of RHEL, while AlmaLinux and Rocky run alongside it.

For most web projects, the choice between AlmaLinux and Rocky Linux is not about technology but about preference: governance, community, panel and host support. We have two separate articles that compare the two in depth and explain who CentOS Stream suits, so we will not repeat them here. The short answer: for a live website or online store, choose a stable distribution, AlmaLinux or Rocky, and keep Stream for testing.

Whichever distribution you choose, the real difference comes from maintenance discipline: regular updates, backups, a firewall and monitoring. We gathered the other server criteria in our guide on how to choose web hosting.

When should you not do this yourself?

To be honest, installing AlmaLinux or migrating a server is not a job every site owner should take on. In these cases, we suggest you leave it to your hosting provider or an experienced sysadmin:

• The server runs an online store that takes payments, and downtime means lost revenue.
• You have no remote console, so a dropped SSH session locks you out.
• Your panel license (cPanel, Plesk) comes through the host, and the host offers a managed migration.
• Nobody knows who installed what on the server, and the documentation is thin.
• You have no time to prove that your backup restores.

On the other hand, on a test server, a personal project or a well documented single purpose VPS, you can follow this guide with confidence. The key is to judge the size of the risk honestly. In our web projects, we treat infrastructure as part of the site itself; our web design service also covers server choice and the launch process.

Does AlmaLinux affect your site speed and SEO?

The operating system is not a ranking factor on its own. Google neither knows nor cares whether your site runs on AlmaLinux or Ubuntu. However, there is an indirect effect: an up to date, well configured server with little downtime responds faster and throws fewer error pages.

For example, on an old CentOS server it gets harder to install a current PHP release, and old PHP means both slowness and security risk. A newer AlmaLinux release makes current PHP and web server packages easier to reach. That can bring speed gains, but they do not come for free; you also need caching, compression and app tuning.

After the migration, watch your server response time, and if things slow down, look for the cause on the server side. We cover that in our article on server side causes of a slow website. Also, if the move changes URLs or domains, plan redirects and crawl checks so search visibility stays intact.

Summary: a short AlmaLinux checklist

If we boil the whole guide down to one list, you get the order below. It works for both a fresh install and a CentOS migration.

1. Pick the newest AlmaLinux major release that your panel and apps support.
2. Download the ISO from an official source and verify the GPG signature and SHA256 hash.
3. Do a minimal install, then update the system with dnf update.
4. Create an admin user, switch to SSH keys and disable root login.
5. Keep SELinux enabled and open only the services you need in firewalld.
6. Automate security updates with dnf-automatic.
7. Before migrating, take a snapshot and an off server backup, then test the restore.
8. For an in place migration, download the script, read it, run it inside screen and verify the result.

In short, AlmaLinux fills the gap that CentOS left with a stable, community governed option. If you pick the right release, install it with safe steps and protect the migration with backups, your server will keep receiving security updates for years.