The Problem: Picking a VPS Plan Is Overwhelming

You have a project in mind — a WordPress site for your business, a Docker host for your side project, a media server for the family — and you know you need a virtual private server to run it. But when you look at VPS plan pages, every option blurs together. 1 vCPU or 4? 2 GB RAM or 16? 40 GB storage or 200?

Pick too small and your site slows to a crawl during traffic spikes. Your database connection drops. Your Docker containers fight for resources and restart randomly. Pick too large and you are paying for capacity you will not use for months — money that could be better spent on development, marketing, or subscriptions.

We help hundreds of customers choose their first VPS (or upgrade to the right one) every year at Canadian Web Hosting. After seeing every workload on every tier, patterns emerge. Here is what we have learned about matching server specs to real-world projects.

Quick Reference: Workload Size Chart

If you know what you are running, jump straight to your workload:

Workload Minimum Recommended Advanced
Single WordPress site (low traffic) 1 vCPU, 1 GB RAM 2 vCPU, 4 GB RAM 4 vCPU, 8 GB RAM
Business WordPress + WooCommerce 2 vCPU, 2 GB RAM 2 vCPU, 4 GB RAM 4 vCPU, 8 GB RAM
Self-hosted apps (Nextcloud, Vaultwarden, etc.) 1 vCPU, 2 GB RAM 2 vCPU, 4 GB RAM 4 vCPU, 8 GB RAM
Docker host (multiple containers) 2 vCPU, 2 GB RAM 2 vCPU, 8 GB RAM 8 vCPU, 16 GB RAM
Database server 1 vCPU, 2 GB RAM 2 vCPU, 8 GB RAM 8 vCPU, 16+ GB RAM
CI/CD runner 2 vCPU, 4 GB RAM 4 vCPU, 8 GB RAM 16 vCPU, 32 GB RAM
Media streaming (Jellyfin/Plex) 2 vCPU, 4 GB RAM + GPU 4 vCPU, 8 GB RAM + GPU 8 vCPU, 16 GB RAM + GPU
Small business all-in-one (5-10 users) 2 vCPU, 4 GB RAM 4 vCPU, 8 GB RAM 8 vCPU, 16 GB RAM

Ops Note: Measure Peak Behaviour, Not Average Behaviour

In hosting operations, averages are where bad sizing decisions hide. A server can look quiet all day and still fall over during backup jobs, malware scans, imports, or a traffic spike. When we review CWH server issues, the useful data is usually peak memory, swap activity, disk growth, and whether the workload recovers cleanly after pressure. Size for the busiest normal hour, then leave enough headroom for maintenance tasks.

How We Think About Server Sizing

When we help customers choose a VPS plan, we start with three questions:

  1. What software is actually running? — A single WordPress site consumes far fewer resources than GitLab or Jellyfin, even on the same VPS.
  2. How many people will use it concurrently? — Five team members using Nextcloud is very different from fifty.
  3. What is your acceptable performance floor? — If a page load taking three seconds costs you sales, you need more headroom than if you are just testing an idea.

The numbers below assume a standard Linux server running Ubuntu 24.04 LTS with modest swap (~2 GB). We subtract approximately 256-512 MB for the operating system itself before calculating available resources for your application.

1. WordPress and WooCommerce Sites

WordPress itself is lightweight — the official requirements are minimal. What eats resources is PHP processing: every visitor triggers PHP execution, database queries, plugin loading, and theme rendering.

How PHP-FPM Memory Works

Each PHP-FPM worker process consumes approximately 30-50 MB of RAM. The more concurrent visitors your site has, the more workers you need. The formula is straightforward:

pm.max_children = available_RAM / average_memory_per_worker

A 1 GB VPS has roughly 700 MB available after the OS boots. That gives you about 14 PHP-FPM workers — enough for one low-traffic WordPress site but tight for WooCommerce with multiple concurrent shoppers.

A 4 GB VPS has about 3.5 GB available, supporting roughly 70 workers. That comfortably handles a business WooCommerce store with dozens of concurrent visitors, multiple plugins, and a reasonable admin panel response time.

What This Means for Your Choice

Scenario Recommended VPS Specs CWH Product
Personal blog, under 1,000 monthly visitors 1 vCPU, 1 GB RAM, 25 GB SSD Shared Hosting or Cloud VPS VPS1
Business site, 1,000-10,000 visitors/month 2 vCPU, 4 GB RAM, 80 GB SSD Cloud VPS VPS3
WooCommerce store with 1,000+ products 4 vCPU, 8 GB RAM, 160 GB SSD Cloud VPS VPS5
Multiple WordPress sites (5+) 4 vCPU, 8 GB RAM, 200 GB SSD Cloud VPS or Managed WordPress (per site)

