Shared Hosting or VPS? How to Decide for Your Website

Most sites that move to a VPS move for the wrong reason: the site felt slow, and a bigger product sounded like the fix. Sometimes it is. Often the same slow plugin runs just as slowly on four cores. This post is about telling the two cases apart with measurements. If you want the definitions first, what is a VPS explains how shared, VPS and dedicated differ; here we assume you know and need to choose.

Signals that actually mean "move"

There are five that matter. Anything else is usually a tuning problem.

1. You hit the account limits at normal traffic. On a CloudLinux server every account has caps on CPU, memory, disk I/O and entry processes, the number of requests being handled by PHP at the same moment. How LVE limits work has the detail. Hitting a limit once during a sale is normal. Hitting it every weekday at 11:00 is a signal.

2. You need root or system software. A Node or Python service, Docker, Redis with your own configuration, a custom PHP extension, a VPN, a non-standard port. No shared plan gives you these, however large.

3. You need long-running or background processes. Queue workers, websocket servers, a scheduler that runs every minute and takes minutes. Shared hosting is built for requests that start and finish; persistent daemons get killed.

4. Memory, not CPU, is the ceiling. Imports, image processing, large exports and report generation that fail with memory errors even after the code is reasonable.

5. You need isolation for a contractual reason. A client or auditor requires a dedicated IP, your own firewall rules or your own operating system.

Traffic alone is a weak signal. A cached brochure site can serve a great deal on shared hosting, while an uncached shop can saturate its PHP workers with a few dozen simultaneous customers.

Measure before you decide

Check the limit faults

In DirectAdmin on a CloudLinux server, open Resource Usage. It shows CPU, memory, I/O and entry process graphs for your account, and a faults count: the number of times a request was slowed or refused because a limit was reached. Look at a full week. Faults clustered at one time of day point at a cron job or a backup plugin, not at your hosting tier.

Estimate how many PHP workers you need

Concurrent PHP requests are roughly uncached requests per second multiplied by average response time. Five uncached requests a second at 0.4 seconds each is two workers busy at once. The same five requests at 3 seconds each is fifteen, and that is where sites fall over. Halving response time doubles capacity without changing plans.

Download the access log from the panel and count what actually reaches PHP, per hour:

# requests per hour, busiest first
awk '{print $4}' access.log | cut -d: -f1,2 | sort | uniq -c | sort -rn | head

# the same, ignoring static files
grep -vE '\.(css|js|png|jpe?g|gif|svg|webp|woff2?|ico)[ ?]' access.log \
  | awk '{print $4}' | cut -d: -f1,2 | sort | uniq -c | sort -rn | head

Divide the busiest hour by 3,600 for an average rate, and assume the peak minute is several times higher.

Tip: look at who is making those requests before sizing anything. On many small sites the busiest client is a bot hammering wp-login.php or xmlrpc.php:

awk '{print $1}' access.log | sort | uniq -c | sort -rn | head
grep -c 'wp-login.php' access.log

Blocking that is cheaper than a VPS.

Check the cheap fixes first

Before paying for more, confirm that a page cache is active, that PHP is on a current version (changing it in DirectAdmin takes a minute), and that no single plugin accounts for most of the response time.

Decision table

What changes operationally when you move

This is the part people underestimate. A shared plan is a finished service. An unmanaged VPS is a computer.

Two details from our own products show what to ask any host. Our shared plans include daily off-site backups kept 14 days; a Cloud VPS includes a daily snapshot of the previous 24 hours and anything older is your job. And outbound SMTP ports 25, 465 and 587 are closed by default on a Cloud VPS and opened on request, so a site that sends its own mail needs that arranged before the move.

Tip: email is the usual surprise. If the shared account hosts your mailboxes, decide where they will live before you migrate. Moving the site and leaving mail where it is, with only the web records in DNS changed, is a perfectly good design.

The first hour on a new server should go on hardening it, before any site is copied across.

What it costs

Prices from our current list, in USD per month. Paying annually costs ten months.

The interesting comparison is Pioneer Pro at $11.99 against Cloud VPS S at $8.49. The VPS is cheaper and has more raw resources. It also arrives without a control panel, without mailboxes and without anyone patching it. Add a panel licence if you want one (check the vendor's current price list), and add your own hours. If those hours are worth anything, the honest comparison for a non-administrator is shared against Managed VPS, and that is a step from about $12 to about $35.

After the move: check you sized it right

Give the server a week of real traffic, then look:

free -h              # "available" is the number that matters, not "free"
vmstat 5 5           # si/so above zero means swapping; wa is time waiting on disk
uptime               # load average against your core count
df -h                # disk space

If available memory stays comfortable and load stays below the number of cores at peak, the plan fits.

Tip: do not cancel the shared account on migration day. Keep it for a week, lower the DNS TTL before you switch, and you have a way back that takes minutes.

The short version

Stay on shared hosting until a measurement says otherwise: repeated limit faults after caching, a need for root, or background processes. Move to a self-managed VPS only if someone will own the server every month.