WordPress officially requires PHP 7.4 or greater, MySQL 5.5.5 or greater, and HTTPS support. That's what the WordPress.org system requirements page says. And it's technically true in the same way that a car requires an engine and four wheels. It tells you nothing about whether your car can haul a trailer up a mountain.
The real WordPress hosting requirements for your site depend entirely on what your site does. A five-page brochure site and a membership portal with Salesforce integration, event registration, and a member directory have completely different hosting profiles, but most hosting guides treat them the same.
We manage around 200 WordPress sites for nonprofits, associations, advocacy organizations, and businesses. The hosting issues we troubleshoot are rarely due to the server not meeting WordPress.org's requirements. They're because those requirements were assessed against a generic checklist instead of against what the site actually does.
This article gives you the framework to assess what your site actually needs.
WordPress Server Requirements: The Official Minimums (and Why They're Not Enough)
Here's what WordPress.org publishes as minimum requirements:
- PHP: 7.4 or greater (8.3 recommended)
- MySQL: 8.0 recommended (or MariaDB 10.6+)
- Web Server: Apache or Nginx
- HTTPS: Required
These WordPress minimum requirements are deliberately low to maximize adoption. WordPress wants to run on as many servers as possible, so the bar is set at "will it install," not "will it perform."
The WordPress Hosting Handbook, the more technical reference, goes further with its WordPress PHP requirements: it recommends PHP 8.2 or 8.3, MySQL 8.4 LTS, and a handful of PHP extensions that aren't technically required but are functionally essential for a production site: curl, imagick, mbstring, openssl, and redis or memcached for caching.
Without these, your site will install, but features like image processing, secure API connections, and external service integrations either break or degrade silently.
"It's not their job to know the difference between a $5 host and a $500 host. But the difference is real."
The gap between "it installs" and "it performs well for your organization" is where every meaningful hosting decision lives.
WordPress PHP Version: More Than a Number
The right PHP version for WordPress is the single most common technical question we field about hosting requirements, and the answer isn't as simple as "use the latest."
What You Should Be Running
As of early 2026, WordPress recommends PHP version 8.3. It's fully supported by WordPress core, actively maintained by the PHP project through December 2027, and delivers meaningful performance improvements over older versions. PHP 8.2 is also a solid choice, with security support through December 2026.
Here's what you should know about the PHP landscape:
- PHP 7.4 and below: End of life. No security patches. While PHP 7.4 remains the WordPress minimum PHP version, roughly 55% of WordPress sites are still running EOL PHP versions, which is a significant security risk across the ecosystem.
- PHP 8.0 and 8.1: Also end of life as of late 2025. If you're on either, plan an upgrade.
- PHP 8.2: Security fixes only through December 2026. Safe for now, but start planning for 8.3+.
- PHP 8.3: Active support through December 2026, security support through December 2027. The sweet spot.
- PHP 8.4 and 8.5: Active support, but WordPress labels them as beta compatible. Fine for testing, not yet recommended for production.
WordPress 7.0, scheduled for April 2026, will drop support for PHP 7.2 and 7.3. Sites on those versions will stop receiving WordPress feature updates.
The Performance Case for Upgrading
The jump from PHP 7.4 to 8.x is the single highest-ROI server change most sites can make. Benchmarks show that PHP 8.3 handles 14-20% more requests per second than PHP 7.4 for WordPress workloads. WooCommerce sites see even larger gains: roughly 23% higher throughput and 25% faster product page loads.
The difference between PHP 8.2 and 8.5? Marginal. If you're already on 8.2+, don't lose sleep over it.
The Compatibility Problem
Here's where the real-world tension lives. Your host upgraded to PHP 8.3, but your theme was last updated in 2022. Or a critical plugin doesn't support PHP 8.x yet. We see this constantly.
"The 7.x to 8.x conversation is the hardest. A client has a 7-year-old website they're happy with and isn't expecting the cost of a rebuild. But moving from PHP 7.x to 8.x can require massive effort."
We've had to modify commercial plugin code because the original developers abandoned the project. We've rebuilt custom themes that relied on deprecated PHP functions.
The PHP upgrade itself is straightforward. The plugin and theme compatibility work is what takes time and money.
Our advice: Always test PHP upgrades in a staging environment first. Never upgrade PHP on a production site without verifying that every plugin and your theme work correctly on the new version. If you're on PHP 7.x, budget for compatibility work, not just the version change.
The ILFI Story
The International Living Future Institute came to us after their previous developer moved them to self-managed DigitalOcean servers. Nobody had explained PHP version management to them. They were running PHP 7.3 when 8.3 was the modern standard.
"The biggest problem wasn't the migration itself. It was the fact that no one had explained this to them. No one was watching out for this."
This is more common than it should be. A site gets built, launched, and then left on a server with nobody paying attention to whether the underlying software is still being maintained.
Letting a website sit on a server unattended, assuming it will keep running just because it ran yesterday, is not professional hosting management.
WordPress MySQL Version: The Database Behind Your Site
WordPress stores all content, settings, user data, and plugin data in a MySQL or MariaDB database. WordPress.org recommends MySQL 8.0 or MariaDB 10.6+, but there's an important timeline to note.
MySQL 8.0 reaches end of life in April 2026. If your host is running MySQL 8.0, it will stop receiving security patches within months. The upgrade path is MySQL 8.4 LTS, supported through April 2032.
MariaDB, a fork of MySQL maintained by MySQL's original developers, is the preferred choice for most WordPress hosting environments. It benchmarks faster for WordPress workloads, includes built-in thread pooling to manage concurrent connections better, and its LTS versions offer long support windows.
MariaDB 10.11 LTS (supported through February 2028) or 11.4 LTS (supported through May 2029) are both solid choices for new deployments. Migrating from MySQL to MariaDB is straightforward for WordPress.
If you're unsure which database version your site runs, ask your hosting provider. If the answer is MySQL 5.x, that's a red flag: it's ancient, unsupported, and a security risk.
What Your Site Type Actually Demands
This is where generic hosting guides fail. They list the same WordPress hardware requirements regardless of whether you're running a three-page brochure site or a membership portal with 3,000 active users. The requirements are fundamentally different.
Brochure and Informational Sites
Profile: 5-20 pages, contact form, maybe a team directory. Under 1,000 visits per month.
These sites are the simplest WordPress hosting scenario. Shared hosting genuinely works here. You need PHP 8.2+, a few gigabytes of disk space, and basic SSL. A $15-35/month managed hosting plan is more than adequate.
The real risk for brochure sites isn't under-provisioning. It's overpaying. If a hosting provider is trying to sell you a $200/month plan for a site that gets 500 visits a month, they're selling you infrastructure you don't need.
Content-Heavy Publishing Sites
Profile: 500+ posts, regular publishing schedule, multiple authors. 5,000-50,000 visits per month.
This is where requirements start diverging from the minimums. Database query load scales with post count. Archive pages and search queries against thousands of posts without object caching will hammer the database.
Image storage accumulates: 1,000 posts with 3-5 images each, at multiple WordPress-generated sizes, can consume 10-15GB.
What you need: 2GB+ RAM, 2-4 PHP workers, Redis object caching, and full-page caching for anonymous traffic. A managed WordPress host or managed VPS in the $35-75/month range.
We manage AIER, a research organization that publishes multiple articles per day with thousands of posts in its archive. They can't use aggressive full-page CDN caching because the content changes too frequently.
Object caching with Redis intelligently caches database queries, making the site perform well even with high volumes of dynamic content.
Membership and Association Sites
Profile: User authentication, gated content, member directories, event registration. Hundreds to thousands of logged-in users.
This is where most organizations underestimate their WordPress hosting requirements. The critical factor: logged-in users bypass page caching.
A brochure site can serve 90%+ of traffic from cache. Each request served from cache costs almost nothing in server resources.
But a membership site with 200 concurrent logged-in users generates 200 uncached PHP requests, each of which requires a PHP worker and a database connection.
"Membership sites serve the public and members: two completely different audiences with different requirements. You're not going to use the same caching technologies in the logged-in area as you will on the public area."
What you need: 2-4GB RAM, 4-8 PHP workers, Redis object caching (not optional), and a hosting environment that can handle the two-audience problem. Budget $75-200/month for hosting alone.
The security profile changes, too. Member interactions, such as file uploads, form submissions, profile management, and inter-member communication, create a larger attack surface than a static brochure site. The hosting environment needs stronger security protocols to match.
E-Commerce (WooCommerce) Sites
Profile: Product catalog, shopping cart, checkout, payment processing. Transaction-critical uptime.
WooCommerce adds a layer of hosting requirements on top of everything above. Cart and checkout pages are uncacheable by nature because each shopper at checkout is a live PHP request plus a database transaction. Payment gateway webhooks add API overhead.
Peak load matters far more than average load. A flash sale or email blast can spike concurrent users 10-50x above your daily baseline.
What you need varies dramatically by store size:
- Small stores (under 100 products): 2-4GB RAM, 2-4 PHP workers. $50-100/month.
- Medium stores (100-500 products): 4-8GB RAM, 4-8 PHP workers. $100-200/month.
- Large stores (500+ products): 8GB+ RAM, 8-16 PHP workers, and likely cloud-based hosting with auto-scaling capability. $200-500/month.
We don't store any financial information on client websites, and we wouldn't accept a client that does. Transaction processing belongs at the payment gateway: Stripe, Square, or PayPal.
Our responsibility is to ensure that the API connections to those gateways are stable and that the hosting environment has the resources to handle concurrent transactions without dropping connections during peak periods.
Sites with CRM and AMS Integrations
Profile: WordPress connected to Salesforce, iMIS, Blackbaud, Neon CRM, or similar. Data sync, member lookup, SSO, form submissions pushed to CRM.
CRM integrations are the resource demand that most surprises organizations. The integrations don't spike CPU or RAM in the traditional sense, but they create a different kind of bottleneck.
API calls block PHP workers. A Salesforce REST API call might take 200 to 2,000 milliseconds. While that PHP worker waits for the API response, it can't serve other requests. This is the number one reason CRM-integrated sites need more PHP workers than their traffic alone would suggest.
"APIs are not plug and play. Programming must be done correctly and efficiently. We've seen scenarios where API connections were inefficiently implemented, pulling 1,000 records when only 1 was needed. RAM gets eaten up."
The hosting environment has to match the integration approach. Transient caching, object caching, and strategic pagination aren't just nice-to-haves. They help prevent API integrations from overwhelming the server during peak usage.
What you need: 2-4GB RAM, 4-8 PHP workers, Redis object caching, and a hosting provider that allows you to configure PHP execution timeouts beyond the default 30 seconds. Budget $75-200/month.
Advocacy and Campaign Sites
Profile: Nonprofit or political organizations running campaigns, petition drives, fundraising pushes. Traffic is extremely spiky.
The defining challenge is unpredictability. A brochure site gets steady traffic. An advocacy site gets 500 visits on a normal day and 50,000 when a campaign launches, a story breaks, or a political figure draws attention to the cause.
We've worked with nationally recognized PACs and federal election campaigns. The traffic spikes aren't just from the organization's own outreach. A clip goes viral, a candidate makes headlines, someone with a large platform mentions the organization, and suddenly thousands of people hit the site at once.
The donation page, the site's highest-value page, is most likely to fail under load because donation processing is uncacheable.
What you need: Proper provisioning for expected maximums, a CDN with hit rates above 90% (meaning the vast majority of traffic is served from edge servers and never touches your web server), full-page caching for anonymous visitors, and either auto-scaling capability or a hosting partner willing to scale resources proactively. These systems become more efficient as traffic increases.
"We prepare for those spikes before they happen. If we've done our jobs correctly, then all the optimizations are already in place."
PHP Workers: The Hidden Bottleneck
PHP workers are the number of simultaneous PHP requests your server can process. This is the resource most directly tied to "how many people can use my site at once," and it's the resource most hosting providers either don't disclose or bury in fine print.
How it works: Each uncached page request needs one PHP worker for the duration of that request (typically 200ms to 2 seconds). If all workers are busy, new requests queue up until visitors see 504 timeout errors. Cached requests don't consume any PHP workers, which is why caching is so critical.
Rough guidelines by site type:
- Brochure site: 1-2 workers
- Blog with caching: 2-4 workers
- Small WooCommerce store: 4-8 workers
- Membership or LMS site: 8-16 workers
- High-traffic WooCommerce: 16-32+ workers
What increases PHP worker demand: Logged-in users (they bypass page cache), slow external API calls that keep workers waiting, heavy plugin execution, AJAX-heavy admin interfaces, and long-running cron jobs.
The reason PHP workers matter so much is that they're invisible until they're exhausted. A site works fine with 10 concurrent visitors, but crashes at 30 because only 2 PHP workers are available.
Shared hosting plans rarely disclose their PHP worker allocation.
The Plugin Stack Effect
Every hosting guide says "plugins increase resource demands," but none explains what actually happens when you stack them. A single plugin, in isolation, might add 10-20 MB of memory per PHP process. But WordPress plugins hook into core execution on every page load, even when their features aren't used on that page.
Stack a page builder, WooCommerce, a forms plugin, a CRM connector, and a caching plugin together, and each PHP process can consume 200-300MB of memory. The load isn't additive; it compounds.
We see this constantly in the sites we manage. A site running Elementor, WooCommerce, Gravity Forms, and a Salesforce connector generates fundamentally more load than any of those plugins individually. Each plugin adds its own database queries, hooks into WordPress execution, and makes its own external API calls.
A single page load on a plugin-heavy WooCommerce site can trigger 200+ database queries and multiple external API calls, each one consuming memory and holding a PHP worker for the duration.
This is why "disable plugins you aren't using" is real operational advice, not just a tidiness measure. Every active plugin has a cost, even on pages where it does nothing visible.
Object Caching: When It Becomes Non-Negotiable
Object caching (Redis or Memcached) stores the results of expensive database queries in memory so they don't have to re-execute on every page load. A typical WordPress page runs 50-200 database queries. Object caching reduces that by 40-70%.
"WordPress is always calling the database. Object caching makes those calls super fast. It's an intelligent system that reacts quickly when data changes."
Object caching is mandatory for:
- Any site with significant logged-in user activity (membership, LMS, WooCommerce)
- Sites running community features (BuddyPress, forums)
- Sites with CRM integrations generating extra database queries
- Content-heavy sites with 1,000+ posts
Object caching requires server-level support. WordPress plugins like Object Cache Pro or Redis Object Cache connect to Redis, but they don't provide it. If your host doesn't have Redis installed on the server, no plugin can create real object caching. This is one of the clearest dividing lines between commodity hosting and professional hosting.
Hosting problems aren't always about raw resources. They're often about configuration and flexibility.
We worked with a national medical research nonprofit whose site featured dynamic design elements that created unique user experiences as visitors moved through the site. WP Engine's strict caching policy broke those intentional design features.
Caching was too aggressive, and WP Engine's response was to upgrade to a plan costing hundreds more per month just to get caching policy control. We provided a caching solution that met their actual design requirements without the premium price tag. The right caching configuration matters as much as having caching at all.
The "Unlimited" Hosting Problem
Hosts advertising "unlimited" storage, bandwidth, or resources are overselling. A typical mid-tier shared hosting plan behind the "unlimited" marketing claims looks like this: 1-2GB RAM from a shared pool, CPU with aggressive throttling at capacity, and shared disk I/O across hundreds of accounts.
The math is simple. A $10/month shared plan on a server with 1,000 accounts collects $10,000/month. That server might have 256GB RAM and 32 CPU cores, enough capacity for roughly 256 accounts. They've sold 1,000. The business model depends on 95% of accounts being dormant.
Even when storage seems unlimited, there's often a hidden cap: inodes. Every file on the server, every cache fragment, every email log counts as an inode. A WordPress site with WooCommerce, caching, and email can hit 250,000 inodes even at 5GB of actual disk space.
Hit the inode limit, and the server stops creating new files, so no new uploads, no cache files, and failed backups.
"Unlimited" hosting fails precisely when the site needs resources: during traffic spikes, fundraising campaigns, or email blasts. These are the moments when multiple tenants on the oversold server compete for the same physical resources.
"If you're paying less for your hosting than you did for your last fancy coffee, then you're doing it wrong."
Signs You've Outgrown Your Hosting
Some organizations wait for obvious failure before evaluating their hosting. Here are the warning signs:
- Slow admin panel. If the WordPress dashboard, especially the Plugins page, Media Library, and post editor, loads slowly, your server is likely under-resourced.
- 504 or 502 errors during moderate traffic. These indicate PHP worker exhaustion or insufficient RAM.
- Database connection errors. "Error establishing a database connection" means concurrent requests have exceeded available database connections.
- Failed cron jobs. Scheduled posts not publishing, backup plugins timing out, or email queues stalling.
- Images taking forever to upload or process. Often a disk I/O bottleneck.
- Plugin updates timing out. The server runs out of memory or execution time during updates.
Those are useful diagnostics, but we'll be direct: if your website is mission-critical to your organization, the question isn't when you'll outgrow budget hosting. The question is why you're on it in the first place.
"Any professional organization or business that considers its website to be mission-critical should absolutely not be on any of those budget web hosts. It's not about waiting until you've outgrown them. It's an issue of treating your website as a professional tool, and therefore, you need a professional hosting environment."
Budget hosts like GoDaddy, Bluehost, and HostGator are fine for hobby sites and personal blogs. For an organization where the website supports your mission, drives donations, serves members, or generates revenue, those platforms are the wrong foundation.
A Real-World Example: When the Site Goes Down at the Worst Possible Moment
The North Carolina Budget and Tax Center published time-sensitive research reports tied to state legislature sessions. Their reports influenced government hearings and required constituent action. Every time they released a report, the traffic spike brought their Bluehost-hosted site down.
They contacted Bluehost, worked their way up the support ladder, and the only suggestion was to upgrade their plan, with no evidence that the upgrade would actually solve the problem. It was a sales pitch, not a diagnosis.
We moved them to a server with enough resources for both normal days and spike periods. They haven't had a downtime issue since.
The contrast in approach is telling. Budget hosts let your site crash, then turn it into a sales conversation. If FatLab sees high resource usage, we move the website to a higher-resource server, no questions asked. Clients aren't charged additionally.
The fix is often not more resources but better configuration: caching, CDN optimization, and strategic resource allocation. That's the difference between reactive upselling and proactive management.
Budget hosting works fine on quiet days. It fails during the moments that matter most to your organization.
How to Evaluate Your WordPress Hosting Requirements
When we take on a new client, our discovery process follows three pillars. This is the same framework you can use to assess your own hosting needs:
1. Functionality and use. How do you use your website, and what does it do? A contact form and a few pages are a completely different hosting profile than member authentication, event registration, CRM sync, and donation processing.
We want to understand every integration point: is your Salesforce connection a complex API integration or a simple widget embed? Is your member portal a real integration or just a link to a third-party platform? Is your donation system running GiveWP with Stripe or embedding Donorbox? The deeper the integration, the more your hosting needs to support it.
2. Site footprint and plans. How big is the website, and where is it going? A site with 50 pages that rarely updates has entirely different resource demands than one with thousands of posts publishing daily.
Content velocity matters: AIER publishes multiple articles per day with thousands in its archive, which requires a completely different caching and database strategy than a brochure site that updates quarterly. Your plans matter just as much. If you're adding a membership portal or CRM integration next year, your hosting should be ready for that.
3. Traffic patterns. What traffic levels can you expect? Most organizations can give a qualitative answer ("a few hundred visitors a day" vs. "a few thousand").
The critical distinction is whether your traffic is steady and predictable or spiky around campaigns, publications, or news cycles. If you actively drive traffic through newsletters, email blasts, or media outreach, your hosting needs headroom for those spikes, since that's when your site's performance matters most.
Beyond these three pillars, ask yourself one more question: What's the cost of downtime? If your site going down for an hour means missed donations, lost member trust, or failed advocacy campaigns, your hosting budget should reflect that risk.
What to Ask Your Hosting Provider
If you're evaluating hosting, these are the questions that actually matter:
- What PHP version is available, and can you choose your version?
- How many PHP workers are allocated to your account?
- Is Redis or Memcached available for object caching?
- What happens when your site exceeds its allocated resources?
- Do they offer staging environments for testing updates?
- What's their backup strategy, and have you ever needed to restore from a backup?
- What does "managed" actually mean in their context?
That last question is important. "Managed hosting" at most providers means they manage the server. They keep the lights on and the operating system up to date. They don't manage your website.
If your site crashes at 2 AM, most managed hosts will ensure the server is running. Whether your WordPress site is functioning correctly on that server is a separate question. And those impressive uptime guarantees in the marketing? They're measuring something different than what you think.
"99.999% uptime refers to their network, not your website."
That distinction matters. A hosting provider can have perfect network uptime while your WordPress site throws errors, runs out of PHP workers, or fails to process donations. The network is up. Your website is not.
A Note on WordPress Self-Hosting
When you self-host WordPress, meaning you run the application on infrastructure you fully control, whether a cloud VPS or physical hardware, you carry the same technical requirements as any WordPress installation plus the entire operational burden: Linux administration, PHP and database configuration, security hardening, SSL management, backups, monitoring, and incident response.
For organizations with dedicated DevOps staff or regulatory requirements mandating specific infrastructure controls, WordPress self-hosting is a legitimate choice. For everyone else, the hidden costs are substantial.
Server maintenance alone runs for 5-10 hours per month, assuming nothing goes wrong. The "savings" over managed hosting disappear quickly when you account for the labor of keeping the server secure, patched, and performing well. For a single site, managed hosting is almost always more cost-effective.
Making the Right Investment
The WordPress hosting requirements for your site aren't a mystery. They follow directly from what your site does, who uses it, and what's at stake when it doesn't work.
The gap between WordPress's minimum requirements and what your organization actually needs is where every meaningful hosting decision lives.
For organizations where the website is mission-critical, getting this right isn't a technical luxury. It's operational infrastructure, and it deserves the same thoughtful evaluation you'd give any other system your organization depends on.
"If your organization is mission-critical, then so should your infrastructure."
If you're unsure whether your current hosting meets your site's actual requirements, or you're planning a site that will need more than the basics, we're happy to help you evaluate your options.