On some platforms the actions that matter exist only in the app and can't be done in a browser. A cloud phone is an Android device running in the cloud: install the app, bind the account, and digital workers act on the device itself while you watch the screen and the logs from the console.
Twenty handsets on the desk, charging cables in a knot, and they still keep dropping off
Devices run in the cloud, so hardware, power and network aren't yours to maintain. A device that drops or freezes can be restarted from the console instead of unplugged in person.
Every phone gets the app installed by hand, and then I log in on each one separately
Upload the APK once and push the install to a whole group. Progress is visible in the console, and devices that failed are listed separately to retry.
Someone left and nobody can say who's using the devices and accounts they had
Assignments are on the record: which device went to which member, and which account it holds. A handover means changing the assignment, not reinstalling and logging in again.
Platforms like WhatsApp and Line can't be worked fully from a browser
Anything that needs the app goes through a cloud phone; the rest goes through a browser environment. One set of accounts can use both.
Devices have to be operable in bulk, drivable by code, and traceable to whoever is using them. Those three decide whether you still have control once the count climbs.
Every cloud phone in one list, with online, offline and running status shown live. Filter by status to find the ones misbehaving.
Group devices by project, platform or owner. Installs, starts and parameter changes can all be run across a group at once.
Open the device screen in your browser and operate it directly, with no local client to install. Used for first logins, codes and manual checks.
Keep the installers for the apps you use, with a record of what's installed on each device and at which version. Uninstall or install over the top.
Upload an APK and push it by group, covering the whole group in one pass. Results are visible per device, and failures can be retried on their own.
Devices are assigned to members or accounts, which makes ownership explicit. Assignment changes go to the audit log, so a handover doesn't lose the thread.
Devices hold a persistent MQTT connection to the platform, with commands out and status back on the same channel — convenient for hooking into your own scheduler.
A digital worker's actions reach the device as tasks, subtask results are kept entry by entry, and failure reasons are searchable by device or by date.
A device is only the host; the work is done by digital workers. Two steps in the middle are yours: which device an account goes on, and the first login itself.
Provision as many cloud phones as you need and group them by project or platform. Installs and configuration can be done across a group together.
Upload the target platform's APK and push it to the whole group. Progress and any failed devices are visible in the console.
Which account lands on which device, over which exit route, is fixed once you confirm it. After that, devices shouldn't be swapped often.
Open the device screen, sign in to the app, and handle the SMS code and 2FA — the steps only you can do. From then on the device holds the session.
Warming, customer conversations and publishing are dispatched to the matching device. A device behaving oddly stops and is flagged for you to look at.
Which device an account lives on isn't something to decide automatically. A device is part of an account's long-term identity, and moving it around amounts to logging in from a new handset — a signal platforms notice on its own. First login is the same: the code goes to your number, the credentials are yours, and the platform doesn't hold them for you.
Exact models, OS versions and available regions come from the resource pool at provisioning time. Only what's settled is written here.
Anything doable on the web goes through a browser environment, which costs less. Only the actions that exist solely in the app need a cloud phone — schedule both together.
A device's exit IP comes from the proxy network, configured to the account's target region, and you can check the current exit at any time.
Conversations on messaging platforms like WhatsApp and Line happen on the cloud phone, with both AI replies and the handoff to a human on the same device.
For platforms that need a handset, warming runs on the cloud phone, with the same action scores and logs as a browser environment.
Technically yes, within limits. When several accounts from the same platform share a device, what the platform sees is repeated login switching on one handset, and that is itself a linkage signal — the more an account matters, the less we'd advise it. Accounts from different platforms sharing a device usually matters less. The system doesn't force a one-to-one ratio, billing follows the devices actually in use, and how you allocate them is your call based on what your accounts are worth and how much risk you'll carry.
We can't promise they can't. A cloud phone is an Android environment running on a server, it differs from physical hardware, and a platform that specifically looks for virtualisation traits may well find them. What can be done is keeping device parameters, exit routes and pacing consistent and sensible, and avoiding actions that clearly depart from ordinary use. Any tool that promises to be "undetectable" isn't worth believing.
Its status turns offline in the device list, and the related tasks stop with their failure reason recorded. You can restart the device from the console. A restart usually leaves installed apps and sessions intact, though the platform may ask for verification again depending on its own policy.
You can install by uploading an APK. The installer is yours to supply; we don't obtain, crack or modify apps for you. Some apps that hard-require Google services, particular hardware or a security chip may not run properly, so test on one device before provisioning a batch.
App data stays in the device's local storage. What the platform keeps is task records, audit logs and the contact profiles you export. Export anything you need to keep before releasing a device — once released, its storage is not retained.
Assign devices to members through assignment management and use member permissions to control what each person sees. Remote control, installs and assignment changes all go to the audit log. Turn on 2FA for admin accounts.
A consultant will put together a device configuration and resource quote around your target platforms, account count and regions.