Important limitations

What shared hosting capacity does—and does not—isolate

Last materially reviewed 2026-09-21

Quick answerAn application boundary is not automatically an independent capacity or recovery boundary.
Likely to work well when

✓ Small WordPress teams that retain application responsibility

✓ Client portfolios needing explicit ownership and exit plans

✓ Readers comparing complete configurations rather than promotional prices

Important limitations

— A promise of unlimited custom-code support

— Readers expecting guaranteed speed or search rankings

— A stable current arrangement without a demonstrated reason to move

What to know

Verify the isolation boundary and its limits

Isolation can refer to permissions, application files, resource capacity, billing or recovery. Those are different requirements. Two applications with different domains do not automatically have independent server resources or ownership. Cloudways documents distributing applications across servers, so the arrangement should be chosen with those shared boundaries in mind. Avoid using a broad phrase such as fully isolated without specifying what operation or failure is supposed to remain contained.

What to know

Consider shared workload consequences

A fictional agency placing several clients on one server should understand that an intensive task can compete for the same resources. That does not prove shared hosting is unsuitable; it identifies a condition to measure and manage. Record the applications, normal workload and important peak activities. Capacity separation may be warranted for a busy store even when the rest of the portfolio can operate sensibly together.

What to know

Consider ownership and recovery separately

A client may need to leave without affecting other clients, and a restore may need to target only one application’s data. Verify the actual supported scope for the chosen operation. A whole-server transfer has a wider ownership consequence than a single-site migration. Similarly, application-level recovery is not evidence that every server-level change is independently reversible. Keep these distinctions visible in the decision brief before choosing a configuration.

What to know

Avoid false security guarantees

This guide is not a security audit of Cloudways or a certification that one arrangement prevents every cross-application risk. Use the current product controls, appropriate access and your own required review for sensitive workloads. Describe what has actually been verified and what remains an assumption. A clear boundary map is more useful than a reassuring label because it tells the operator which neighboring applications and owners must be considered before a change.

Source boundary

Where the safety evidence stops

This guide draws on Cloudways distributing sites across servers, Cloudways collaboration and separate application credentials. Merchant-controlled records describe the provider’s own capabilities, terms or standards; they do not independently validate those claims. These records do not establish independent confirmation of the product claims.

Verify any current price, plan limit, label direction, compatibility rule, or commercial term that would materially change the decision. The dated source ledger shows the underlying records so this conclusion can be checked and updated.

Sources used for this page

These records support the facts and comparisons above. Merchant-controlled records are labelled so you can separate product claims from independent evidence.

  1. Cloudways distributing sites across servers — Merchant documentation · support.cloudways.com · Merchant-controlled · checked 2026-09-21
  2. Cloudways collaboration and separate application credentials — Merchant documentation · support.cloudways.com · Merchant-controlled · checked 2026-09-21