Shared vs VPS vs Managed Hosting for a Small Business Website or Store
A plain comparison of shared hosting, VPS and managed hosting or PaaS for small business sites and online stores: responsibilities, isolation and performance, the signs a WooCommerce store or Next.js app has outgrown shared hosting, GDPR data residency, and a decision table.

Shared hosting is the cheapest and simplest option and suits a brochure site or a small WordPress store with modest traffic. A VPS (virtual private server) gives you dedicated resources and full control, but you become responsible for patching, security and backups. Managed hosting or a PaaS (platform as a service) sits in between: you get isolation and room to grow while the provider runs the server for you.
The right choice depends less on traffic than on two questions: what does your site actually need to run (PHP and MySQL, or a long-running Node.js process), and who on your side will look after the server at 2am when something breaks? This guide answers both, and ends with a decision table you can use with your developer or agency.
What each hosting model actually gives you
The labels are used loosely by providers, so it helps to define them by what you receive and what you control.
Shared hosting. Your site lives on a server alongside many other customers' sites. You get a control panel, a file area, one or more databases, email, and usually one-click WordPress. You do not get root access, you cannot install system software, and CPU, memory and disk input/output are shared with your neighbours, with per-account limits enforced by the host. It is built for PHP applications such as WordPress and WooCommerce.
VPS. A virtual machine with a guaranteed slice of CPU, memory and disk, running its own operating system. You get root access and can install anything: Nginx, Node.js, Redis, a specific PHP version, Docker. In cloud terminology this is close to what NIST SP 800-145 calls Infrastructure as a Service: the provider runs the hardware and virtualisation, and you manage the operating system and everything on it. An "unmanaged" VPS is exactly that. A "managed VPS" adds some provider support, and how much varies a lot by plan.
Managed hosting and PaaS. Here the provider operates the server or platform and you deploy your application to it. Managed WordPress hosting runs the web server, PHP, database, caching and often core updates for you. A PaaS for Node.js or Next.js lets you push code from Git; the platform builds it, runs it, scales it and issues TLS certificates. NIST's definition of Platform as a Service fits: you control the application and some settings, not the underlying servers or operating system.
A useful shorthand: shared hosting rents you a room in a managed building, a VPS rents you an empty flat you must maintain, and managed hosting rents you a serviced apartment.
Who is responsible for what
The biggest hidden difference between the three is not speed, it is responsibility. Every hosting arrangement has a split between what the provider does and what you do, and outages and breaches tend to happen in the gaps nobody owned.
| Task | Shared hosting | Unmanaged VPS | Managed hosting / PaaS |
|---|---|---|---|
| Hardware, network, data centre | Provider | Provider | Provider |
| Operating system patches | Provider | You | Provider |
| Web server, PHP or Node.js runtime updates | Provider (you pick a PHP version) | You | Provider, usually with a version you select |
| Firewall and SSH access | Provider | You | Provider |
| TLS certificates | Usually automatic | You (for example certbot) | Usually automatic |
| Application updates (WordPress, plugins, npm packages) | You | You | You, though some managed WordPress hosts update core |
| Backups | Often included, check retention and restore process | You | Usually included, check retention and restore process |
| Scaling | Upgrade plan | Resize server, or redesign | Often a setting or automatic |
| Monitoring and alerting | Basic | You | Platform metrics, you add uptime checks |
Two rows deserve emphasis.
Application updates are always yours. No hosting model patches your plugins, theme or npm dependencies for you unless you pay for that service specifically. A WordPress site on excellent managed hosting with an abandoned plugin is still vulnerable. If that work has no named owner, a website maintenance plan with a security and backup schedule is the usual fix.
Backups are only real if a restore has been tested. "Daily backups included" can mean anything from full off-site snapshots kept for 30 days to a single copy stored on the same server. Ask how long backups are kept, where they are stored, whether you can download them, and how a restore is requested. Keep at least one copy you control outside the host's account.
Performance and isolation
On shared hosting, your site competes with other accounts for CPU, memory and disk. Hosts use per-account limits so that one busy site cannot take down the server, but the practical result is that your site is throttled when it hits those limits, and a noisy neighbour can still affect response times. Security isolation depends on how well the host separates accounts. Reputable hosts isolate accounts properly, but you are trusting configuration you cannot inspect.
A VPS gives you a fixed allocation that is yours alone. Response times become more predictable, you can tune the stack (PHP-FPM workers, OPcache, object caching with Redis, Nginx caching), and nothing another customer installs can read your files. The flip side is that a VPS has a hard ceiling too: when you exhaust its memory, processes are killed, and there is no host team watching it unless you pay for one.
Managed platforms vary. Managed WordPress hosts usually run tuned stacks with server-level page caching, which is often faster out of the box than a self-configured VPS. A PaaS typically isolates each application in its own container and can add instances under load. Where you lose some control is in unusual requirements: a specific system library, a long-running background worker, or a cron job that runs for an hour may not be allowed.
For most small business sites, the bottleneck is not the hosting tier but the application: heavy page builders, unoptimised images, too many plugins, slow database queries. Before paying for a bigger server, it is worth a WordPress performance audit covering plugins, database, caching and hosting. Moving a slow site to faster hosting often makes it a slightly less slow site.
When a WooCommerce store outgrows shared hosting
WooCommerce runs well on good shared hosting at small scale. Its published server requirements are modest: a current PHP 8.x release, MySQL 8.0+ or MariaDB 10.6+, a WordPress memory limit of at least 256 MB, and HTTPS. Most decent shared plans meet those on paper.
The trouble starts with what a store does that a brochure site does not. Cart, checkout and account pages cannot be served from a page cache, so every customer in checkout is a live PHP and database request. Order processing, stock updates, emails and scheduled actions run in the background. Payment gateways and shipping plugins make outbound API calls. All of that hits the CPU and process limits that shared accounts are built around.
Signs it is time to move:
- Checkout slows or errors during promotions or email campaigns, while the rest of the site seems fine.
- The host reports you hitting resource limits (CPU, entry processes, memory) or temporarily suspends the account.
- Scheduled actions pile up. In WooCommerce, the Tools > Scheduled Actions screen shows a growing list of pending or failed actions.
- The admin is slow for staff processing orders, especially order search and reports.
- You need software the host will not install, such as Redis for object caching, a specific PHP extension, or a real system cron instead of WP-Cron.
- You need a staging environment with a one-click push and the plan does not offer one.
For most stores in that position, managed WordPress or WooCommerce hosting is the next step, not a raw VPS. It removes the resource ceiling and adds staging, object caching and server-level backups without making you the system administrator. A VPS makes sense when you have a developer or agency who will own the server, or when you need control that managed hosts do not offer. The WooCommerce store setup checklist covers the rest of what a store needs to run reliably.
When a Next.js app outgrows shared hosting
Next.js is a different case. A Next.js app that uses server rendering, API routes, Server Actions, image optimisation or incremental regeneration needs a long-running Node.js process. The Next.js deployment documentation lists the options: a Node.js server, a Docker container, a static export, or a platform adapter. Only the Node.js server and Docker options support every feature.
Traditional shared hosting is designed for PHP requests that start and finish, not for a process that stays running. Some shared hosts now offer Node.js application support through their control panel, but resource limits, build memory and process restarts can be restrictive. So the honest answer is that a Next.js app with server features usually does not start on classic shared hosting at all, and the real choice is between a PaaS and a VPS.
- Static export (
output: 'export') produces plain HTML, CSS and JavaScript that any web server, including shared hosting, can serve. You lose server features such as dynamic rendering, Server Actions, Proxy and on-demand revalidation. - PaaS is the lowest-effort way to run a full Next.js app: Git-based deploys, automatic HTTPS, preview environments per branch, and someone else patching the runtime.
- VPS gives the lowest running cost at steady traffic and full control, at the price of owning the server. The Next.js self-hosting guide recommends putting a reverse proxy such as Nginx in front of the Node.js server, and covers caching and multi-instance considerations you take on yourself.
If you are deciding between WordPress and Next.js in the first place, the Next.js vs WordPress comparison for business websites covers how the platform choice drives the hosting choice.
EU data residency and GDPR
If you serve customers in the EU or UK, where your hosting stores personal data matters. A typical small business site processes contact form submissions, order records, customer accounts, server logs with IP addresses and analytics data, all of which can be personal data.
The main points to check:
- Your host is a processor. Under Article 28 of the GDPR, you need a contract with your hosting provider that covers processing on your behalf, usually called a data processing agreement or addendum. Reputable hosts publish one; make sure it covers the plan you buy.
- Choose the data centre region deliberately. Most VPS, managed and PaaS providers let you select an EU region. Shared hosts may or may not tell you where the server is. Choosing an EU region keeps data at rest inside the EU, which simplifies your records and your privacy notice.
- Region is not the whole story. Chapter V of the GDPR governs transfers of personal data outside the EU/EEA, and access from outside the EU (for example by a provider's support staff or sub-processors in another country) can count as a transfer. Check the provider's list of sub-processors and the safeguards it relies on. For US providers, the European Commission adopted an adequacy decision for the EU-US Data Privacy Framework on 10 July 2023, which covers transfers to US companies certified under the framework; other providers typically rely on standard contractual clauses.
- UK businesses follow the UK GDPR, and the ICO's international transfers guidance explains the UK's equivalent mechanisms.
- Backups and logs count. Backups stored with a third-party storage service, log shipping to a monitoring tool, and CDN edge caches are all places personal data can end up. Your data map should include them.
- Security is your obligation regardless of model. Article 32 requires appropriate technical and organisational measures. On a VPS that includes the server hardening you do yourself.
*This is general information, not legal advice. Confirm your obligations with a qualified data protection adviser.*
Decision table
Use this as a starting point. Most small businesses should pick the simplest row that meets their requirements and only move down when a specific limit is reached.
| Your situation | Sensible choice | Why |
|---|---|---|
| Brochure or lead-generation site on WordPress, low to moderate traffic, no in-house technical staff | Good-quality shared hosting or entry managed WordPress | Lowest cost, host handles the server, you handle plugin updates |
| WooCommerce store, small catalogue, steady order volume | Managed WordPress or WooCommerce hosting | Staging, backups and object caching without server administration |
| WooCommerce store hitting resource limits, or running promotions with traffic spikes | Higher-tier managed WooCommerce hosting, or a VPS run by a developer or agency | Removes shared limits; VPS only if someone owns patching and monitoring |
| Next.js marketing site with no server features | Static export on any host or CDN, or a PaaS | Static files are cheap to serve and have almost no attack surface |
| Next.js app with server rendering, Server Actions or APIs, small team | PaaS | Git deploys, automatic HTTPS and runtime patching handled for you |
| Next.js or Node.js app with steady traffic, cost-sensitive, technical owner available | VPS with Nginx and a process manager | Predictable cost and full control, in exchange for owning the server |
| Unusual requirements: custom system software, background workers, specific data location controls | VPS or managed VPS | Full control over the stack and region |
| Strict EU data residency requirements | Any model, provided the region, sub-processors and DPA check out | Location and contracts matter more than the hosting type |
Two warnings apply to every row. First, a VPS without a named owner for security updates and backups is riskier than shared hosting, not better. Second, do not choose hosting purely on headline price: compare what is included (backups, staging, support response, TLS, email) and what each extra will cost as you grow.
Related: securing a new Ubuntu VPS, deploying Next.js on a VPS.
If you are unsure which row you are in, or you want the server side handled for you, website maintenance covers hosting choice, updates, backups and monitoring as an ongoing service, so the responsibilities in the table above all have an owner.
Related posts

How to Secure a New Ubuntu VPS: A Setup Checklist for Business Websites
A step-by-step hardening checklist for a fresh Ubuntu 26.04 or 24.04 LTS VPS that will host a business website, with copy-paste commands for SSH keys, ufw, unattended-upgrades, fail2ban, time sync, swap, monitoring and backups.
Read article →

Deploy a Next.js 16 App on a VPS with Nginx, systemd or PM2, and HTTPS
A working guide to running Next.js 16 on your own VPS: Node.js LTS, build-time versus runtime environment variables, a systemd unit and PM2 alternative, an Nginx server block with certbot HTTPS, the standalone output option, logs, and a two-port release script.
Read article →

Business Email Compromise and Invoice Fraud: How Small Businesses Stop It
A defensive guide to business email compromise and invoice fraud for small businesses: how the scams work at a high level, the red flags, the payment and email controls that stop them, and what to do in the first hours after a fraudulent transfer in the US, UK and EU.
Read article →
Author
Anushka Dahanayake
Anushka Dahanayake builds SEO-focused websites, e-commerce platforms, dashboards, and automation systems for businesses worldwide.
