Capacity planning guide
How many cloud phones do you actually need?
A practical guide from CloudPhoneBase, the service provider.
The short answer
Count the highest number of recurring projects that need separate app, sign-in, or browser context at the same time. Choose the smallest plan that covers that number.
Capacity planning prevents two opposite problems: forcing unrelated work into one confusing Android context, and paying for environments that have no defined job. Start with present, recurring work. A future project belongs in the forecast, but it should not increase today's count until it has a real workflow and a reason to preserve state.
The calculation answers the capacity question. A short pre-purchase checklist can capture the other requirements that matter to the workflow, such as its essential apps and any specific configuration, region, performance level, or access pattern.
Check the number against the work it represents
A capacity result should point back to projects with stable purposes. Compare the total with one-, three-, and 25-device examples, then use the multiple-project boundary guide to challenge any row based only on an app, account, person, or speculative future task.
Count persistent environments, not raw activity
Use one counting unit: a recurring body of work that needs its own recognisable combination of apps, sign-ins, and browser state. The number of apps is not the number of cloud phones.
The number of people is not automatically the device count either. Increase capacity only when their work genuinely requires separate persistent environments. If several people need the same environment, confirm the available access method before using headcount in the calculation.
| Input | Increase the count when | Keep the current count when |
|---|---|---|
| Project | It recurs and needs retained, distinct Android context. | It appears once on a future ideas list. |
| App | The app belongs to a separate project context that cannot be combined clearly. | Another app is installed for the same project. |
| Account | The workflow needs a distinct persistent sign-in and recovery path. | The app offers a clear account switcher for the intended workflow. |
| Person | A separately assigned environment is operationally required. | Another teammate occasionally reviews the work. |
| Temporary task | It becomes recurring and needs retained state. | It can be completed and closed without retaining state. |
Complete a six-question capacity worksheet
List every candidate environment in a worksheet and answer the same questions. A row counts only when the need is current, recurring, and distinct. Turn any uncertain answer into a pre-purchase question rather than adding capacity by default.
Your device count is the highest number of qualifying project spaces that need to remain distinct during the same operating period.
- What single outcome does this environment support?
- Which apps and browser steps are essential to that outcome?
- Which intended identity and recovery owner apply?
- Must the context persist between sessions?
- Would combining it with another row create a realistic sign-in or state error?
- Is it active now, or is it only forecast work?
Apply the method to three worked examples
Example one is a solo project lead with one weekly app-led project and several supporting web pages. The requirement is one cloud phone even though the workflow uses more than one app or website.
Example two has three recurring jobs with different purposes. Peak demand is three cloud phones, which fits the Plus plan.
Example three has four qualifying projects. The next available capacity is the 25-device Workspace plan, so challenge the fourth row before ordering.
Map the result to the current plans
Essential covers one cloud phone, Plus up to three, and Workspace up to 25. Match the plan to the highest number of project spaces that need to stay separate at the same time.
Capacity is only one buying criterion. Check the essential app path and any project-specific configuration or region requirement. Activation is handled manually, so confirm availability and expected timing before payment.
| Plan | Cloud phones | Monthly total | Per device |
|---|---|---|---|
| Essential | 1 | $9.99 | $9.99 (rounded) |
| Plus | 3 | $26.99 | $9.00 (rounded) |
| Workspace | 25 | $63.99 | $2.56 (rounded) |
Recount capacity on a fixed review cycle
Revisit the worksheet monthly or when a project starts, ends, or changes its account and app path. A cloud phone with no current purpose is a signal to review capacity rather than fill it with unrelated work. Before reassigning it, complete the app sign-outs and ask support for the correct reset path.
Track three simple states in an external inventory: active, under review, and ready for reassignment. Also record the last date the exact app workflow was checked. App availability and requirements can change, so rerun a representative task after a material app update.
- Increase the device count when a new recurring project has a justified separation need.
- Review the device count when a project has been inactive for a full operating cycle.
- Recheck compatibility after a material app or workflow change.
- Complete the sign-out and agreed reset path before assigning a device to a new project.
Common questions
Do I need one cloud phone per app?
No. Count project spaces, not app icons. One cloud phone can hold several compatible apps for the same outcome.
Do I need one cloud phone per account?
Not automatically. Some apps support multiple accounts or switching, while others use different sign-in flows. Add an environment when a distinct account context must persist and combining it would create a real operational error.
What if I need four cloud phones?
CloudPhoneBase plans cover one, three, or 25 devices, so four separate project spaces map to the 25-device Workspace plan. Recheck the fourth project before buying.
Should I buy spare devices for future projects?
Forecast them, but base a purchase on justified current demand. Give every cloud phone a clear project purpose instead of buying unused capacity by default.
Sources and further reading
- Google Account Help: sign in to multiple accounts at once
Google documents that multiple accounts can coexist in supported services and that default-account settings can sometimes apply, supporting a context-based count instead of an automatic one-account-per-device rule.
- Android Open Source Project: support multiple users
Android documents distinct app data and workspaces in its multi-user architecture, providing useful background on persistent context boundaries.
- Google Play Help: install apps on another device
Google Play shows compatibility by target device, supporting the guide's app-by-app workflow check.