XenForo's published requirement is PHP 7.2, with 8.3 recommended, and a developer confirmed in February 2026 that the software runs fine on PHP 8.5.
Both statements are true, and neither is much help when you are picking a host. The gap between them is where most bad hosting decisions get made.
Sizing starts with everything a XenForo install has to keep running, because the load is not only page rendering. Search indexing, attachment storage, background jobs, and outbound email all draw on the same machine.
PHP 7.2 dropped off the supported list years ago. The recommended 8.3 left active support at the end of December 2025, which leaves 8.4 and 8.5 as the only branches still receiving bug fixes.
Those are the versions a XenForo developer confirmed in February 2026, saying 2.3.9 functions fully on both. The caveat was that newer branches emit deprecation notices XenForo suppresses outside debug mode, and the advice was to keep a rollback plan rather than stay away.
So the PHP version your host actually runs matters less than the requirements page implies. Anything from 8.4 upward is sound, and sitting on 7.x because the minimum permits it is a choice rather than a constraint.
The installer doubles as your requirements test. If it throws errors beyond the obvious ones, the documentation's own reading is that the server does not meet XenForo's requirements and the host has to change its PHP configuration.
The extension list is the fussier half. XenForo wants MySQLi, GD with JPEG support, PCRE, cURL, SPL, SimpleXML, DOM, JSON, iconv, and ctype, and it wants common PHP functions left enabled.
GD is the other trap. It is required unconditionally, and installing ImageMagick does not excuse you from it, because ImageMagick is treated as an advanced non-default option layered on top of GD rather than a replacement for it.
Plenty of hosting guides list the two as alternatives. They are not alternatives. You need GD either way.
The install itself expects a short checklist. An empty MySQL database with its credentials, FTP access to the server, and your XenForo customer account details. The installer then writes a config file into the src directory, and if it cannot write there, you upload that file by hand.
File permissions catch people during setup. The data and internal_data directories have to be writable, and the documentation tells Linux users to chmod them to 0777, which is wider than some managed hosts permit by default.
Windows and IIS hosting has its own version of that step, granting full control to the IUSR account instead. The requirement is the same underneath.
Enhanced Search is where shared hosting runs out entirely. It needs an Elasticsearch server, and the documentation says plainly that shared hosts generally do not have one, so ask before you buy rather than after.
The documented minimum there deserves a second look. XenForo asks for Elasticsearch 2.0 or newer, while Elastic shipped 9.5 in August 2026 and now supports only the 9.4, 9.5, and 8.19 lines.
Read that as a very low bar, not a suggestion. Nobody should stand up a search cluster on a release that predates every currently supported branch by several generations.
XenForo runs its scheduled tasks asynchronously, triggered by visitors loading pages. No visitors, no cron.
On an active community, that behavior is invisible and perfectly fine. On a quiet board, a brand new project, or a site with a long overnight lull, housekeeping that should run hourly can drift by hours.
The fix exists, and it is not automatic. You point your server's task scheduler at XenForo's command line job runner, and the documentation classifies this as an advanced operation most installations do not need.
It comes with a warning attached. Configure the server-side schedule badly and cron tasks stop running altogether, which is a worse outcome than the irregular triggering you were trying to fix.
Hardware is the easy part by comparison. A quiet forum sits happily on a small virtual server with two gigabytes of memory, and Elasticsearch is what forces you up a tier, because a Java service running alongside PHP and MySQL wants headroom of its own.
Both statements are true, and neither is much help when you are picking a host. The gap between them is where most bad hosting decisions get made.
Sizing starts with everything a XenForo install has to keep running, because the load is not only page rendering. Search indexing, attachment storage, background jobs, and outbound email all draw on the same machine.
The published minimums trail what the software runs on
The official floor is PHP 7.2 and MySQL 5.7, with MariaDB and Percona named as compatible alternatives. Treat that floor as a historical artifact rather than advice.PHP 7.2 dropped off the supported list years ago. The recommended 8.3 left active support at the end of December 2025, which leaves 8.4 and 8.5 as the only branches still receiving bug fixes.
Those are the versions a XenForo developer confirmed in February 2026, saying 2.3.9 functions fully on both. The caveat was that newer branches emit deprecation notices XenForo suppresses outside debug mode, and the advice was to keep a rollback plan rather than stay away.
So the PHP version your host actually runs matters less than the requirements page implies. Anything from 8.4 upward is sound, and sitting on 7.x because the minimum permits it is a choice rather than a constraint.
The installer doubles as your requirements test. If it throws errors beyond the obvious ones, the documentation's own reading is that the server does not meet XenForo's requirements and the host has to change its PHP configuration.
The extension list is the fussier half. XenForo wants MySQLi, GD with JPEG support, PCRE, cURL, SPL, SimpleXML, DOM, JSON, iconv, and ctype, and it wants common PHP functions left enabled.
Shared hosting for XenForo fails on the details
That last clause is the one that breaks installations. Budget hosts routinely disable PHP functions for security, and a server that passes every version check will still refuse to run the software.GD is the other trap. It is required unconditionally, and installing ImageMagick does not excuse you from it, because ImageMagick is treated as an advanced non-default option layered on top of GD rather than a replacement for it.
Plenty of hosting guides list the two as alternatives. They are not alternatives. You need GD either way.
The install itself expects a short checklist. An empty MySQL database with its credentials, FTP access to the server, and your XenForo customer account details. The installer then writes a config file into the src directory, and if it cannot write there, you upload that file by hand.
File permissions catch people during setup. The data and internal_data directories have to be writable, and the documentation tells Linux users to chmod them to 0777, which is wider than some managed hosts permit by default.
Windows and IIS hosting has its own version of that step, granting full control to the IUSR account instead. The requirement is the same underneath.
Enhanced Search is where shared hosting runs out entirely. It needs an Elasticsearch server, and the documentation says plainly that shared hosts generally do not have one, so ask before you buy rather than after.
The documented minimum there deserves a second look. XenForo asks for Elasticsearch 2.0 or newer, while Elastic shipped 9.5 in August 2026 and now supports only the 9.4, 9.5, and 8.19 lines.
Read that as a very low bar, not a suggestion. Nobody should stand up a search cluster on a release that predates every currently supported branch by several generations.
Scheduled tasks stop when nobody visits
This is the requirement almost nobody mentions, and it shapes small boards more than any hardware choice does.XenForo runs its scheduled tasks asynchronously, triggered by visitors loading pages. No visitors, no cron.
On an active community, that behavior is invisible and perfectly fine. On a quiet board, a brand new project, or a site with a long overnight lull, housekeeping that should run hourly can drift by hours.
The fix exists, and it is not automatic. You point your server's task scheduler at XenForo's command line job runner, and the documentation classifies this as an advanced operation most installations do not need.
It comes with a warning attached. Configure the server-side schedule badly and cron tasks stop running altogether, which is a worse outcome than the irregular triggering you were trying to fix.
Hardware is the easy part by comparison. A quiet forum sits happily on a small virtual server with two gigabytes of memory, and Elasticsearch is what forces you up a tier, because a Java service running alongside PHP and MySQL wants headroom of its own.
