Platform

The isolation model: one seat, one identity

The whole reason a remote Android platform exists — instead of ten emulator windows on one laptop — is separation. On CloudPhoneHub, every cloud phone is a self-contained seat: its own Android userspace, its own storage, its own device identity, and its own network exit. Seats do not share a fingerprint pool, and one customer's seats are not silently drawn from the same identity template as another's.

This matters most for multi-account work. Platforms rarely ban a single account in a vacuum — they link accounts that look like the same device, the same install, or the same network, and then act on the cluster. If five logins share host-level identity signals, one challenge can cascade into five. Per-seat isolation is what keeps each account looking like its own phone in its own pocket. It is not a ban shield — nothing is — but it removes the cheapest, most obvious linking signal that cheap density-first clouds leave lying around.

Rule of thumb we repeat everywhere on this site: one account, one seat, one proxy persona. The platform is built to make that the easy path, not the exception.

Bring your own proxy, routed per device

Network identity is half the battle, so proxy support is first-class rather than an afterthought. You attach your own proxy per seat — sticky mobile or residential — and that seat routes exclusively through it. There is no forced shared exit, no mystery pool where your account inherits the reputation of strangers who used the same IP last week.

• Per-device routing — each cloud phone gets its own exit, set before first login so the account is born on the network it will live on.
• Mobile IP preferred — when the account story is "a person on mobile data," a sticky mobile exit matches that story far better than a datacenter IP.
• Residential as fallback — high-quality residential works when mobile isn't available for the geography you need.

We deliberately do not resell a house proxy pool as a magic fix. You control network hygiene because you know your accounts' geography and risk tolerance better than any default ever could. See the Snapchat page for why this is non-negotiable on the hardest social app.

ADB and REST API: automate without breaking the fingerprint

Serious operators eventually want automation — installs, backups, scripted setup, health checks. The platform exposes ADB access and a REST API so you can drive seats programmatically, but the design goal is that automation does not flatten every seat into the same machine.

The trap with naive automation is that it makes all your devices behave identically: same cadence, same timings, same actions, same order. That uniformity is itself a fingerprint. The API is there to manage inventory and provisioning; it is not a license to run one script in lockstep across fifty warmed accounts. We steer people toward ADB and API on the higher tiers precisely because they should be reached for when your process is mature — after human warm-up, not instead of it.

Practically: use the API to stand up seats, attach proxies, and track inventory; use ADB for installs and maintenance; keep the human-looking behavior human-looking. Automation that respects the fingerprint is an advantage. Automation that ignores it is a slow ban machine.

Device identity that holds for weeks and months

A cloud phone is only useful if the account you warmed on Monday is still on the same device on the following month. Seat identity is designed to be stable across reboots and over long horizons — the device characteristics a warmed account depends on do not churn underneath you every time the seat restarts.

This is the single most underrated property when people compare hosts. A seat that quietly re-rolls its identity looks, to the app, like a brand-new device logging into an established account — which is exactly the signal that triggers verification loops. Stability is what lets an account age gracefully. The main thing that breaks it is you: factory-resetting a warmed seat without a recovery plan throws away the identity you spent days building. Treat a warmed seat like production infrastructure, not a scratch VM.

Android versions and specs by tier

Resources scale with the plan, so you buy the seat that matches the workload instead of overpaying for a test or underpowering production:

• Spark ($9) — the test seat. Enough to confirm an app installs and opens cleanly, run throwaway experiments, and validate a proxy before you commit. Shared-class resources; not where you park ten warmed accounts.
• Creator ($19) — the production social seat. Dedicated resources for daily social work, proxy-ready, sized for one real account you actually keep open and warm.
• Studio ($34) — the fleet seat. Adds room and access for root/ADB/API orchestration when your automation is real and your process is proven.

Exact Android version and per-seat specs are listed on the pricing page alongside each tier — check there rather than trusting a number quoted in a blog. The principle is simple: Spark to prove it, Creator to run it, Studio to scale it.

Always-on availability for warm sessions

Emulators run while your PC is awake. Cloud phones are meant to stay up. That difference is the whole point for social work: warm sessions, background presence, and the ability for a teammate in another city to take over a seat without your laptop being open.

Always-on availability is what makes a warmed account behave like a real person's always-on phone rather than a device that only exists during your working hours from one time zone. It is also what makes agency handoff possible — seats live in the platform, not on someone's desk. We won't quote an uptime percentage we can't stand behind, but the design intent is durable, persistent seats you can name, proxy, audit, and hand off. Explore the full model on the cloud devices page.