Long-maintained PHP in RHEL
About 10 years
RHEL Full Life packages follow the OS’s standard lifecycle. Not every distributed PHP version is covered.
Recently, we have started receiving a few enquiries about Laravel upgrades.
Looking into their setups and support deadlines, some connections began to emerge.
The PHP maintained by an OS vendor and the Laravel framework running on it move at very different speeds.
So we did a little research and put together this overview.
About 10 years
RHEL Full Life packages follow the OS’s standard lifecycle. Not every distributed PHP version is covered.
About 4 years
Each release branch receives two years of active support plus two years of security support.
About 2 years
Each major release normally receives two years of security support.
With the standard PHP packages on a RHEL-family OS,
PHP 8.0 on version 9 can remain in service until around 2032,
and PHP 8.3 on version 10 until around 2035.[1][2]
The chart below is based on currently available public information.
Bars run from release to end of security support, assuming updates are applied. Laravel 14 is the source author’s projection: release around Q1 2027 with roughly two years of maintenance. PHP 8.6 uses the official planned release date of November 19, 2026. RHEL 10 extends beyond the right edge to around 2035. Hover over a bar, or tap on mobile, for details.
OS package maintenance varies by package, contract, and maintenance phase. Check it separately from upstream PHP and external repositories, and apply the distributor’s updates.
Information checked: . Plans and maintenance terms may change.
Now the picture starts to make sense.
The OS and Laravel lifecycles
just do not quite line up.
Laravel releases a new major version each year, embracing modern PHP along the way. The OS, meanwhile, is built around maintaining the same foundation for years.
The framework and the OS beneath it are used together, yet their maintenance timelines are worlds apart.
Laravel’s ease of development is appealing.
For a system intended to run for years, though, the cost of keeping up with upgrades also needs to be part of the plan.
It is also worth asking whether the system actually needs a Laravel upgrade for its features or ongoing development.
The features and behaviour may be stable, and the current Laravel version may still be perfectly adequate for development. Even then, continuing to receive official security support requires upgrading Laravel. Sometimes that also means moving to a newer PHP version.
These are upgrades to keep maintaining the existing system, rather than to add a feature it needs. Include that cost when deciding whether the stack is a good fit for the long term.
At Nanomix, we recommend PHP development approaches suited to each system’s requirements and the team responsible for operations and maintenance, without limiting the options to Laravel.
If this article struck a chord and you could use some help,
Nanomix offers free consultations and system assessments, so feel free to get in touch!
Still, it is a little frustrating that the alternatives to Laravel feel rather limited. Such are our days. 🥴
Dates refer to standard official maintenance, excluding independent third-party extensions. Development requirements are distinguished from releases and linked to the inspected commit.