Rocky Linux 9 has been a solid, stable foundation since its release in mid-2022. Rocky Linux 10 arrived in 2025 with a significantly updated kernel, toolchain, and runtime stack. If you are deciding whether to stay on Rocky 9 or move new workloads — or existing ones — to Rocky 10, this comparison gives you the technical specifics to make that decision based on facts rather than changelog headlines.
- Rocky Linux 10 ships kernel 6.12 (vs Rocky 9's 5.14), GCC 14 (vs 11), Python 3.12 (vs 3.9), and glibc 2.39 (vs 2.34)
- Rocky 9 reaches End of Full Support in May 2027; End of Life in May 2032. No urgent migration pressure for existing workloads
- Rocky 10 enforces cgroup v2 exclusively — cgroup v1 applications need to be updated before migrating
- For new server deployments in 2026, Rocky 10 is the right default. For existing certified or legacy-app workloads, Rocky 9 with a planned migration path is the pragmatic choice
- Hosting panels supporting Rocky 10 include Panelica (first-class). Legacy panels vary — check vendor-specific status before committing
Why Rocky 10 Now? Release Timeline and End-of-Life
Rocky Linux follows the Red Hat Enterprise Linux (RHEL) lifecycle. Rocky 9 is based on RHEL 9 and Rocky 10 tracks RHEL 10, which shipped as General Availability in May 2025.
| Release | GA Date | End of Full Support | End of Life |
|---|---|---|---|
| Rocky Linux 9 | July 2022 | May 2027 | May 2032 |
| Rocky Linux 10 | June 2025 | May 2030 | May 2035 |
Rocky 9 still has years of full support ahead. This is not an urgent migration. The practical reason to move to Rocky 10 for new deployments is that you get a 5-year support horizon from today rather than a shrinking one, plus a modern runtime stack that will be the standard for the next decade of enterprise Linux software.
Kernel, Toolchain, and Runtime Changes
This is where the concrete differences are. Rocky Linux 10 ships significantly newer versions of every core component:
| Component | Rocky Linux 9 | Rocky Linux 10 | What It Means |
|---|---|---|---|
| Kernel | 5.14 | 6.12 | Two major kernel versions. io_uring improvements, better BPF support, updated driver stack |
| GCC | 11 | 14 | Newer C++ standard support (C++23), improved auto-vectorization, better diagnostics |
| Python (system) | 3.9 | 3.12 | Significant performance improvements, match statements, improved typing |
| glibc | 2.34 | 2.39 | Newer binaries compiled against glibc 2.35+ will run. More security mitigations |
| systemd | 252 | 257 | Improved service management, credential handling, better cgroup v2 integration |
| OpenSSL | 3.0 | 3.2 | TLS 1.3 improvements, QUIC transport layer support (used by HTTP/3) |
| LLVM/Clang | 14 | 18 | Rust and LLVM-ecosystem tooling improvements |
| Node.js (default) | 16 | 20 | LTS version shift, V8 engine updates, native fetch API |
| Ruby | 3.0 | 3.3 | Performance improvements (YJIT enabled by default) |
| Perl | 5.32 | 5.40 | Modern Perl features, performance improvements |
| Go (toolset) | 1.18 | 1.22 | Improved garbage collector, range-over-integer, compiler optimizations |
The glibc upgrade deserves particular attention. If you compile software on Rocky 9 (glibc 2.34), that binary will run on any system with glibc 2.34 or higher. But if you compile on Rocky 10 (glibc 2.39), the binary requires glibc 2.39+ and will fail on Rocky 9 or older Debian/Ubuntu releases. This matters for distributed binaries and self-compiled daemons.
Security and Hardening Improvements in Rocky 10
Cgroup v2 Exclusively
Rocky Linux 9 shipped with cgroup v2 as default but still allowed cgroup v1 via kernel parameters. Rocky 10 removes cgroup v1 support entirely. This is a breaking change for older container runtimes, Docker versions below 20.10, and any software that uses the cgroup v1 hierarchy directly. Before migrating to Rocky 10, audit all containerized workloads for cgroup v1 dependency.
For hosting panels, cgroup v2 exclusive mode is the right direction — it provides more precise per-process accounting for CPU, memory, and I/O, and removes the complexity of maintaining two cgroup hierarchies simultaneously.
SELinux Profile Updates
Rocky 10 ships updated SELinux policy packages aligned with the RHEL 10 policy baseline. Several legacy application domains that were permissive in Rocky 9 are now in enforcing mode by default. If you are running custom SELinux policy modules written for Rocky 9, test them against the Rocky 10 policy base before migrating.
FIPS 140-3
Rocky 9 was certified for FIPS 140-2. Rocky 10 ships with FIPS 140-3 support, the current standard required for US federal deployments and increasingly common in financial services compliance frameworks. If your workload has a FIPS compliance requirement, Rocky 10 is the forward path.
TLS 1.0 and 1.1 Removed
The crypto policy changes in Rocky 10 remove TLS 1.0 and 1.1 from the default configuration. Applications that only support TLS 1.0/1.1 will fail to connect to services on Rocky 10 with default crypto settings. This affects older PHP applications, legacy Java apps, and some monitoring agents. Test before migrating.
SHA-1 Signature Removal
SHA-1 signatures are disabled by default in Rocky 10's system-wide crypto policy. This breaks older CA certificates and code-signing chains that used SHA-1. Affects legacy SSL certs, older Git signed tags, and some internal PKI configurations.
Migrating from Rocky 9 to Rocky 10: 3 Real Strategies
Strategy 1: In-Place Upgrade (Not Recommended for Production)
Red Hat does not provide an officially supported in-place upgrade path from RHEL 9 to RHEL 10, and Rocky Linux follows the same position. While community tools and manual procedures exist, an in-place major version upgrade on a production server carries significant risk: package conflicts, modified config files, kernel module incompatibilities, and post-upgrade instability are common. Reserve this approach for test environments.
Strategy 2: Side-by-Side Migration (Recommended)
This is the practical approach for most workloads:
- Provision a new Rocky 10 server alongside the existing Rocky 9 server
- Set up all services fresh on the Rocky 10 server (use your existing playbooks — this is a good audit of what you actually need)
- Test the application stack end-to-end on Rocky 10 before touching DNS
- Run both servers in parallel for a validation window (one to two weeks for critical workloads)
- Switch DNS to the Rocky 10 server when confident
- Keep the Rocky 9 server as a fallback for at least the validation window
This approach gives you a complete rollback path at any point. The cost is running two servers in parallel temporarily, which is acceptable given the risk reduction.
Strategy 3: Fresh Install with Data Restore
For workloads where the application itself is stateless or the data is stored externally (object storage, managed database), a fresh install with data restore is the cleanest option. Format the server, install Rocky 10, restore configuration and data from backups. This is also the standard approach when moving to new hardware.
For PHP hosting and web applications specifically: export each site's files and database from the Rocky 9 server, provision the Rocky 10 server fresh, then import. Most hosting panels that support both OS versions have migration tooling that handles this process.
Hosting Panel Compatibility
If you run a hosting panel on your Rocky Linux server, compatibility with Rocky 10 varies by vendor:
Panelica
Rocky Linux 9 and 10 are both first-class supported platforms. Panelica's build pipeline compiles against glibc 2.34 (AlmaLinux 9 Docker environment), meaning binaries run correctly on both Rocky 9 and Rocky 10. All 20 managed services (Nginx, Apache, MySQL 8, PostgreSQL 17, PHP 8.1-8.5, Redis, BIND, Postfix, Dovecot, and others) install and run on Rocky 10. Cgroup v2 is used exclusively throughout Panelica's isolation architecture, which aligns precisely with Rocky 10's kernel requirements.
Legacy Panels (General Status)
Traditional panels that were built around RHEL 7/8-era assumptions frequently have Rocky 10 compatibility gaps: hardcoded package names that changed between RHEL 9 and 10, init scripts that rely on deprecated systemd unit names, or compiled binaries linked against older glibc versions. Check your specific panel vendor's Rocky 10 support statement before migrating a production setup.
When to Upgrade vs Stay on Rocky 9
| Situation | Recommendation | Reason |
|---|---|---|
| New server deployment in 2026 | Rocky 10 | 5-year support horizon from today, modern toolchain, no migration debt later |
| Existing production server running well | Stay on Rocky 9 | Full support until 2027, EOL 2032, no urgency. Plan migration for 2026-2027 |
| ISV-certified workload (Oracle DB, SAP, etc.) | Wait for certification | Many enterprise ISVs certify Rocky 10 after GA. Check vendor certification matrix |
| FIPS 140-3 compliance required | Rocky 10 | Rocky 9 only has FIPS 140-2 certification |
| Application depends on cgroup v1 | Stay on Rocky 9, fix first | Rocky 10 removes cgroup v1. Update container runtime before migrating |
| Container host / Kubernetes node | Rocky 10 | Kernel 6.12, exclusive cgroup v2, and updated container runtime support |
| Legacy PHP app (5.x, 7.x) | Rocky 9, or Panelica on Rocky 10 | System PHP versions shifted. Panelica's per-user PHP pools support 5.6-8.5 regardless of OS |
| Hosting company provisioning new customer servers | Rocky 10 | Longer support horizon reduces future migration windows for customer data |
The glibc 2.39 Implication for Self-Compiled Software
This deserves a dedicated mention. If your workflow involves compiling custom daemons, Go binaries, or Rust tools and distributing them across mixed OS environments:
- Compile on Rocky 9 (glibc 2.34): Binary runs on Rocky 9, Rocky 10, Ubuntu 22.04, Debian 12, and most modern distributions
- Compile on Rocky 10 (glibc 2.39): Binary requires glibc 2.39+, which narrows the target set significantly
For software distributed to customers or across heterogeneous infrastructure, building in a Rocky 9 or AlmaLinux 9 Docker environment remains the safer choice in 2026, even if your servers run Rocky 10. The binary still runs correctly on Rocky 10 — glibc is backward compatible.
What Does Not Change
Some things remain consistent across both versions, worth noting to prevent over-caution:
- RPM package management, DNF, and repository structure work identically
- SELinux is still enforcing by default in both (not a Rocky 10 "new" change)
- Firewalld is the default firewall in both versions
- SSH configuration, sshd_config options, and authorized_keys mechanics are unchanged
- Standard cron, systemd timers, and logrotate configuration carry over without modification
- Most Ansible roles and Terraform configurations work on both with minimal or zero changes
TL;DR
- Rocky 10 ships kernel 6.12, GCC 14, Python 3.12, glibc 2.39, OpenSSL 3.2 — meaningful updates across every layer
- Rocky 9 is fully supported until May 2027, EOL May 2032. No urgent migration for stable production workloads
- Rocky 10 removes cgroup v1, TLS 1.0/1.1, and SHA-1 signatures — audit these before migrating
- For new deployments in 2026, Rocky 10 is the correct default. The support timeline alone justifies it
- Side-by-side migration is the safest approach for production: provision Rocky 10 fresh, test, then cut over DNS
Running Rocky Linux 10 with Panelica
If you are deploying a hosting panel on Rocky Linux 10, Panelica installs in under 3 minutes on Rocky 10 with the same one-line command as every other supported OS:
All 20 services are configured, the panel is running at https://SERVER_IP:8443, and every subsequent domain you add gets per-user PHP-FPM pools, cgroup v2 resource limits, SSL, and DNS provisioned automatically. Rocky 10's exclusive cgroup v2 requirement aligns with Panelica's isolation architecture, which has used cgroup v2 from the start.
Panelica supports PHP 5.6 through 8.5 on Rocky 10 via per-user isolated pools — the OS PHP version does not constrain which PHP version your hosted applications run.
Start a free 14-day trial at panelica.com/free-trial. No credit card required.