Website Server Software: The Updates You Miss

Every WordPress site owner knows the little red dot. The one in the dashboard telling you a plugin needs updating. You click it, the number disappears, and you feel like you have done your bit for security. For the layer you can see, you have.

There is a second layer underneath. You never see it, you never click anything, and it is doing more to keep your site safe, or to expose it, than every plugin update combined. It is the server software your WordPress site actually runs on. And it expires.

I was reviewing a migration we took on last week, a site that had run without complaint for years, and the software stack underneath it had not been touched since the day it was set up. The owner had diligently updated every plugin. Nobody had touched the engine those plugins ran on. This article is a guide to that engine: what it is, why it has an expiry date, and how to tell whether anyone is watching the clock on yours.

The Two Layers of Keeping a Website Updated

When people talk about keeping a WordPress site updated, they almost always mean one thing: the software you can see from the dashboard. WordPress core, your plugins, your theme. You log in, the prompts appear, you apply them. That is real work, and it matters.

But your site does not run on the dashboard. It runs on a server, and that server has its own software. Three pieces of it in particular decide whether your site is fast, secure, and even able to run at all.

The software layer	What it does for your site	What happens when it goes end of life
Web server (Nginx or Apache)	Answers every visitor request and hands back your pages	Stops receiving security fixes, so known exploits stay open
PHP runtime	Runs the actual code that builds every WordPress page	No more patches, and modern plugins eventually refuse to run on it
Database (MySQL or MariaDB)	Stores every page, order, and customer record you have	An unpatched store of your most sensitive data

None of these show up in your WordPress dashboard. There is no red dot. There is no prompt. On a properly managed platform they get updated quietly in the background by the people who run the infrastructure. On a cheap or unmanaged plan they often do not get updated at all, and you would have no way of knowing.

What Actually Runs Underneath WordPress, in Plain English

You do not need to administer any of this. You do need to know it exists, because the gaps in it are where small sites get caught.

The web server is the doorman. Nginx or Apache sits at the front of your site and answers every request that arrives. When a customer of a Waterford manufacturer with a trade catalogue site clicks through to a product page, the web server is the thing that takes that request and hands back the page. If it is running an old, unpatched version, it is a doorman working from a security briefing that stopped being updated years ago.

The PHP runtime is the engine. WordPress is written in a language called PHP, and the PHP runtime is what turns that code into the page your visitor sees. Every single page load runs through it. An old runtime is slower, so pages take longer to appear and visitors drift away before they buy. An end-of-life runtime is worse than slow, because it no longer receives the security fixes that close newly discovered holes.

The database is the filing cabinet. MySQL or MariaDB stores every page, every product, every order, and every customer record on your site. When that layer is left on a version nobody is patching, you have your most sensitive data sitting in a cabinet whose lock the manufacturer has stopped maintaining. It still locks. It just no longer gets fixed when someone works out how to pick it.

The layer you update sits on top of three you never see

End of Life Is Not a Setting. It Is a Date Your Security Stops.

Here is the part that catches people out. Software does not break the day it goes end of life. It keeps running. That is exactly what makes it dangerous.

End of life is a date set by the people who make the software. After it, they stop releasing security patches for that version. The PHP project publishes these dates openly: PHP 8.0 and 8.1 are already past end of life, PHP 8.2 receives security fixes only until the end of 2026, and PHP 8.3 until the end of 2027, according to php.net's own support schedule. WordPress.org now states plainly on its requirements page that its recommended baseline is PHP 8.3 with MySQL 8.0 or MariaDB 10.6, and that running anything older has reached official end of life and may expose your site to security vulnerabilities. That is not a hosting company talking. That is the people who make WordPress.

The database layer hit the same wall this year. MySQL 8.0, one of the most widely deployed database versions on the web, reached end of life in April 2026. Oracle moved it to what they call sustaining support, which in plain terms means the community version most hosts run no longer gets security patches.

