What we do · Data and web
PHP upgrades and fleet-wide security patching
End-of-life PHP never receives the fix for the next exploited vulnerability. We move applications onto supported PHP without breaking them, and when a critical flaw lands we get the fix onto every server we manage the same day, one host at a time, with a rollback ready at every step.
What it is
Two services that share one discipline:
- Planned upgrades: moving an application from an old PHP branch to a supported one, including commercial software protected with encoders, on plain Linux, Plesk and cPanel with CloudLinux.
- Emergency patching: when a critical PHP vulnerability is disclosed, a stopgap in front of your application within the hour, followed by the patched PHP rolled out across the fleet as soon as it exists.
How we build it
Side by side, never over the top. The new PHP version is installed next to the old one. The cutover is a single reversible change of the FastCGI socket or pool, and the old version keeps running as the rollback path until a clean burn-in period has passed.
Proof before the jump. Before a major upgrade we compile check every PHP file in the application under the target version, trace which files real traffic actually loads (including logged-in paths), and verify encoded files by reading their headers rather than trusting a vendor's compatibility banner. Problems surface on our bench, not on your checkout page.
A stopgap first. When a critical vulnerability is disclosed, we do not wait for packages. We disable the affected feature in configuration where that is possible, and deploy a load balancer rule that rejects the triggering input in request bodies, query strings and cookies.
Our own builds when mirrors lag. If distribution repositories are slower than the threat, we build the patched PHP ourselves from upstream source, tagged so that the official package replaces it automatically when it arrives.
Same day, with you informed. Emergency patches go out the same day the fix exists. You are kept informed at each step, and if a patch needs downtime on your service, we agree it with you first. Planned upgrades follow the same rule: if a change could touch your traffic, we agree the timing with you before we start.
One host at a time. Rollouts go server by server, with a health check before and after each one. On cPanel and Plesk fleets, a timer watches for the vendor's fixed builds and rolls them out with a health gate across a sample of live sites on each server; any regression halts the rollout.
What it protects you from
- Running a PHP version that will never be patched against an actively exploited flaw.
- An upgrade that breaks the site with no quick way back.
- An actively exploited flaw left open after its fix has been published.
- Encoded commercial software that refuses to load after an upgrade.
- A patch campaign that stops halfway because one server misbehaved and nobody noticed.
In practice
Same-day response across the customer fleet. When a critical PHP vulnerability is reported in the wild, our edge and configuration stopgap goes live ahead of the upstream release, and our patched builds follow within hours. Multi-blade publishing clusters, application hosts on the newest PHP branch, and individual customer Plesk, cPanel and plain Linux servers are patched one by one, with a single graceful worker restart of about a second and no change in uncached render time.
Upgrades that reach the logged-in paths. On commercial PHP applications we test not only the public pages but the paths only logged-in users and administrators reach, because that is where retired modules and stale files hide. Every step of the upgrade can be undone with a single configuration change.
Why EuroVPS
- A same day response to critical PHP flaws across the whole managed fleet, with you kept informed and any downtime agreed first.
- We build from upstream source when packages are late, and let official packages take over cleanly.
- Every upgrade has a one step rollback, kept until burn-in ends.
- Plesk, cPanel with CloudLinux and plain Linux, handled with the same method.
- A written record of every server patched, with the before and after checks.
FAQ
Which PHP versions do you support? Any branch your application needs during migration, with a plan to reach a supported branch. We will not leave a managed server on an end-of-life branch without telling you.
Will an upgrade break our plugins or encoded modules? We find out before the cutover, by compile checking and tracing real traffic. Anything incompatible is listed with options before we switch.
Do we get downtime during patching? On multi node stacks, no: nodes are patched one at a time behind the load balancer. On a single server, a PHP-FPM restart takes about a second, and if any downtime is needed we agree it with you first.
How do we know it was done? You receive a record of what was changed, when, and the health checks before and after.
Want PHP that is current, and stays that way? Talk to an engineer.
Your next infrastructure partner
Let’s look at
your setup.
Tell us what you run today and what needs to improve. An engineer will review your brief and help you plan the next step.
+357 222 32280
who will look after your infrastructure.
Let’s start with your setup.
A little context helps us start the right conversation.