Joomla hosting requirements are short: a PHP version the current Joomla release supports, a few standard PHP modules, a MySQL, MariaDB or PostgreSQL database, and URL rewriting if you want clean addresses. Nearly any paid hosting plan meets that list. The harder question is PHP upgrades, and your extensions set that pace.
The official list takes a minute to check. The extensions take longer.
Joomla Hosting Requirements, From the Project Itself
The Joomla project publishes its technical requirements as a table whose columns run from a minimum version up to a recommended one. Read that page instead of any version number printed in an article, including this one, because the numbers move with every major release.
The minimum column is the one people misread. It is the oldest version Joomla will run on, and sitting at the floor leaves you no room when an extension asks for more. Aim for the recommended column on PHP whenever your extensions allow it.
Beyond the version, the page lists the PHP modules Joomla needs: json, simplexml, dom, zlib, gd, and one database driver out of mysqlnd, pdo_mysql or pdo_pgsql. Do not take a sales page's word for them. You can confirm on a running site under System, then System Information, where the PHP Settings and PHP Information tabs show what is loaded and what memory_limit and upload_max_filesize are set to. Watch the second of those. Extensions install as zip packages through the browser, and a package larger than upload_max_filesize is rejected by PHP before Joomla ever sees it.
Clean URLs are the one requirement that depends on the web server. Joomla ships a file called htaccess.txt in its root. On Apache you rename it to .htaccess, then switch on Use URL Rewriting under Global Configuration, in the SEO settings. Skip either step and your addresses keep /index.php/ in the middle. The requirements page lists mod_rewrite as optional for exactly this reason: the site works without it, only with longer and uglier addresses.
Extensions Are Where Joomla Sites Actually Break
Joomla core is rarely the problem. The problem is the dozen extensions a real site accumulates: a form builder, a gallery, a template framework, something that handles redirects. Each one comes from a different developer on a different schedule, and each decides for itself which PHP versions it supports.
That creates pressure from two directions at once.
An abandoned extension pins you to old PHP. It works today on the PHP branch you have, and it throws fatal errors on the next one, so the whole site stays on an aging branch because one gallery plugin stopped receiving updates. Meanwhile an actively maintained extension does the opposite: its next release drops the old branch, and you cannot take that update until the host moves you forward. The supported versions table at php.net shows how long each branch receives security fixes, which is the clock all of this runs against.
Joomla's own backward compatibility policy explains when the ground shifts. Minimum requirements such as the PHP version can only rise with the first release of a new major version. Code that core removes can be moved into a compatibility plugin, which is switched on after a major update so older extensions keep working. The policy is blunt about what that means: an extension is only fully compatible when it runs with that plugin disabled.
Treat the plugin as a grace period, then get off it.
My rule is simple: before installing any extension, check that its developer has released a version for the current Joomla major version. If the last release predates it, do not install it, however good the reviews are, because you are signing up to be stranded at the next upgrade. Anyone who moved a site from Joomla 3 to 4 remembers the common version of this story, where core upgraded cleanly and the template and a couple of extensions did not.
Run Every Major Upgrade on a Staging Copy First
Joomla's updater includes a pre-update check that lists your installed extensions and whether each one reports compatibility with the target version. Read it. Then do the upgrade somewhere else first, because an extension that reports compatibility and an extension that works with your data are two different things.
A staging copy on a subdomain is enough:
- Create a subdomain such as
staging.example.comand a second, empty database. - Copy the site files across, then import a fresh dump of the live database.
- Edit
configuration.phpon the copy. Change$db,$userand$passwordto the new database, and fix$tmp_pathand$log_path, which are absolute paths and will still point at the live site's folders. - Set Robots to "noindex, nofollow" in Global Configuration, under Metadata, and put a password on the subdomain so the copy stays out of search results.
- Run the upgrade, disable the compatibility plugin, and click through every page and extension you depend on.
Here is where the hosting plan comes in. Your plan has to allow a subdomain and a second database, and you should be able to take a database dump without opening a ticket. If a plan makes staging awkward, you will skip it, and skipping it is how a Saturday upgrade turns into a Monday restore.
Who Guards the /administrator Door?
Every Joomla site keeps its login at /administrator/, so every bot on the internet knows exactly where to knock. Core has no setting to move it. You can make it expensive to reach.
The work splits cleanly. On shared hosting the host normally runs and patches the server and keeps your account apart from the other customers on the machine. Everything inside Joomla is yours, from who holds a Super User account to whether logins need a second factor. Joomla has shipped multi-factor authentication in core since the 4.x series, with authenticator-app codes and hardware security keys among the methods, and the Users options let you require it for the groups you choose. Require it for Super Users and Administrators at minimum. Our guide to website security basics covers the wider split between what a host handles and what stays with the owner.
The extra door I recommend on any site with one or two editors is HTTP basic authentication on the administrator folder. Apache checks it before PHP runs, so password-guessing traffic aimed at the Joomla login form never reaches Joomla at all. An .htaccess file inside administrator/ does it:
apache
AuthType Basic
AuthName "Restricted"
AuthUserFile /home/youraccount/.htpasswd
Require valid-user
Keep the .htpasswd file outside the public web folder. Ten minutes of setup, and the only cost is typing one extra password.
If Your Visitors Log In, Caching Will Not Carry You
Joomla offers three kinds of cache. The Page Cache system plugin stores the finished HTML of each page and serves it to the next visitor who requests that address. Conservative and progressive caching, set in Global Configuration on the System tab, cache pieces of a page instead: the component view and the modules around it.
All three share one limit, stated plainly in Joomla's developer documentation on caching: Joomla performs no caching for logged-in users. A logged-in member or editor gets a freshly built page on every click, because what one user may see is not necessarily what the next may see.
That single rule sorts Joomla sites into two groups. A brochure site or a news site where nearly everyone is anonymous can serve most traffic from cache, and a small plan carries it a long way. A membership site or a community built on user profiles gets almost nothing from caching, so every request is full PHP and database work.
Forms sit in the second group. A submitted contact or registration form is a POST request, and it runs the full stack every time. Search is barely better, since every new query is a new URL with no cached copy waiting for it. The page cache plugin lets you exclude menu items and URLs, and you should exclude any page whose content changes per visitor. One more trap: an updated article is not cleared from the page cache automatically. It stays stale until the cache time expires or someone uses Clear Cache under the System menu.
What a Restorable Joomla Backup Has to Contain
Two things, and both must come from the same moment: every file under the Joomla root, and a dump of the database. The files include images/ and media/, along with configuration.php, which holds the database credentials, the table prefix and the site's secret key.
The table prefix is the detail that sinks restores. Joomla tables carry a prefix, stored as $dbprefix in configuration.php, and a dump restored into a database whose prefix does not match the file produces a site that installs fine and then cannot find a single table. If the restore lands in a different folder or on a different server, $tmp_path and $log_path need correcting as well.
Whether you use an extension such as Akeeba Backup or the host's own backups, restore one onto your staging subdomain. Do it once. That one exercise tests the backup and gives you a working staging copy in the same afternoon. For where copies should live and how long to keep them, read our guide on how to back up a website.
Does Your Joomla Site Fit on Shared Hosting?
Count extensions and logged-in users before you count gigabytes. Storage is almost never what a Joomla site runs out of first.
| Your Joomla site | Sensible tier | What runs out first |
|---|---|---|
| Brochure site or small business site, mostly anonymous visitors | Shared | Rarely the plan, once the page cache is on |
| News or content site with several editors and steady traffic | Shared or semi-dedicated | Concurrent PHP processes while editors work during busy hours |
| Membership site or community with many logged-in users | Semi-dedicated or VPS | CPU and database time, since caching does not apply to them |
| Store built on a Joomla ecommerce extension | VPS | Uncached cart and checkout pages at peak |
What drives that table is the share of traffic you can cache, which decides the tier more than raw visitor numbers do. If you are still choosing a platform, our posts on WordPress hosting requirements and Drupal hosting requirements answer the same question for those two. Joomla adds one wrinkle of its own. A site running many third-party extensions spends more PHP time on every uncached request, so the same visitor count costs more on an extension-heavy build than on a lean one.
Where to Start
If you are launching a new Joomla site, a shared plan with a PHP version selector is enough, provided it allows a subdomain with its own database so you can stage upgrades from day one. The Joomla hosting plans at BestPaidHosting run on the Hepsia control panel rather than cPanel, so follow the panel's own screens for the PHP selector and databases rather than a tutorial screenshot from another host. If the site is part of a wider launch, our guide on getting a small business online puts hosting in the right order alongside the domain and email.
If the site already exists, do one thing this week. Audit your extensions. Open the extension manager, list every third-party extension, and check each developer's last release date against the current Joomla major version. Anything stale is your next upgrade problem, and it is cheaper to replace now than during the upgrade itself.