In short: Whether managed hosting or a root server is more secure is decided less by technology than by the question of who installs updates reliably. With managed hosting, the provider does this to the agreed extent; with your own root server, your team or a service provider does. For companies without server expertise, managed hosting is usually the safer choice. Those who need control and have a supporting team can be just as safe with their own server.
What PHP2Shell revealed about operating models
The situation in October 2026 was a practical test. On 21 October at 4 p.m. German time the patches appeared, and the BSI (German Federal Office for Information Security) recommended an immediate update. Anyone on a managed plan had to do one thing above all: ask the provider and have the patch level and restart confirmed. Anyone who ran their own server had to act themselves, often in the evening or at the weekend.
Both had their pitfalls. For managed customers, the panel could continue to show an old version number, such as 8.2.34, even though a backport had been installed; without confirmation from the provider, the status then remained unclear. Operators of their own servers faced the question of whether they had the right packages and whether all PHP processes had been restarted. The basic responsibilities are described in Managed servers: clarifying responsibility and Securing root servers and vServers yourself. This page is about the decision between the two.
Managed hosting or root server: the comparison
| Criterion | Managed hosting | Own root server or vServer |
|---|---|---|
| Who patches PHP and the operating system? | The provider, to the agreed extent | You or your service provider |
| Speed with critical vulnerabilities | Depends on the provider’s processes | Depends on your availability |
| Control over configuration | Limited, often only via panel or request | Complete |
| Interim measures at server level | Only possible through the provider | Can be implemented yourself |
| Evidence of the patch level | Confirmation from the provider needed | Can be checked yourself via the package changelog |
| Expertise needed in-house | Low for the server, the application stays with you | High, permanently |
| Special requirements, old software | Often not possible | Possible, but your own risk |
| Search for traces after incidents | Logs and access only by arrangement | Full access, but own expertise needed |
| Dependence | On the provider and its contract | On your team and its availability |
The table shows: both models shift responsibility, neither removes it. With managed hosting you offload server maintenance but keep the duty to ask and to secure your application. With your own server you keep everything, weekends included.
Five questions for choosing the operating model
- Is there a person in-house with server expertise who is also covered during illness or holiday? If not, an own server without external support is risky.
- Does your application need special configurations, its own services or old software? If so, managed hosting often reaches its limits.
- How critical is the website for revenue or operations? The more critical, the more important are clear commitments on updates and availability, whatever the model.
- Which data do you process? With sensitive data, evidence and log access count. Clarify whether your provider hands over logs in an emergency.
- How many websites do you run? Many similar sites can be efficiently bundled on a well-maintained server of your own. Individual sites are often better off in managed hosting.
The hybrid forms that work well
Between the two poles there are models that often work best in practice. The most common is the own server with external support: you keep control of configuration and data, and a service provider takes over updates, monitoring and emergency response according to fixed arrangements.
A second variant is managed hosting with a supplementary security review. The provider maintains the server, and an independent service provider regularly checks the application, plugins and traces that lie outside the managed scope. For simple websites, finally, shared hosting remains a reasonable solution if the host patches reliably and the website has no special requirements.
Important in all models: automatic security updates for the operating system, regularly tested backups and two-factor login for all access are foundations that apply regardless of the model. Anyone who sets up automatic updates on their own server must still check that PHP processes are restarted afterwards; why that is decisive is explained in After the update: restarting PHP-FPM and all workers.
No operating model relieves you of responsibility for your application and your data. Even with managed hosting, the CMS, plugins and admin accounts must be maintained and data breaches assessed by you.
When a switch makes sense, and when it does not
A switch is worthwhile if PHP2Shell revealed a structural weakness: your team could not patch its own server in time, or your managed provider did not respond to queries and supplied no evidence. What to look out for when changing providers is described in Changing hosts after a security incident.
A single event that better arrangements could have resolved, on the other hand, is no good reason for a switch. Often it is enough to supplement the existing contract with provisions on security updates, restarts and information about critical vulnerabilities.
Also consider the timing. A move in the middle of an acute situation ties up exactly the resources that are needed for patches and the search for traces. It is better to secure the current server first and then plan the switch calmly, with a clean rebuild instead of a copy of the old system.
How does PHP SOS help?
- We compare your current model with your actual requirements and show where responsibility is unclear.
- We check managed providers’ service descriptions for the points that count in an emergency.
- For own servers, we take over updates, hardening and monitoring under a security maintenance contract.
- For a switch, we accompany the move so that no old access or unchecked data migrates with it.
Conclusion
Managed hosting is the safer choice for companies without server expertise, the own server the more flexible one for teams with expertise and commitment. Hybrid forms often do best, in which it is clearly settled who patches, who restarts and who responds in an emergency.
Frequently asked questions
Is managed hosting fundamentally more secure than a root server?
Not fundamentally. Managed hosting is more secure if the provider installs updates reliably and you have little server knowledge yourself. A well-maintained own server can be just as secure, but it permanently requires time and expertise.
Who is responsible for PHP updates on a root server?
As a rule, you are. The data centre operator usually only takes care of hardware, network and virtualisation. The operating system, PHP, web server and application are with you or your service provider.
Can I set my own PHP settings with managed hosting?
Often only to a limited extent. Many providers allow changes via a panel or on request. For interim measures such as with PHP2Shell, some settings have to be applied server-wide; that is then only possible through the provider.
What about shared hosting?
Shared hosting is the simplest form of managed hosting. The provider maintains the system for many customers at once. You have hardly any influence on the PHP version and configuration, but you also hardly need to worry about it.
Is it worth changing the operating model after PHP2Shell?
Only if the situation exposed a real weakness, for example that nobody could patch your own server in time. A gut-feeling switch rarely solves the actual problem.