And plenty of sites are nowhere near current. By W3Techs' latest count, roughly four in ten sites that run PHP are still on PHP 7 or older, versions that stopped receiving security updates years ago. I would treat that as a rough figure, because it shifts month to month and varies a lot by sector, but the direction is clear enough. A very large slice of the web is running on an engine nobody is patching anymore.

Why You Are the Last to Know

The cruel thing about an end-of-life stack is how normal it looks. Your site loads. Orders come in. The contact form works. Nothing on screen tells you the foundation has stopped receiving security fixes.

Then one of two things happens. Either a plugin or WordPress core updates itself, hits a version of PHP it no longer supports, and a page goes blank. Usually the checkout. Usually noticed first by a customer who rang to say they could not pay. Or, worse, nobody notices anything until a known vulnerability in that unpatched software is used, and you are dealing with a compromised site, a malware warning next to your name in Google, and the phone call you do not want on a Friday evening.

Neither of those is a scenario I am dressing up for effect. Unpatched server software is one of the most common ways small sites get compromised, precisely because the owner did everything they were told. They kept every plugin updated and still got caught by the layer they could not see. If you want the fuller picture of what you can control directly, our complete WordPress security and backup guide for Irish sites walks through the parts of this that sit in your hands.

I will own one of these myself. Years ago I took a vendor at their word that a client's hosting was fully managed and patched. It was not. The PHP build was two major versions past end of life and had been for a long time. We caught it during a routine review, not because anything had broken yet, which was pure luck. I do not take the words fully managed at face value anymore. I check.

Whose Job Is This, Actually?

Strip away the marketing and this is a question about who is responsible for the engine. There are three broad answers.

On unmanaged hosting, a bare server or a bargain shared plan, the answer is usually nobody, or you. The host keeps the lights on. Patching the PHP runtime, upgrading the database, hardening the web server, all of that is left to whoever set it up, which for most businesses is no one with the time or the knowledge to do it safely.

On genuinely managed hosting, the platform owns that layer. It tracks the end-of-life dates, tests the upgrades, applies the security patches, and does it without you ever needing to know it happened.

Here is the honest concession. If you have a developer or a systems person on the payroll who already monitors your stack and patches it on a schedule, then an unmanaged server genuinely gives you more control, and it can cost less. That is a real and valid choice. But it is a choice that depends entirely on having that person. Most local firms do not, and were never meant to. They are running a business, not a server room.

What a Properly Maintained Stack Actually Does

Forget brand names for a moment. A properly maintained hosting platform does a short list of unglamorous things, continuously:

It runs current, supported versions of the web server, the PHP runtime, and the database, and it moves them forward before they hit end of life, not after.
It tests those upgrades against real sites in a staging environment first, so a major version jump does not silently break a live checkout.
It takes a backup before it changes anything, so there is always a rollback if an upgrade conflicts with an older plugin.
It hardens the server and watches for intrusion, because even fully patched software still needs a locked door.

That is the standard. Any host worth paying should meet it, and you are entitled to ask whether yours does.

This is the layer Web60 was built to own. Sites run on the enterprise-grade Irish stack we keep patched and current for you: managed WordPress on Nginx and PHP-FPM with Redis object caching, kept on supported versions as part of the platform rather than as a favour you have to request. Server-level hardening, fail2ban, and automatic malware scanning sit on top of that. Automatic nightly backups and one-click staging mean the engine can be moved forward safely, with a snapshot taken before anything changes. Keeping that software current is only one of the automated layers a managed platform runs quietly while you sleep. The point is not a longer feature list. The point is that the clock on your server software is somebody's actual job, and that somebody is not you.

