WordPress Hosting Requirements

WordPress itself asks for remarkably little. What decides the plan you actually need is everything you install on top of it, and the gap between those two numbers is where most people get their hosting decision wrong in one direction or the other. This page separates the two: the platform requirements that are fixed, and the sizing question that is entirely about your site.

The platform requirements

These are the versions WordPress.org publishes, and they are the floor a host has to clear before anything else matters:

A host that cannot tell you which PHP and database versions you are on is telling you something. These are the questions worth asking before price.

The memory limit that is not the one you think

WordPress has two memory settings and confusing them is the cause of a lot of wasted debugging. memory_limit in PHP is the hard ceiling set by the server. WP_MEMORY_LIMIT in wp-config.php is what WordPress asks PHP for, and it cannot exceed the PHP setting.

WordPress defaults to asking for 40 MB on front-end pages and 256 MB in the admin, which is why a site can look perfectly healthy to visitors and fall over the moment you open the plugin editor or run an import. If you see a white screen or an "allowed memory size exhausted" error in the admin and not on the site, this is it.

Raise WP_MEMORY_LIMIT to 256 MB, and to 512 MB if you run a page builder such as Elementor or a WooCommerce store, both of which routinely go past the default. If raising it changes nothing, the PHP ceiling underneath is lower than what you asked for and only the host can move it.

What actually decides your plan

WordPress core is small. A brochure site on a well-cached stack is genuinely light work. Three things move the requirement, and none of them is WordPress:

• Plugins. Not the count, the kind. Thirty lightweight plugins can cost less than one page builder, one security scanner and one backup plugin running on a schedule. Anything that runs on every request, or on a cron, is the expensive kind.
• Dynamic pages. A cached page is served without touching PHP or the database at all. A WooCommerce cart, a logged-in user session and a search results page cannot be cached, so they execute PHP and query MySQL every time. A shop is a fundamentally different tenant from a blog with identical traffic.
• Concurrency, not visits. A month of traffic tells you very little. What sizes a server is how many uncacheable requests arrive in the same second, which is why a small site with a newsletter send can fall over while a larger steady one never does.

Sizing the plan

Every plan here is dedicated CPU, RAM and SSD rather than a share of a crowded box, which is the difference that actually shows up in page time. Higher tiers add Redis object caching, which matters most for exactly the uncacheable work described above: it is what keeps a WooCommerce checkout fast when the page itself cannot be cached.

Storage: the media library is the whole story

A WordPress install is a few tens of megabytes and the database of a normal site is small. What fills a disk is uploads, and specifically the fact that WordPress generates multiple resized copies of every image you add. A photography site or a shop with a large catalogue grows far faster than its page count suggests, and backups stored on the same disk double whatever number you arrived at.

The requirements nobody lists

Two things belong here even though they are not specifications, because they decide more about how a site performs than any of the versions above.

The first is where the server is. Latency is set by distance, and a site hosted a continent away from its readers is slower for every one of them regardless of how much CPU it has. Choosing a region near your audience is free and frequently outperforms buying a larger plan.

The second is what happens when the machine fails. On shared hosting your site is one of hundreds on a single server, which is a single point of failure with your name on it. On Flux a site is deployed as redundant instances across independent nodes, so losing a machine is not the same event as losing the site. That is a requirement in the sense that matters most: the one you only notice when it is missing.

Checking what you have now

You do not need to guess about any of this on an existing site. WordPress reports it to you: open Tools, then Site Health, then the Info tab. It lists your PHP version, database version, PHP memory limit and the constants set in wp-config.php. If your host is behind on PHP or capping memory below 256 MB, that page says so plainly, and it is the fastest audit available to you.