One VPS for multiple client websites: when it works and where risk accumulates

“How many websites fit on one VPS?” sounds like a capacity question. It is also a security, continuity, maintenance and client-boundary question.

Several quiet brochure sites may use fewer resources than one busy shop. Yet even light sites can create a large shared impact if one compromised plugin, failed update or full disk affects every client at once. This comparison is illustrative, not a measured site count or capacity result.

There is no credible universal safe-site count. Decide from the workloads and the boundary you are creating.

Why agencies consolidate

A shared VPS can offer practical benefits:

• one operating environment to maintain;
• consistent deployment and monitoring;
• pooled capacity rather than stranded resources per small site;
• potentially fewer supplier accounts and invoices;
• a repeatable application stack;
• easier central visibility for an agency team.

Those benefits are real only if the agency can operate the shared environment competently. Consolidation reduces the number of platforms while increasing the consequence of each platform decision.

Risk 1: resource contention

Sites on one VPS share finite compute, memory, storage throughput, network capacity and often database or web-server workers. A traffic spike, runaway process, backup job or expensive query from one site can degrade the others.

Assess each workload using evidence:

• request and transaction volume;
• peak and seasonal patterns;
• CPU and memory behaviour;
• database load;
• storage use and growth;
• disk latency and throughput;
• background jobs;
• cache effectiveness;
• external-service delays;
• deployment and backup windows.

Average CPU alone is not enough. A short memory spike, exhausted worker pool or slow shared database can harm response time while the monthly average looks comfortable.

Use per-site or per-process observability where the stack permits it. If the team cannot identify which site consumes the shared resource, it will struggle to manage contention or allocate cost fairly.

Risk 2: one larger failure domain

A VPS outage can affect every site on it. So can:

• a failed operating-system update;
• a damaged shared database service;
• storage exhaustion;
• a mistaken firewall or web-server change;
• loss of the primary administrative route;
• a backup or restore process that cannot separate sites;
• compromise of a shared privileged account.

Ask how many clients, revenue journeys and support conversations the agency can handle in one incident. The answer may set a lower consolidation limit than CPU or RAM.

Fault domains are not removed by a backup. Recovery capacity, restore order and client communication must cover the full shared impact.

Risk 3: weak separation between sites

Separation can exist at several layers:

• application users and roles;
• file ownership and permissions;
• database users and schemas;
• runtime process pools;
• containers or operating-system accounts;
• network paths;
• secret stores;
• backup and log access;
• separate virtual machines or accounts.

These controls are not interchangeable. NCSC guidance says buyers should understand compute, storage and network security boundaries and warns that kernel- or application-enforced separation can have a larger attack surface than hardware-backed virtualisation for workloads running custom code.

For agency-managed sites with a common trusted operator, some controls may be intended mainly for functional separation. Do not market them as equivalent to a separate VPS or provider tenant. If client terms, threat model or data sensitivity require stronger separation, use the boundary that actually provides it.

Risk 4: maintenance becomes a portfolio event

A shared runtime can make routine work efficient, but it also couples change:

• one PHP or database version may not suit every application;
• a security update may require all sites to be tested together;
• one legacy plugin may block stack modernisation;
• a restart or maintenance window affects several clients;
• rollback may need to preserve different data-change patterns.

Record compatibility before grouping sites. Sites that need conflicting versions or maintenance windows are signalling that they do not belong in the same operational cohort.

Risk 5: backup and recovery become harder to reason about

Check whether you can:

• create a consistent recovery point for one site;
• restore one database without overwriting another;
• recover shared services in the correct order;
• validate each client's application and data;
• retain evidence per client;
• meet different retention or deletion decisions;
• restore the entire VPS within the combined business need.

A full-machine snapshot may be useful for one failure type while being too coarse for a single-site mistake. Per-site exports may support granular recovery while omitting shared configuration. A sound design can use more than one recovery method, each with an explicit purpose.

Risk 6: client terms and data boundaries may differ

Clients may have different requirements for:

• data categories and sensitivity;
• processing and support locations;
• subprocessors;
• retention and deletion;
• maintenance notice;
• recovery objectives;
• audit evidence;
• licence ownership;
• exit and export format.

Do not put sites together merely because their technology matches. First confirm that the shared operating and supplier model is compatible with the applicable client agreements and risk decisions.

Risk 7: exit becomes a dependency graph

Moving one client away should not require exposing another client's data or dismantling the entire platform.

For each site, keep:

• its files and database identifiable;
• configuration and dependencies documented;
• licences attributable;
• domain and DNS authority separate;
• secrets scoped and rotatable;
• logs and backups separable where required;
• an export and validation route;
• a record of shared components that must be replaced at exit.

Test a representative single-site export. If the agency can only move the portfolio as one block, consolidation has created a commercial and operational lock-in of its own.

Build a site-cohort decision matrix

Score or describe each site against the same factors:

The table supports a decision; it does not calculate a magic site count.

Operate a shared VPS as a capacity and risk budget

Define:

• which sites are admitted to the cohort;
• minimum headroom and review triggers based on observed metrics;
• per-site resource or process limits where supported;
• maintenance and client-notice rules;
• backup and restore methods;
• monitoring and alert ownership;
• incident triage and client communication;
• criteria for moving a site to a separate environment.

Review after onboarding a site, after a major release and when workload patterns change. Spare capacity today is not permanent permission to keep adding sites.

When a separate VPS is the clearer choice

Separate treatment may be justified when a site has:

• materially different trust or data requirements;
• high or unpredictable resource demand;
• incompatible runtime dependencies;
• a critical business journey with a distinct recovery objective;
• client-controlled administration that should not reach other sites;
• a change or maintenance calendar that conflicts with the cohort;
• a contract requiring a clearer technical boundary;
• exit requirements that cannot be met cleanly in the shared design.

The decision is not that a VPS is inherently secure or resilient. It creates a different boundary that still needs maintenance, monitoring, backup and recovery.

How this relates to Novasean

Novasean's current Managed VPS page lists VM Start, Grow and Scale with Managed OS included in the displayed monthly catalogue amounts of €78, €98 and €138 respectively, before applicable VAT. These are existing plan comparisons, not a multi-site price or capacity statement. New VPS orders are temporarily paused; applicable scope, terms, availability and final charges must be confirmed before any new order.

The page does not state a safe number of websites per VPS, promise per-site isolation or establish delivery capacity for a portfolio. The separate one-to-five-site agency portfolio enquiry is non-binding and is not a VPS plan or accepted service commitment. A portfolio arrangement would need workload inventory, boundary and responsibility decisions, measured capacity, recovery design and separately accepted scope. Managed infrastructure would not silently transfer application, content, plugin, licence or client-communication responsibility from the agency.

Sources

• NCSC: Principle 3 — separation between customers — official guidance on compute, storage, network and management-plane boundaries.
• NCSC: technically enforced separation in the cloud — official explanation of different separation mechanisms and their limitations.
• Microsoft Azure Well-Architected Framework: virtual machines — official vendor guidance on workload metrics, pilots, dependencies and capacity planning; used as an example, not a Novasean platform statement.
• Novasean: Managed VPS and responsibilities — live availability and proposed responsibility wording inspected on 2 October 2026.

Next: Review the current Managed VPS scope and availability.