A reliable cPanel server starts before the installer runs. Storage layout, hostname, DNS, static addressing, time, supported operating system, and repository state determine whether the control panel remains maintainable after the first reboot.
As of August 2026, cPanel’s current AlmaLinux system requirements list AlmaLinux 8 as supported for cPanel & WHM 110 or later. That is a current compatibility statement, not a reason to choose the oldest supported OS for every new long-lived server. Compare lifecycle, application, CloudLinux, backup, and migration requirements before provisioning.
Treat the VM as Disposable Until Preflight Passes
cPanel requires a freshly installed operating system and has no uninstaller. Its official installation guide states that removal requires reformatting. Take a hypervisor snapshot only as a short pre-install rollback point—not as the server’s future backup strategy.
Start from an official minimal AlmaLinux image, give the VM a static IPv4 address, and avoid installing Apache, MariaDB, PHP stacks, third-party repositories, desktop environments, or licensing scripts first. The cPanel installer supplies the services it expects; preinstalled conflicts can cause installation failure.
Record:
- VM CPU, memory, and virtual disk allocation;
- network address, prefix, gateway, and resolvers;
- FQDN and forward/reverse DNS ownership;
- cPanel and optional CloudLinux licence plan;
- backup destination outside the VM;
- console access if networking fails.
Choose a Storage Layout for Failure Behaviour
cPanel does not require five virtual disks. Separate filesystems are operational boundaries: they can prevent one workload from consuming the entire root filesystem, but they also create fixed capacities that must be monitored and expanded correctly.
Three practical layouts are:
| Layout | Advantages | Trade-off |
|---|---|---|
One XFS filesystem for / plus swap | Simple growth and recovery | User data, logs, databases, and OS share one free-space pool |
/ plus a large /home | Hosting accounts cannot consume root as easily; simple account storage growth | Mail, database, and log growth still affect root unless planned |
Separate /, /home, and /var | Stronger capacity boundaries for accounts and service data | More sizing decisions and more ways to fill one filesystem while others remain free |
For a general shared-hosting VM, a large /home is often the most useful separation because cPanel uses /home as the default account directory; the current installation customisation reference documents HOMEDIR=/home and how home partitions are matched.
Do not make /var small. Databases, logs, package caches, queues, and other service state can grow there. A dedicated /tmp is optional; cPanel also documents its securetmp mechanism. Its server security guidance recommends a separate /tmp with nosuid and discusses applying noexec after installation. Test application compatibility before enforcing restrictive mount options.
Swap is not a substitute for RAM. A modest swap area can absorb a short spike and provide diagnostic time, while sustained swapping means the workload is undersized. Size it from workload and crash-dump requirements, not a fixed “twice RAM” formula.
Validate Filesystems and Periodic TRIM
On a virtualised SSD or thin-provisioned datastore, discard must pass through every layer: guest filesystem, virtual disk/controller, hypervisor, and backing storage. Check before enabling automation:
lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINTS
lsblk --discard
findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS
Red Hat’s official RHEL 8 discard guidance recommends batch or periodic discard for normal use and documents the systemd timer:
systemctl enable --now fstrim.timer
systemctl status fstrim.timer
systemctl list-timers fstrim.timer
fstrim --all --verbose
Run the manual command once and read the result. “Discard not supported” is a storage-path finding, not a reason to add the discard mount option blindly. Red Hat notes that continuous online discard can have a performance cost and recommends periodic fstrim in many cases.
Do not edit /etc/fstab just to make TRIM work. The timer operates on eligible mounted filesystems without adding discard to every mount.
Establish Hostname, DNS, and Static Networking
cPanel requires a registered, resolvable FQDN that does not match a hosted account domain or reserved service name. Use a pattern such as host01.example.net, create its A record, and arrange PTR with the address owner.
Check before installation:
hostnamectl
hostname -f
getent ahostsv4 host01.example.net
ip -brief address
ip route
cat /etc/resolv.conf
timedatectl
The FQDN must resolve to the server’s main address, and the server needs outbound DNS and HTTPS. cPanel requires a publicly visible static IPv4 address; an IPv6-only host or ordinary dynamic/private address is not eligible. A NAT deployment needs supported 1:1 NAT and NAT loopback.
On AlmaLinux 8, the current cPanel installer automatically disables NetworkManager and enables the legacy network.service. cPanel’s NetworkManager documentation warns that incorrect manual changes can disconnect the server. Have hypervisor console access and let the supported installer perform its expected transition unless the current requirements instruct otherwise.
Run a Read-Only Preflight
cat /etc/almalinux-release
uname -m
free -h
df -hT
df -ih
dnf repolist
dnf check
curl -I https://securedownloads.cpanel.net/latest
Confirm 64-bit x86, supported resources, sufficient free space and inodes, a clean package transaction, and only expected repositories. cPanel’s current minimum is 2 GB RAM and 20 GB disk, with 4 GB RAM and 40 GB disk recommended; real hosting workloads often need substantially more. The installer and upgrades also require working space under /usr/local/cpanel.
Update the base OS and reboot into the current kernel before installation:
dnf clean all
dnf -y update
reboot
After reboot, repeat hostname, networking, time, disk, DNS, and package checks. A successful update before installation is valuable evidence that repositories and boot configuration are healthy.
Install Only from the Official Source
From an interactive root session that will survive disconnects, use the current command published by cPanel:
cd /home && curl -o latest -L https://securedownloads.cpanel.net/latest && sh latest
Prefer a console, tmux, or screen session and preserve the installer log. Do not combine the installation with third-party curl | bash licensing commands. cPanel and commercial web-server products require legitimate licences from their publishers or authorised channels. An unauthorised script that replaces binaries or modifies startup jobs creates a persistent supply-chain and recovery risk.
If the server’s IP has an active CloudLinux licence, cPanel warns that installation may automatically convert the host. Decide intentionally whether to remain on AlmaLinux or deploy CloudLinux. For a later authorised conversion, follow CloudLinux’s current cPanel conversion documentation and verify that the exact AlmaLinux minor version is supported. Do not enable testing repositories to force missing packages into a production control panel.
Validate Before Adding Accounts
After installation, do not stop at “WHM opened once.” Check:
/usr/local/cpanel/cpanel -V
/usr/local/cpanel/scripts/restartsrv_cpsrvd --status
ss -ltnp
systemctl --failed
journalctl -p err -b --no-pager
df -hT
df -ih
Complete WHM’s initial setup, configure resolvers and nameservers, verify the hostname certificate, review the update tier, configure an authenticated firewall, and set remote backups. Test WHM from an external authorised client, then reboot once and repeat service, socket, DNS, storage, and web checks.
Do not diagnose an external access problem by pasting an HTTPS URL into Bash; use curl, openssl s_client, ss, firewall counters, and a browser from the actual client network. A listening local service proves the process is alive, not that routing, firewall, NAT, TLS, and client access all work.
Finally, create one nonproduction account and verify DNS, HTTP/HTTPS, PHP, database, mail routing if enabled, quota behaviour, backup, restore, and log rotation. Only then should the VM leave the disposable-build stage.
A clean cPanel deployment is a controlled sequence: supported minimal OS, deliberate storage, verified hostname and network, current packages, the official installer, licensed components, and a post-reboot acceptance test. Skipping those gates saves minutes during installation and can cost hours during the first failure.