One honest limitation, because it matters. No host can upgrade a major version of PHP with zero risk to every plugin you have ever installed. A genuinely abandoned plugin, written for an ancient runtime, can break when the runtime moves on. That is not a reason to sit on dead software. It is the reason staging environments and pre-update snapshots exist: you test the jump, you find the conflict, you fix or replace the offending plugin, then you deploy to production. The alternative, freezing your stack forever to keep one old plugin alive, just trades a small managed risk for a large unmanaged one.

Four Questions That Tell You Who Is Watching the Clock

You do not need to become technical to find out where the responsibility sits. You need four questions for whoever hosts your site.

Which PHP version does my site run on, and when does it lose support? A host that owns this layer answers in a sentence. Vagueness here is the answer.
Do you upgrade server software before it reaches end of life, or after? Before means they are watching the calendar. After, or "when there is a problem", means you are the early warning system.
Do you test upgrades in staging and take a backup first? This is the difference between a controlled deployment and a Friday spent restoring a site that broke during an unannounced change.
If an upgrade breaks a plugin, what happens, and who fixes it? You are checking whether there is a rollback and a person, or just an apology.

You are not trying to catch anyone out. You are confirming whether the responsibility sits with the platform or has quietly landed on you. WordPress.org even publishes a short message you can copy and send your host, asking whether they support the current PHP and database versions. If the replies come back vague, that vagueness is your answer.

Conclusion

Keeping your plugins updated is good practice, and you should carry on doing it. It is also the half of the job you can see. The other half, the web server, the PHP runtime, and the database your whole site sits on, runs out of road on dates set by other people, and it does it in complete silence.

So the useful question is not whether you are updating your site. You almost certainly are. The useful question is who is updating the part you cannot. If that is a platform whose job it is, you can get back to running your business. If the honest answer is nobody, that is worth sorting before a date you never saw slips past in the background.

You can describe your business to Web60 and have a site running on a stack that is kept current for you in about a minute, for sixty euro a year. But whatever you choose, the one thing worth doing this week is simple. Find out who is watching your clock.

Frequently Asked Questions

Do I need to update the PHP version on my WordPress site myself?

On unmanaged or cheap shared hosting, often yes, and that is the problem, because most business owners have no safe way to do it. On genuinely managed WordPress hosting, the provider owns the PHP runtime, the web server, and the database, and keeps them on supported versions for you. The honest test is to ask your host directly: which PHP version does my site run, and when does it lose support? A managed host can answer in a sentence.

What happens if my website runs on an outdated PHP version?

Two things. Once a PHP version reaches end of life it stops receiving security patches, so any vulnerability found after that date stays open on your site indefinitely. Separately, modern WordPress and plugin updates eventually stop supporting old PHP, so an automatic update can hit an unsupported runtime and take a page down, usually the checkout. The site keeps working right up until it does not, which is exactly why the risk is so easy to ignore.

How do I find out which PHP version my website uses?

On a managed platform it is usually shown in your hosting dashboard, and support can tell you straight away. WordPress itself reports it under Tools, then Site Health, then the Info tab, in the Server section. If neither your dashboard nor your host can give you a clear answer, that uncertainty is itself a useful signal about how closely the underlying software is being maintained.

Is MySQL 8.0 reaching end of life a problem for my website?

MySQL 8.0, one of the most widely deployed database versions on the web, reached end of life in April 2026, after which the community version most hosts run no longer receives security patches. Your database holds every page, order, and customer record, so leaving it on an unpatched version is a genuine security exposure. The fix is for your host to move you to a supported version such as MySQL 8.4 LTS or a current MariaDB release, ideally tested in staging first.

Does managed WordPress hosting update server software automatically?

A genuinely managed platform does. It tracks the end-of-life dates for the web server, PHP runtime, and database, tests upgrades against real sites in staging, takes a backup before changing anything, and applies security patches without you needing to know it happened. Cheap shared or unmanaged hosting frequently does not, which is how a site that has run quietly for years ends up on software that stopped receiving security fixes long ago.

Website Server Software: The Updates You Never See, and Why They Matter More Than Your Plugins