2. Self-Hosted Applications

This category covers the apps people most commonly self-host on a VPS: file sharing, password management, team chat, project management, and automation tools. Resource needs vary dramatically by application.

Lightweight Apps (Under 512 MB RAM)

  • Vaultwarden (Bitwarden-compatible password manager) — 50-100 MB RAM idle, runs comfortably on a 1 GB VPS alongside other services. SQLite by default, tiny storage footprint.
  • Nginx or Caddy as a reverse proxy — ~30-50 MB RAM. Negligible overhead.
  • Miniflux or FreshRSS (RSS reader) — ~100-200 MB RAM with a moderate number of feeds.
  • Gitea (lightweight Git server) — ~200-300 MB RAM for a small team.

Medium Apps (1-2 GB RAM)

  • Nextcloud (file sync and share) — Officially recommends 512 MB minimum, but practical use for 5+ users with file versioning calls for 1 GB. Storage scales with your files.
  • Mattermost (team chat) — ~1 GB RAM for 10-25 users. Database grows with message history.
  • Jellyfin (media server, direct play only) — 4 GB minimum per official docs, but runs well at 4 GB with no transcoding.

Heavy Apps (4+ GB RAM)

  • GitLab — The heavyweight champion of self-hosted apps. Official minimum is 8 GB RAM, recommended 16 GB for 1,000 users. This is the one app that can dominate even a mid-range VPS.
  • Jellyfin with hardware transcoding — 8 GB recommended. GPU essential for anything beyond direct play. CWH GPU Dedicated Servers with RTX A4000/A5000 are ideal for media transcoding.

Practical Tier Recommendations

Stack Minimum Recommended Storage
Vaultwarden + Nginx + basic site 1 vCPU, 1 GB 1 vCPU, 2 GB 25 GB SSD
Nextcloud + Vaultwarden + Gitea 2 vCPU, 2 GB 2 vCPU, 4 GB 80 GB SSD
Full suite (Nextcloud + Mattermost + GitLab) 4 vCPU, 8 GB 4 vCPU, 16 GB 200 GB SSD

3. Docker Hosts and Container Platforms

Running applications in Docker adds a small overhead — about 50 MB for the Docker daemon plus roughly 20-50 MB per running container. The real resource consumption comes from the applications inside the containers, not Docker itself.

What Adds Up

  • The daemon — ~50 MB RAM, negligible CPU when idle.
  • Each container — ~20-50 MB overhead on top of the application itself.
  • Build cache — Can grow to 10-20 GB quickly if you rebuild images frequently. Plan storage accordingly.
  • Log files — Docker defaults to JSON-file logging without rotation. A busy container can generate gigabytes of logs in days. Configure logrotate or switch to the local log driver.

Capacity Planning

Container Count Minimum RAM Recommended RAM Storage
3-5 small containers (Nginx, DB, app) 2 GB 4 GB 40 GB SSD
10-15 containers (microservices, dev tools) 4 GB 8 GB 100 GB SSD
20+ containers (CI runners, staging, prod) 8 GB 16 GB 250+ GB SSD

Pro tip: Use docker stats after setting up your stack to see real memory and CPU usage per container. You can then right-size your VPS based on actual data rather than estimates.

# Check real container resource usage
docker stats --no-stream

# Set per-container memory limits to prevent one app from starving others
docker run -d --memory="512m" --memory-reservation="256m" your-image

4. Database Servers

Databases have a deceptively simple resource profile: they want RAM and fast storage. More RAM means more data cached in memory, which means fewer slow disk reads. The rule of thumb: your database server should have enough RAM to hold at least 50-80% of your active data set.

MySQL / MariaDB

The innodb_buffer_pool_size parameter — which caches data and indexes in memory — should be set to 70-80% of available RAM on a dedicated database server. A 10 GB database on a 4 GB VPS will hit swap performance almost immediately.

PostgreSQL

PostgreSQL uses shared_buffers at roughly 25% of RAM (up to 40% maximum). Each connection adds 2-10 MB of overhead. PostgreSQL performs best on SSD storage — official docs strongly recommend SSD for any database over 1 GB.

Practical Sizing

Database Size Minimum RAM Recommended RAM Storage
Under 1 GB (small app, blog) 1 GB 2 GB 20 GB SSD
1-10 GB (business app, e-commerce) 4 GB 8 GB 50-100 GB SSD
10-50 GB (heavy workload, analytics) 8 GB 16 GB 200+ GB NVMe

5. Media Streaming: When You Need a GPU

