The real criterion: who applies the patches
The question "which one is more powerful?" almost always leads to the VPS. The useful question for an agency is a different one: when a critical flaw is disclosed on a Tuesday evening, who patches this client's server? On cPanel shared hosting, the host does. The kernel, the PHP interpreter, the server firewall and the monitoring of the machine are not your job, and you keep the relationship with the client. On a VPS, all of that becomes your scope from the first minute, weekends included. That is not a defect of the VPS: it is the price of the freedom it offers, with root, persistent services and a custom stack. The table below sets each criterion against the person who handles it, because that line, far more than the RAM figures, changes your workload. Here we reason in responsibilities, not raw performance.
Shared hosting and VPS, criterion by criterion
Scroll the table
| Criterion | Shared hosting (who handles it) | VPS (who handles it) |
|---|---|---|
| Root access | No, bounded cPanel accounts: the host | Yes, full: the agency |
| Isolation between sites | cPanel accounts isolated from each other: the host | One VPS per client, or a shared blast radius if several sites live together: the agency |
| Kernel updates | Applied on the shared machine: the host | Planned update then reboot: the agency |
| PHP updates | Patches pushed to the server: the host | Packages to update and test: the agency |
| Firewall | Server firewall: the host | To configure and keep current: the agency |
| Backups | Depends on the plan, weekly on entry plans and daily on Pro and Agency: the host | Strategy to define and test: the agency |
| Monitoring | Machine monitored by the host, site watched by you: shared | Availability, disk, certificates, services: the agency |
| Scaling | Per-account limits, then a higher plan or a VPS: the host and the agency | Resources adjusted on demand, architecture in your hands: the agency |
PHP2Shell: the PHP patch, on shared hosting and on a VPS
On 21 October 2026, the PHP project published the advisory for CVE-2026-109619, nicknamed PHP2Shell, a remote code execution rated critical and fixed in PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. On shared hosting, the host applies the patch; on a VPS, you must update PHP on each machine, then reload PHP-FPM. The dedicated PHP2Shell article details the inventory and the mitigations.
Fragnesia: when the kernel is the agency's
Fragnesia (CVE-2026-46300) is a Linux kernel flaw allowing local privilege escalation to root. On shared hosting, the host schedules the kernel update; on a VPS, the kernel is the agency's, so its maintenance window and its reboot, since a VPS that is never rebooted keeps the old kernel in memory. Check the running kernel with uname -r. The dedicated Fragnesia article details the flaw and the mitigations.
Isolation and backups: what protects a client from the others
On shared hosting, each site lives in an isolated cPanel account: a compromised site does not, in principle, give access to the neighbour's files. On a VPS, isolation depends on how you split things. One VPS per client draws a clear boundary, but multiplies the machines to keep current. Several sites mixed on one VPS lower the bill, but share a common blast radius: a vulnerable plugin on one site exposes all the others, and stolen root access takes them all. For backups, do not generalise. On shared hosting, the frequency depends on the plan: weekly on entry plans, daily on the Pro and Agency plans. Check the plan sheet before promising a restore frequency to a client. On a VPS, nothing is decided for you: the backup strategy, its off-machine destination and above all the restore test are for the agency to define and verify. A backup that has never been restored is still a hypothesis.
How many maintenance hours per month and per site
The figures in the table below are not a benchmark: they are this article's assumptions, to be replaced by your own measurements. They assume one standard Linux VPS per client, run by a competent person, against a site on a shared account whose host runs the machine. The total gives the order of magnitude: about 0.75 h per month and per site on shared hosting, against about 4.5 h per month and per VPS. For twelve clients, that is 9 h against 54 h per month. Compare with your internal hourly rate: if the hours gap, valued at that rate, exceeds the monthly price gap, for the same billing period, between 799 DH/year and 99 DH/month, the VPS costs more than its listed price. Grouping several sites on one VPS divides the hours per site, but enlarges the blast radius. The VPS administration option can move part of these hours to ServOrbit; check its scope on the VPS page. The blog guides are provided, without support coverage.
The article's assumption: maintenance hours per month
Scroll the table
| Task | Shared (per site) | VPS (per server) |
|---|---|---|
| Kernel and reboots | 0 h | 0.5 h |
| PHP and system packages | 0 h | 1 h |
| Firewall and hardening | 0 h | 0.5 h |
| Backups and restore test | 0.25 h | 1 h |
| Monitoring and alerts | 0.25 h | 0.75 h |
| Incidents and on-call | 0.25 h | 0.75 h |
| Total | 0.75 h | 4.5 h |
Decision grid: five yes or no questions
Does traffic durably exceed the plan's limits?
No: shared hosting is enough. Yes, sustained and not a one-off spike: go to question 2. A one-off spike is handled first with caching and a higher plan.
Does the client have several sites or heavy services?
No: stay on shared hosting as long as the process limits hold. Yes: a VPS becomes credible, go to question 3.
Do you need root or persistent services?
No: shared hosting remains the default choice. Yes, for a daemon, a job queue, a specific database engine or a non-standard stack: the VPS is justified, go to question 4.
Must this client be isolated from the others?
Yes, for sensitive data or a contractual requirement: plan a VPS dedicated to this client. No: the per-account cPanel isolation of shared hosting is already enough.
Do you have the administration skills and the on-call cover?
No: do not open a VPS without planned administration, stay on shared hosting or look at the VPS administration option. Yes: the VPS is validated, and you budget the hours from the previous table.
The signals that justify changing model
A hosting model is not chosen once and for all. Two families of signals trigger a migration, in either direction. Towards the VPS, they are technical constraints that keep recurring: the same ceiling hit every month, a service that shared hosting does not allow. Towards shared hosting, it is the opposite: the machine costs more time than it earns. Note the date and cause of every incident tied to limits or administration. A practical rule of this article: a single incident is an accident, three in a quarter are a signal.
Seven migration signals
- Towards the VPS: limited processes or memory — limit errors keep returning despite optimising the site, the plan's ceiling is reached.
- Towards the VPS: root or persistent services — the project requires a daemon, a worker, a search engine or a system version that shared hosting does not offer.
- Towards the VPS: sustained load — the load stays high for several weeks, not only during a one-off campaign.
- Towards the VPS: specific firewall or stack — a network rule, a reverse proxy or a precise runtime becomes a client requirement.
- Towards shared hosting: low traffic — the site fits comfortably in a shared plan and the VPS sits idle most of the time.
- Towards shared hosting: no admin skills available — nobody on the team can apply a kernel or PHP patch within the day.
- Towards shared hosting: on-call load above the value — the maintenance hours exceed what the client pays for the site.
Migrating with minimal downtime: six steps
Back up the source
Take a full backup of the files and the database, then check that it restores on a test machine before touching anything.
Lower the DNS TTL
At least 24 to 48 hours before the switch, bring the record TTL down to 300 seconds, then check with
dig +short your-domain.com.Build the target
Install the stack on the VPS, or create the cPanel account, copy the files and the database, then reproduce the PHP configuration and scheduled tasks.
Test before the switch
Test the target without touching DNS using
curl -I --resolve your-domain.com:443:IP_CIBLE https://your-domain.com/, then walk through forms, payment and mail sending.Switch over
Freeze writes on the source if the site receives any, make a final copy of the database, then change the A record. Keep the TTL short during the switch.
Monitor and close out
Watch the logs for 48 hours, keep the source untouched for a few days, then raise the TTL again and remove the old environment.
A tie-break rule for a portfolio
Start from shared hosting for every new client site, and move to a VPS only on a written signal: a limit reached, a need for root, an isolation requirement. Keep a table per client with the model, the date of the last kernel and PHP update, and the last tested restore. A VPS whose row is out of date is a debt you carry in the client's place.
The official documentation
PHP2Shell security advisory (GitHub, PHP project) : https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
Debian entry for Fragnesia : https://security-tracker.debian.org/tracker/CVE-2026-46300
Security Affairs coverage of Fragnesia : https://securityaffairs.com/192145/security/linux-kernel-bug-fragnesia-allows-local-root-access-attacks.html
Supported PHP versions : https://www.php.net/supported-versions.php
