How Many Websites Can You Host on a Single VPS?

There is no universal number of websites that one VPS can host. Ten brochure sites, ten uncached stores, and ten sites with import jobs are three different workloads. The defensible answer comes from measuring the actual portfolio, reserving operating headroom, and admitting another site only when the combined system still passes its service and recovery targets.

This guide is for freelancers, agencies, and technical teams deciding whether to consolidate several websites on one self-managed VPS or split them across multiple instances.

Start with the service target, not a site count

Define what the shared server must deliver before measuring capacity. Record:

• the pages, APIs, checkouts, admin actions, and scheduled jobs that must work
• expected normal and peak concurrency by site
• response-time and error-rate limits for each critical path
• acceptable interruption and data-loss windows
• maintenance, deployment, backup, and restore windows
• the effect of one compromised, overloaded, or broken site on the others

A server is full when adding another site would break one of those requirements. It may reach that point because of CPU, memory, storage latency, database load, worker concurrency, disk growth, network behavior, recovery time, or operational risk. A raw site total cannot reveal which boundary will fail first.

Measure each website and the shared stack

Collect evidence during a representative busy period. Include ordinary traffic, cache misses, authenticated sessions, checkout or form submissions, scheduled tasks, imports, backups, deployments, and administrative work.

Measure the shared operating system, web server, database, monitoring, security tooling, control panel if used, and backup process separately. Those components consume resources even when no website is receiving traffic.

Do not estimate a dynamic site's demand from its idle memory or homepage alone. A cached public page can look inexpensive while an uncached search, checkout, import, or backup becomes the limiting path.

Build a capacity model from measured websites

Create a resource budget for the candidate VPS:

1. Start with the documented CPU and RAM allocation.
2. Subtract the measured baseline for the operating system and shared services.
3. Reserve explicit headroom for traffic variance, deployments, monitoring, backups, and incident diagnosis.
4. Add the measured simultaneous demand from the current websites. Do not add unrelated per-site peaks if they cannot occur together; do not average away correlated peaks when campaigns, cron schedules, or client behavior can align them.
5. Replay representative traffic and background work on the complete stack.
6. Reject the model if any service target, recovery target, or resource-headroom rule fails.

For a rough screening calculation, estimate a separate maximum from CPU, memory, storage, database connections, and worker concurrency, then take the lowest result. That minimum is only a test candidate. Production admission still depends on a combined load and recovery test because sites share caches, databases, queues, and failure conditions.

Review the model after material traffic, plugin, theme, runtime, database, client, or deployment changes. Capacity is a current operating property, not a permanent characteristic of a plan.

Hypothetical worked example

The following example demonstrates the method; it is not a Virtarix plan promise or customer deployment result.

Assume an agency measures eight existing sites together during their representative peak. The stack records 1.8 CPU cores of sustained demand, 3.4 GB of peak memory, 22 GB of used storage, 3 GB of monthly storage growth, and a 24-minute tested restore. The agency's written limits require CPU below its chosen sustained-use ceiling, at least 25% memory headroom, six months of forecast storage below its free-space ceiling, and a restore completed and validated within 45 minutes.

A proposed ninth site is replayed on a clone of the full stack. During the combined test it adds 0.35 CPU core of sustained demand, 0.55 GB of peak memory, 4 GB of initial storage, 0.5 GB of monthly growth, and four minutes to the restore exercise.

The decision is made from the new combined measurements, not from nine sites as a category:

If one test fails, the team can tune the workload, change its architecture, choose a different allocation, or isolate sites. It cannot turn a failed measurement into a safe deployment by citing a generic sites-per-plan range.

Website design changes the result

Cache behavior and dynamic paths

Full-page caching may reduce repeated application and database work for eligible public pages. It does not remove uncached logins, carts, checkouts, searches, APIs, administrative actions, cache warmups, or invalidation. Test the dynamic paths that matter instead of treating a cache or CDN label as proof of capacity.

Database and background work

Poor queries, large working sets, locks, imports, search indexing, queue workers, and overlapping scheduled jobs can constrain a server before average page traffic does. Separate database users can improve access boundaries, but they do not create CPU, memory, or storage capacity.

Tenant isolation and blast radius

Sites on one VPS share an operating system and failure domain. Apply per-site credentials, file permissions, process or container limits where appropriate, database privileges, deployment access, logs, and monitoring. Decide whether one client's security incident, traffic surge, faulty release, or unpaid account is allowed to affect every other site.

Isolation controls can reduce interference and investigation scope, but they do not make one VPS equivalent to independent failure domains.

Current Virtarix CPU and RAM allocations

The table contains only Cloud VPS CPU and RAM facts from the frozen Virtarix Source of Truth checked on 11 August 2026. It does not assign a website count or represent real-world customer deployments. Storage, software, traffic shape, database behavior, recovery, and the customer's operating model still need separate evaluation.

Virtarix provides self-managed VPS infrastructure. The customer installs, configures, secures, updates, monitors, and operates the websites and their software. Listed CPU cores and RAM describe allocation; they do not guarantee a site total, application response time, database throughput, or recovery result.

A larger single VPS is not high availability

High availability requires redundant failure domains and a tested way to continue or recover service when one domain fails. Depending on the workload, that may require multiple application instances, replicated data, separate storage or database design, health checks, traffic routing, dependency redundancy, and an exercised failover and failback procedure.

Buying a larger single VPS can provide more allocation, but the workload still has one guest instance and one consolidation blast radius. Capacity and high availability are separate design decisions.

Test before consolidating websites

Use a staging copy or an otherwise controlled environment and keep a rollback path.

1. Inventory every site, runtime, database, scheduled job, external dependency, domain, certificate, access owner, and recovery requirement.
2. Capture baseline traffic, resource, application, database, storage-growth, backup, and restore measurements.
3. Define pass thresholds and explicit headroom before choosing a candidate allocation.
4. Build the complete shared stack with the intended security and tenant boundaries.
5. Replay representative traffic, authenticated actions, scheduled work, deployments, backups, and monitoring together.
6. Introduce a heavy site, failed process, full queue, bad deployment, and restore exercise to observe the shared blast radius.
7. Consolidate in stages, compare production measurements with the model, and stop when the next admission would breach a threshold.

How many websites can one VPS host?

One VPS can host the number of measured websites that simultaneously meet the team's performance, headroom, isolation, maintenance, and recovery requirements on that exact stack. The number may change when a site, traffic pattern, database, plugin, job schedule, or operating target changes.

Use plan allocation to select a test environment, not to publish a universal site-count promise. If the combined workload passes, retain the evidence and review date. If it fails, reduce demand, increase tested capacity, split the portfolio, or design additional failure domains according to the failed requirement.

Source

• Virtarix frozen Source of Truth, version 2.2, effective 16 July 2026 and frozen for this remediation on 11 August 2026: Cloud VPS CPU/RAM allocations and self-managed responsibility boundary.