Media servers like Jellyfin and Plex are unique because their bottleneck is not CPU or RAM in the traditional sense — it is transcoding capability. Direct play (streaming a file in its original format) uses almost no resources. Transcoding (converting the video on the fly to a different resolution or codec) is extremely demanding.

Key numbers from Plex community experience:

  • ~2,000 PassMark per 1080p transcode stream
  • 8,000-12,000 PassMark per 4K transcode stream
  • 10 Mbps bandwidth per 1080p stream, 40+ Mbps per 4K stream

A CPU-only 4K transcode can require a Ryzen 9-class processor for a single stream. This is where hardware transcoding shines — a modern GPU handles the same workload at a fraction of the CPU cost. CWH GPU Dedicated Servers with NVIDIA RTX A-series cards are excellent for this use case.

Use Case Specs Key Requirement
Direct play only (no transcoding) 2 vCPU, 4 GB RAM Large HDD for media files
1-2 concurrent 1080p transcodes 4 vCPU, 8 GB RAM + GPU Intel Quick Sync or NVIDIA GPU
Multiple 4K streams 8 vCPU, 16 GB RAM + GPU Enterprise GPU (RTX A5000+)

6. Small Business All-in-One Server (5-10 Users)

This is one of the most common scenarios we see: a small team that wants to run their own email, file sharing, password management, and perhaps a team chat platform — all on one server. The combined resource budget looks like this:

  • Email (Postfix/Dovecot): ~512 MB RAM
  • Team chat (Mattermost): ~1 GB RAM
  • File sharing (Nextcloud): ~1 GB RAM
  • Password manager (Vaultwarden): ~256 MB RAM
  • Shared database (PostgreSQL): ~512 MB RAM
  • Reverse proxy (Nginx/Caddy): ~128 MB RAM
  • Total: ~3.5 GB RAM plus OS overhead

A 4 GB VPS will run this stack, but it is tight — the OS uses 256-512 MB, leaving barely enough room for the applications. We recommend starting at 8 GB RAM for a comfortable experience with room to grow.

If managing all these services feels overwhelming, CWH Managed Support handles the setup, security patches, and ongoing maintenance — leaving your team to focus on what they do best.

How to Choose Your CWH Server

Canadian Web Hosting offers Cloud VPS plans ranging from 1 vCPU / 1 GB RAM to 12 vCPU / 32 GB RAM, all on enterprise SSD or NVMe storage in our Vancouver and Toronto data centres. Here is how to match the tiers above to actual products:

Workload Tier CWH Product Why This One
Light WordPress, single app Shared Hosting or Cloud VPS VPS1 Lowest cost, includes cPanel, free migration
Business site, 2-3 self-hosted apps Cloud VPS VPS3 (2 vCPU, 4 GB RAM) Dedicated resources, full root access, Docker-ready
Multiple apps, team of 5-10 Cloud VPS VPS5 (4 vCPU, 8 GB RAM) NVMe storage, room for database + apps
GitLab, heavy database, staging + prod Cloud VPS VPS7 (8 vCPU, 16 GB RAM) Serious RAM for database caching
GPU workloads (transcoding, AI) GPU Dedicated Server (RTX A4000+) Hardware transcoding, dedicated GPU resources
Enterprise HA, compliance Enterprise Cloud or Dedicated Server Auto-failover, isolation, compliance-ready

Once your VPS is up and running, do not skip security hardening. Our VPS Security Hardening in 30 Minutes guide covers the essential steps — firewall rules, SSH key authentication, fail2ban, and more — to protect your server from day one.

Sources, Versions, and Command Checks

This guide was refreshed in May 2026. We checked the Docker resource flags used in the examples against Docker 29.2.0 locally, and cross-checked workload requirements against official WordPress, Nextcloud, GitLab, PostgreSQL, and Docker documentation. Exact sizing still depends on plugins, traffic, database size, and background jobs, so treat the tables as starting points and verify with monitoring.

Conclusion: Start Small, Measure, Then Scale

The single biggest mistake we see is guessing too high or too low instead of starting with a reasonable estimate and adjusting based on real data. Here is our recommended approach:

  1. Start at the recommended tier for your workload from the table above.
  2. Run your application for a week with monitoring tools like htop, docker stats, or netdata.
  3. Check peak memory and CPU usage — if you are consistently under 50% utilization, drop to the minimum tier and save money. If you are hitting 85%+ at peak, bump up.
  4. Scale up (or down) — CWH VPS plans can be upgraded or downgraded with no data loss, and we handle the migration.

Not sure which tier fits your project? Our Cloud VPS plans start with flexible options, and our Managed Support team can help you choose the right size — and set it up so you do not have to.