When to Move from Shared Hosting to a VPS

Shared hosting does what it promises for a specific set of workloads: it runs PHP, serves WordPress, and keeps a simple site online without requiring you to know anything about servers. For a blog, a portfolio site, or a small business landing page, that is entirely sufficient.

The ceiling appears the moment you try to run something that shared hosting was never designed to support. Not "it would work better on a VPS" but that it genuinely will not work at all. This article covers those situations specifically: the workloads where moving to a VPS is not a performance upgrade, it is a prerequisite.

What Shared Hosting Actually Restricts

For a PHP CMS like WordPress or a static site, most of those restrictions are invisible. For anything else, at least one of them is a hard wall.

Persistent Processes: Spring Boot, Node.js, and Any Non-PHP Runtime

The clearest technical dividing line is this: shared hosting cannot run a persistent process.

Spring Boot is the most concrete example. A Spring Boot application starts an embedded Tomcat server when it launches. That process listens on a port, maintains database connection pools, runs background task schedulers, and keeps itself alive indefinitely between HTTP requests. Deploying one requires a Linux server with Java installed, a process manager (systemd is the standard choice), and Nginx proxying inbound requests to the application's local port.

Shared hosting provides none of that. There is no mechanism to start a long-running Java process, keep it running across requests, or expose it to the public internet on a shared plan. The same constraint applies to:

• Node.js applications (Express, Fastify, NestJS, Hono)
• Python applications deployed with Gunicorn or Uvicorn (Django, Flask, FastAPI)
• Ruby on Rails with Puma
• Any Go, Rust, or other compiled binary HTTP server

Some shared hosts advertise "Node.js hosting" via cPanel's NodeJS Selector, which runs applications through Passenger. This works for simple demos. For production applications with real user traffic, Passenger on shared infrastructure brings its own constraints: limited environment control, restricted package management, and shared CPU that disappears under sustained load. Most developers who have tried it describe it as fighting the hosting infrastructure rather than building software.

If your application is not PHP, you very likely need a VPS.

High-Traffic WordPress and WooCommerce

WordPress on shared hosting is not inherently problematic. The issue is what shared hosting does under resource-intensive WordPress workloads.

Shared hosts enforce memory limits per PHP process, execution time limits per request, and database rate limits. These exist to protect other tenants on the same server. They also prevent things that are entirely normal operations on dedicated infrastructure: running WP-CLI scripts in the background, batch-regenerating image thumbnails after a theme switch, or handling a traffic surge without the server choking on concurrent database connections.

WooCommerce compounds this. Each transaction involves multiple database writes. Cart recovery plugins run background workers. Inventory sync tools poll external APIs. Any of these can push a shared host into throttling or account suspension.

On a VPS, PHP memory limits, MySQL configuration, and server-level caching (Redis, Memcached) are yours to tune. The ceiling is your plan's allocated RAM and CPU, not a shared pool being consumed by every other account on the machine.

A low-traffic store is fine on shared hosting. A store with variable promotion-driven spikes, complex product catalogs, and third-party integrations will reliably encounter shared hosting limits in ways that affect customers directly.

Background Jobs, Queues, and Scheduled Tasks

Shared hosting does offer cron job scheduling, usually through cPanel. The implementation is limited by design: minimum execution intervals are often coarser than application needs (some providers restrict to no finer than every five or fifteen minutes), jobs run as the web user with minimal permissions, and there is no way to run a persistent background worker watching a queue.

If your application depends on any of the following, you need a VPS:

• A message queue (RabbitMQ, Redis Streams, SQS, Kafka)
• Background email delivery via a queue worker instead of synchronous SMTP
• A task dispatcher using Celery (Python), Bull or BullMQ (Node.js), or Sidekiq (Ruby)
• A file processing pipeline that handles uploads, resizes images, or transcodes video
• A reporting job that aggregates database records on a schedule
• A data sync job that polls external APIs at regular intervals

These are ordinary requirements for any application doing real work. Shared hosting was not built for them.

WebSockets, Game Servers, and Other Real-Time Workloads

Some workloads fail on shared hosting for the same underlying reason: they require a persistent, low-latency connection that consumes memory proportional to the number of active users or players.

WebSockets establish a two-way persistent connection between browser and server, with no new HTTP request for each message exchange. Apache and Nginx on shared infrastructure are not configured to proxy WebSocket connections, and you have no access to change that. Holding open connections per active user also consumes memory in a sustained way, which is exactly what shared hosting caps most aggressively. Chat, live dashboards, collaborative editing, real-time notifications: all require WebSocket support. Technologies like Socket.IO (Node.js), Phoenix Channels (Elixir), and ActionCable (Rails) all depend on it.

Game servers (Minecraft, Valheim, CS2, Rust) require a persistent process, sustained CPU, fast disk I/O, and low latency to players. Shared hosting rules out all four. The specification that matters most varies by game: Minecraft Java Edition is largely single-threaded, so single-core CPU performance is the binding constraint. Games with larger concurrent player counts care more about network throughput. User reviews from operators running the same game on a given provider are more useful than the spec sheet here.

Not every VPS use case is a public-facing application. A significant portion of VPS customers use them to run tools for their own teams: private Git repositories, cloud storage, password managers, analytics servers, uptime monitors.

The economics work at the lower end of the VPS market. Entry-level plans from budget providers (see IONOS as one example currently reviewed on this site) are inexpensive enough that running several of these on a single small VPS often costs less per month than separate SaaS subscriptions for the equivalent tools.

Signs You Are Already Past the Limit

Some of these are obvious; some are easy to misread as something else.

1. Intermittent 500 errors under traffic that disappear on a reload. The shared memory or CPU limit was hit mid-request. The request was killed. The next one succeeded because the queue cleared briefly.

2. WordPress taking five or more seconds to load on the first uncached request. PHP execution and database query time are being constrained. The same site on a properly configured VPS with object caching would typically return far faster.

3. A resource usage warning from your host. Shared hosts enforce usage limits to protect other tenants. A formal warning means you are legitimately taxing the shared infrastructure, and suspension is the next step.

4. You need to run apt install on the server. Root access and the ability to install OS packages are a prerequisite for a large category of real workloads.

5. Deployment still involves FTP uploads. Not disqualifying on its own, but paired with any of the above it is a signal that the infrastructure no longer fits the workload. A VPS with SSH access and Git-based deploys removes a significant amount of friction.

Which Use Case Fits You?

Moving Forward

If any of the above describes your situation, the next step is choosing a provider. VPS plans vary considerably on CPU allocation model, bandwidth terms, included features, and how honest the pricing is. The VPS provider evaluation guide covers the six dimensions worth checking before you commit.

For comparing specific providers with current user reviews, the providers directory is a good starting point. The OVHcloud vs Contabo comparison goes deep on two budget-end options if cost is the primary constraint.