A WordPress server needs five things to run correctly: a supported PHP version, 8.3 or newer per WordPress.org’s own requirements page, MySQL 8.0+ or MariaDB 10.6+, a web server with mod_rewrite (Nginx or Apache), enough PHP-FPM workers to handle concurrent requests without queuing, and RAM sized to the traffic the site actually gets rather than a round number picked off a hosting plan page. The requirements list is short and well documented. What most guides skip is the operational side, how many PHP-FPM workers a given RAM budget supports, whether an object cache is worth adding, and the real difference between running that stack yourself and paying someone to run it for you.
The search results for this phrase are dominated by hosting-affiliate content that repeats WordPress.org’s own four facts, PHP version, database version, web server, HTTPS, and pads them into a long article with a comparison table and a plug for their own hosting plan buried partway through. WordPress.org’s own requirements page already says the important part in a few lines. This post uses that as the floor and spends the rest of its length on what actually decides whether a WordPress server performs well: PHP-FPM worker sizing, the object cache almost nobody adds by default, a rough RAM budget by traffic tier, and what changes, and what does not, when someone else manages the stack.
Table of contents
- The official requirements, and why they are a floor, not a plan
- PHP-FPM: the setting that actually decides how many visitors you can serve
- MySQL or MariaDB, and the object cache most self-managed setups skip
- RAM by traffic: a rough sizing table
- Running the stack yourself: the ongoing list
- What changes when someone else runs the stack
- How this fits the rest of the stack
- FAQ
The official requirements, and why they are a floor, not a plan
WordPress.org’s own requirements page is short on purpose: PHP 8.3 or greater, MariaDB 10.11 or greater or MySQL 8.0 or greater, Nginx or Apache with mod_rewrite, and HTTPS on every install. That list answers will WordPress run at all, and it is genuinely the right place to start, because plenty of hosting-affiliate content pads the same four facts into a two-thousand-word article with a comparison table and a recommendation for their own hosting plan buried in the middle.
What the requirements page does not answer is will WordPress run well for this specific site, because that depends on traffic, plugin count, and whether anything on the site runs a real query per visitor, none of which show up in a minimum-version list. The rest of this post is the operational half: how those requirements translate into an actual server, and how much of it a given RAM budget actually buys.
PHP-FPM: the setting that actually decides how many visitors you can serve
PHP-FPM runs PHP as a pool of worker processes, each one handling one request at a time. pm.max_children sets the ceiling on how many requests WordPress can serve simultaneously, and it is the single setting most self-managed WordPress installs never touch, left at whatever the distro’s default package shipped with. Set it too low and visitors queue behind each other during a traffic spike, each seeing a slow page instead of an error, often mistaken for a slow server rather than a starved worker pool. Set it too high on limited RAM and the OS starts swapping or the out-of-memory killer starts picking processes to kill, neither of which is graceful.
[www]
pm = dynamic
pm.max_children = 5
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3The right number for pm.max_children is roughly the RAM available to PHP divided by the average memory a single PHP-FPM worker uses under real WordPress load, often 40 to 80MB per worker depending on plugins, not a number copied from a tutorial written for a different site.
MySQL or MariaDB, and the object cache most self-managed setups skip
MySQL 8.0+ or MariaDB 10.6+ satisfies the requirement, and the two are close enough in behavior for WordPress that the choice usually comes down to what the distro or the host ships by default rather than a feature WordPress specifically needs from one over the other. What matters more than the version number is what sits in front of the database on every request: WordPress hits the database for nearly everything, and without an object cache layered in front of it, something like Redis or the built-in file-based transient cache, every visitor triggers the same repeated queries the previous visitor just ran seconds earlier. How managed database instances handle connection limits and backups covers the operational side of running the database itself, separate from WordPress’s own query patterns.
An object cache is the single most effective addition to a WordPress install that has outgrown its default configuration, more impactful than most plugin-level speed optimizations, because it removes repeated database round-trips instead of shaving milliseconds off a template render.
RAM by traffic: a rough sizing table
These are starting points, not guarantees, because plugin count and theme complexity move the number as much as raw traffic does. Treat them as a floor to plan from rather than a ceiling to expect.
- Low-traffic brochure site, under 5,000 visits a month: 512MB-1GB total is workable with a lean theme and a handful of PHP-FPM workers, little margin for a traffic spike.
- Small business site with a blog or a simple shop, 5,000-50,000 visits a month: 1-2GB gives room for an object cache and a PHP-FPM pool sized for real concurrency instead of the bare minimum.
- WooCommerce or a membership site with logged-in, concurrent users, 50,000+ visits a month: 2-4GB or more, where an object cache stops being optional, PHP-FPM workers are tuned to actual concurrent sessions, and the database usually deserves its own resources separate from the web server.
Running the stack yourself: the ongoing list
The install is a few commands. What follows is the part that does not end: PHP minor version updates that patch real security issues, plugin updates that occasionally break something on a live site with no staging environment to catch it first, database maintenance as tables grow and indexes drift, and backups that are only as good as the last time someone verified a restore actually works. None of this is difficult individually. All of it together is a recurring time cost, not a one-time setup task, and it is the part that self-managed WordPress guides tend to end the article right before mentioning.
A server that is perfectly sized on day one and six months behind on PHP patches by month three has not actually solved the sizing problem, it has just moved the risk from capacity to security.
What changes when someone else runs the stack
The requirements in this post do not go away when someone else manages the server, they get handled on a schedule instead of an ad-hoc basis: PHP and core patches applied on a known cadence, backups taken and periodically verified rather than assumed, and a single point of contact when something breaks instead of a forum search at 2am. The tradeoff is the same one behind every managed service, less direct control over the exact PHP-FPM tuning or the exact MySQL configuration, in exchange for not being the one who has to notice when a patch is overdue.
For a site where the traffic and the stakes justify a dedicated administrator’s ongoing attention, self-managing stays the right call. For most small business sites, the requirements list at the top of this post is the easy part; the maintenance underneath it is the part that decides whether self-managing was actually worth the savings.
How this fits the rest of the stack
Self-managing the stack above is entirely reasonable when the traffic and the budget justify a dedicated administrator’s time, patching PHP, tuning PHP-FPM, watching the database, and being awake when something breaks. For most small sites, that time costs more than the server does. Managed WordPress on RunxBuild starts at $3/month on the Starter plan and replaces SFTP and phpMyAdmin with a file manager and a database browser built into the dashboard, so the two things this post spent most of its length explaining, the file system and the database, are a few clicks away instead of a terminal session. The RunxBuild hosting calculator shows the full WordPress plan ladder if traffic outgrows the entry tier.
Useful related references:
- Managed WordPress: What the Word Managed Actually Covers, Who It Is For, and What It Should Cost
- Self-Host WordPress: The 2026 Quick-Start (Ubuntu + Nginx + MariaDB)
- Cloud WordPress Hosting Overview: AWS, GCP, Azure, and the 4 Managed Alternatives
- Managed WordPress on RunxBuild
FAQ
What PHP version does WordPress need in 2026?
WordPress.org currently recommends PHP 8.3 or greater. It still runs on PHP 7.4 for legacy environments, but 7.4 and everything before it is end-of-life and no longer receives security patches, so running it on a live site is a real risk, not just a missed optimization. Plan for 8.3 as the baseline and 8.4 where the host supports it.
Can WordPress run on MariaDB instead of MySQL?
Yes. WordPress.org lists MariaDB 10.11 or greater as fully equivalent to MySQL 8.0 or greater, and most distros ship MariaDB by default for exactly this reason. The two are close enough in the SQL WordPress actually uses that the choice rarely matters for a typical site; it usually comes down to whichever the server or host provides.
How much RAM does a WordPress server need?
It depends on traffic and plugin load more than a fixed number: roughly 512MB-1GB for a low-traffic brochure site, 1-2GB for a small business site with a blog or simple shop, and 2-4GB or more for WooCommerce or a membership site with concurrent logged-in users. An object cache and correctly sized PHP-FPM workers matter as much as the raw total.
What does PHP-FPM do for WordPress?
PHP-FPM runs PHP as a pool of worker processes, each handling one request at a time, with pm.max_children setting how many requests can be served simultaneously. Sized correctly for the available RAM, it prevents both request queuing under load and out-of-memory crashes from too many workers competing for too little memory.
Is managed WordPress hosting worth it over a self-managed VPS?
It depends on whether the time spent patching PHP, watching the database, and verifying backups is worth more than the price difference. For a site with real traffic and no dedicated administrator, managed hosting trades some configuration control for patches on a schedule, verified backups, and a file manager and database browser instead of SFTP and phpMyAdmin.