When a serious vulnerability is announced in PHP, OpenSSH or a popular CMS plugin, the first useful question is not "how bad is it?" but "is this mine to patch?" The answer depends on the kind of service you run on. On web hosting, much of the stack belongs to the provider; on a self-managed virtual server, almost everything above the hardware is yours. This guide draws that line clearly so nothing falls between the two.
The model in one sentence
The provider is responsible for the layers you cannot touch, and you are responsible for the layers you can. Microsoft's widely used shared responsibility description puts it in terms of service models: with infrastructure (IaaS) you manage the virtual machines, operating systems and applications; with a platform (PaaS) you deploy applications without managing the operating system. It also lists what the customer always keeps, whatever the model: the data, the devices used to access the service, user accounts and access management such as multifactor authentication.
On shared or managed web hosting
Hosting plans do not give you root access, so you could not patch the operating system, the web server, the PHP runtime or the database server even if you wanted to. Those are operated by the provider. What remains yours is still substantial:
- Your application: CMS core, plugins and themes, frameworks, and your own code. Most website compromises start here, not in the server.
- Dependencies pulled in with Composer or npm, and keeping them updated.
- Compatibility with supported runtimes: when a PHP branch reaches end of life, the code has to run on a newer one. PHP 8.1 reached end of life on 31 December 2025, and PHP 8.2 receives security fixes only until 31 December 2026 (php.net supported versions).
- Accounts and secrets: panel and CMS logins, multifactor authentication, database passwords and API keys in configuration files.
- Your data and how you use it, including exports and copies you keep elsewhere.
On a self-managed VPS
A VPS with root access is infrastructure. The provider runs the physical servers, the network up to your server, the virtualization layer and the console. From the kernel up, the work is yours:
- Installing operating system security updates, restarting services that use updated libraries, and rebooting for new kernels.
- Choosing and updating the web server, PHP, database and runtimes, including packages from third-party repositories that automatic updates may not cover.
- SSH hardening, the firewall inside the server, TLS certificates and their renewal.
- Monitoring, log retention and alerting.
- Backups and restore tests.
- Moving to a new operating system release before the current one leaves security support.
Side by side
| Layer | Web hosting | Self-managed VPS |
|---|---|---|
| Data centre, hardware, network to the server | Provider | Provider |
| Virtualization, console, billing | Provider | Provider |
| Operating system, kernel, reboots | Provider | You |
| Web server, PHP runtime, database server | Provider | You |
| Firewall inside the server | Provider | You |
| Application code, CMS, plugins, dependencies | You | You |
| Accounts, passwords, MFA, secrets | You | You |
| Backups | Check what the plan includes | You |
| Data, retention and compliance decisions | You | You |
A worked example: a critical PHP release
Take the October 2026 PHP security releases described in our php2shell article. On hosting, updating the PHP runtime is the provider's job; your part is to keep the site on a supported PHP branch and keep the application itself updated. On a VPS, the fix only arrives when you install it: run the package updates for your distribution, restart PHP-FPM or the web server, confirm the running version, and repeat on every server. If PHP comes from a third-party repository, make sure that repository is included in your update process.
Applying this to the hosting plans and the Riyadh VPS
On Skyline Cloud's hosting plans there is no root access, Python or Docker. Each plan includes free SSL certificates renewed automatically and nightly backups of websites and databases kept for 30 days with one-click restore. Your application, its plugins and dependencies, and your accounts remain yours. When you need root, Python or Docker, the answer is a self-managed VPS. The Riyadh VPS gives root SSH and a console-managed cloud firewall that applies outside the server. Support covers the platform: console, billing, networking and reachability. What runs inside the server is the customer's responsibility. Riyadh servers have no image snapshots and no platform-run backups, so plan your own, for example with a backup agent for Linux machines such as Skyline Backup or a tool of your choice.
Questions to ask before you choose
- Who on the team will install updates every week, and who covers when they are away?
- Do you need root, Docker or a language runtime that hosting does not offer?
- Where will backups live, and when did you last test a restore?
- Which software versions does your application need, and how long are they supported?
What you should do
- Write down, for each site or server, which layers are yours, using the table above.
- On hosting, keep the CMS, plugins and dependencies updated and turn on multifactor authentication for every account.
- On a VPS, automate security updates, schedule reboots, monitor the server and keep tested backups.
- Track end-of-life dates for your OS release and PHP branch and plan moves months ahead.
- When a new advisory appears, check the layer first, then act on your part the same day.
Comments
0 total · 0 threads