Drive a phone farm
Rack real Android phones and iPhones on one Mac, pair the host once, and run the whole fleet from a plain-language prompt to BusyBro or an MCP client — screenshots, taps, sign-ins, automations — with a confirm gate on every action that changes something.
A phone farm used to mean a room of devices and a person walking between them. Busymate's farm is a host daemon on a Mac with a powered USB hub: it discovers every plugged-in phone, mirrors each screen into your browser, exposes every action as a tool, and pairs itself as a device in your dashboard so the fleet shows up next to your own phone with live health. Because every action is a tool, an AI assistant can run one phone or the whole rack from a sentence.
This guide goes from an empty hub to that sentence. It is honest about the boundaries: raw power actions — shell, arbitrary input, app installs from outside the store, network toggles, reboots — are admin-only, always ask for confirmation, and are kept away from the free-text assistant entirely. The prompt drives the safe, curated surface, which is most of what a test run needs.
What you
Hardware you can plug in, one Mac to host it, and a Busymate account to own it.
A Mac as the host, plus a powered USB hub and data cables — not charge-only cables.
Android phones with USB debugging enabled, and iPhones with Developer Mode on — the only on-device taps the platforms require.
A Busymate account with device edit access; the host and every phone it provisions belong to that owner.
BusyBro in the dashboard, or Claude Code connected over MCP — the previous guide — as the thing you type the prompt into.
Do it
Rack, install, watch the fleet appear, onboard it, then hand it to the agent.
- 01
Rack the phones
Connect the phones to the Mac through the powered hub. On each Android phone, turn on USB debugging and tap Allow USB debugging when the host asks; that is all the configuration an Android phone needs. On each iPhone, enable Developer Mode and Trust the host when prompted — the two one-time taps Apple requires. Everything else on the iOS side is provisioned by the daemon.
- 02
Install the daemon, sign in, start it
One line installs the farm host. Sign in once in the browser so the host can pair — the daemon refuses to start unsigned, so a farm never runs without an owner by accident — then start it with autostart so it relaunches at login and reboot. The status command shows the running build, how many phones are online, and whether the host is paired.
The host pairs itself as a Busymate device with a long-lived credential kept on disk, so it never needs your session again. Each phone becomes a child device under it with a stable identity that survives a USB reconnect, inheriting your ownership.
Install, pair, start, check bashcurl -fsSL https://farm.busymate.net/install.sh | bash # macOS / Linux bmfarm login # sign in once in the browser so the host can pair bmfarm start --autostart # start the background daemon; relaunches at login bmfarm status # running build, phones online / total, pairing state - 03
Watch the fleet appear in the dashboard
Open the Phone Farm view in the dashboard. Its sidebar has a Daemon entry — the farm-level pane with a control panel per machine and a live log tail streamed up from the host — and one entry per farm machine, opening that Mac's Android and iOS phones. Each phone shows model, OS version, battery and state, and a live mirror: the screen is streamed as video and hardware-decoded in your browser, and your taps, swipes and keystrokes round-trip to the physical device. Recovery after a daemon restart is heartbeat-driven, so there is nothing to refresh.
- 04
Onboard every phone with one action
Each phone needs a few components kept current — the on-device control runner, the certificate trust, the Busymate DevTools app for capture, and so on. Rather than walking the rack, the host card's Onboard all phones action runs the fleet walk for you, with per-phone isolation so one failing install can never abort the sweep. The dashboard renders a live grid of phones by components; a cell only turns green once the daemon confirms the installed version, an already-current component is a muted skip, and anything that needs a human — an Apple ID prompt, a paid app — is flagged rather than faked.
- 05
Connect the agent
Two doors lead to the same tools. BusyBro is built into the dashboard and the standalone BusyBro app, already signed in as you. Claude Code — or any MCP client — connects to the same server with one command and a browser sign-in, covered in the previous guide. Either way the assistant acts as you: every farm tool is scoped to your own farm devices, gated on the host's remote-control opt-in, and checked against your role's capabilities.
- 06
Write the one prompt
Say what you want done across the fleet, in plain language. The assistant lists the online phones, screenshots each, opens the app, finds and taps the elements it needs by reading the screen's UI hierarchy, types the sign-in, and reports back per phone. Variables you set in the farm console — a test account, a coupon code — are available to automations by name, so the prompt never has to contain a password.
Anything that changes a phone shows you a confirm card first — with the full payload of what is about to run — and waits. A screenshot or a UI dump needs no confirmation; a tap, an install from the public store, or an automation run does. Raw shell, raw ADB, arbitrary input, proxy and airplane toggles and reboots are admin-only power actions the free-text assistant cannot reach at all; they stay in the dashboard and the MCP tools behind an explicit confirm.
One prompt, the whole rack textOn every online farm phone: take a screenshot, open the checkout app, sign in with the test-account variables, and tell me which phones show the new "Pay in 3" button. Flag any phone whose screen is black. - 07
Make it repeat, and capture what the phones send
Automations are plain JavaScript files on the host with a device API — install, launch, find-and-tap, type, screenshot — and a scheduler that runs them on an interval. Ask the assistant to schedule one and it becomes an overnight job with per-device results. Traffic from farm phones routes through the shared proxy into the same feed as your own phone, so a run's network activity is inspectable, mockable and exportable like any other capture; Android farm phones run at the rooted tier where the certificate sits in the system store, which decrypts everything short of an app that pins.
Fleet health is a tool too: ask which phones need attention, and the assistant reads the same heartbeat the dashboard shows and can trigger the self-heal sweep — again behind a confirm.
Turn the run into a nightly job textRun the login-smoke automation on all Android farm phones every night at 02:00 and message me only if a phone fails.
What can
Farm problems are almost always a cable, a tap on the phone, or a gate doing its job.
A phone never appears in the fleet
Nine times out of ten it is a charge-only cable or an unanswered Allow USB debugging prompt on Android. Swap the cable, unlock the phone, and accept the prompt. On iOS, confirm Developer Mode is on and the host is trusted.
The daemon refuses to start
It fails fast until the host has an owner. Run the login command, sign in, then start it again — the status command confirms the pairing.
The mirror tile is black
The phone is locked, the screen is off, or the control runner is not armed yet. Wake the phone; if it stays black, run the onboard action for that phone so its components are re-checked with real evidence.
The assistant says it cannot run a shell command
Correct and intentional: raw shell, raw ADB and the other power actions are admin-only and off-limits to the free-text assistant. Use the dashboard console or the MCP tool directly, where the explicit confirm gate applies.
An action was denied for a phone I can see
Farm actions are limited to your own farm devices and need the host's remote-control opt-in plus device edit access on your role. Check the host's opt-in in its settings and your role's capabilities.
Questions
Is this cloud phones or emulators?
Neither. They are physical phones on a hub plugged into a machine you control. You can also rent a managed fleet instead of racking your own — the pricing page covers that.
Can the assistant really break a phone?
The destructive surface is admin-only, confirm-gated, and withheld from free-text prompting. What the prompt can do — screenshots, taps, app launches, store installs, automations — always previews the exact action before it runs.
Does traffic capture work on the farm phones?
Yes. Farm phones route through the shared proxy into the same dashboard feed as every other device, and rooted Android farm phones decrypt system-wide short of certificate pinning.
A rack of real phones,
Plug them in, pair the host, and let the assistant run the fleet — with you approving every change.