Phone-farm equipment: devices, USB hubs, power, cooling and control

A physical phone farm needs more than a box of inexpensive phones. Each handset must remain powered, connected, controllable and compatible with the app you intend to use. The useful unit of capacity is a phone that can complete its task reliably, not a phone that turns on once during setup.

This guide explains the equipment and engineering decisions behind a local fleet. If you use PhoneFarm’s hosted cloud-phone workflow, you do not need to assemble a local rack to get started. Begin with create your first phone; use this article to understand the infrastructure work a hosted service takes off your desk and what to consider for a physical-device operation.

Start with a representative workload

Choose one real task before choosing a model. Will the phone play and upload video, interact with a camera, run a private test build, or remain signed into a brand’s app? Does the task need Android or iOS? How much media must stay on the device? Can a remote operator recover from a permission dialog?

A handset that opens the home screen smoothly may still perform poorly while uploading a large file and streaming its screen. Test that combination. Run the intended app, prepare the actual media format, complete the task and repeat after an ordinary disconnect or restart. Observe the port, battery, storage, app version and control connection as well as the screen.

Choose devices for service life and repeatability

For a production-oriented fleet, a small set of known compatible models simplifies spare parts, setup instructions and troubleshooting. For compatibility testing, varied devices are useful because detecting differences is the purpose. These are different purchase strategies.

Refurbished devices can reduce the purchase cost, but the useful comparison is cost over their remaining service life. Check current app and OS compatibility before buying a batch. For used devices, verify that you can legitimately activate and configure the handset and that it is released from previous ownership or management restrictions.

Understand charging hubs versus data hubs

A charging connection supplies power. A data connection also carries communication between a host and the phone. A charging-only cable or hub can keep a handset’s battery full while leaving it invisible to the control computer.

Read the specifications for the exact hub: supported data mode, simultaneous ports, total power budget, per-port delivery and the supplied power adapter. The number of sockets alone does not establish that every port can power a phone under your workload while transferring data.

Read watts, volts and amps as different units. Power in watts equals voltage multiplied by current in amps. In a simplified example, a 60 W output at 5 V corresponds to 12 A total. Dividing that evenly among ten ports would mean 1.2 A and 6 W per port before losses. It does not mean that a particular ten-port hub actually delivers those values: negotiated modes, per-port limits and simultaneous-output ratings determine the real behavior. Use the device and hub specifications together, then observe the representative workload.

Label cables and ports so a failure can be traced. If Phone 7 disconnects repeatedly, move one known-good cable to that phone and observe the result before changing the whole rack. If the fault follows the cable, replace the cable. If several phones on one hub fail together, investigate the shared hub or host connection before treating them as separate device failures.

Avoid designing around a daisy-chain of unspecified adapters. The objective is a serviceable arrangement whose components have known ratings and can be isolated when something fails.

Budget power using the complete setup

Plan for phones, hubs, host computers and networking equipment together. Use manufacturer ratings to select the equipment, and measure the real workload to understand ongoing consumption. A low average reading is not permission to exceed any component’s rated capacity during charging or peak activity.

For illustration, suppose ten phones average 6 watts each during an observed workload and the host/network equipment averages another 40 watts. The measured total is 100 watts. At continuous use for 30 days, that is 0.1 kW × 24 × 30 = 72 kWh. At a hypothetical electricity rate of $0.20 per kWh, the energy component would be $14.40. This example is operating-cost arithmetic, not electrical sizing advice or a PhoneFarm price.

The larger cost can be the operator time lost to unstable power. If devices disconnect mid-task, the team may spend more on diagnosis and retries than it saves by using cheaper charging equipment. Keep energy, hardware and labor as separate lines in the budget.

Make cooling and physical access part of the rack

Leave space for airflow and for removing one phone without disturbing the rest. Label the handset, its cable and its position with the same device identifier. Keep screens and ports accessible enough to inspect a stuck prompt or damaged connector.

Continuous media work and charging create heat. Apple documents a 0–35°C ambient operating range for iPhone and iPad and notes that temperature management can slow charging or reduce performance. Follow the manufacturer guidance for the actual device; room temperature alone may not represent the hotter pocket around a densely packed rack. Apple temperature guidance.

Treat repeated temperature warnings as an infrastructure problem to resolve, not a prompt to bypass. Stop using a visibly damaged or swollen battery and follow the manufacturer’s service guidance. A rack layout that makes inspection difficult also makes small hardware problems harder to catch.

The host and control layer

The host is the computer or service coordinating device access. It needs the appropriate operating system, control tools, connectivity and resources for the number of concurrent sessions you intend to run. One screen stream may work comfortably while twenty streams saturate a link or burden the host.

Android’s ADB documentation describes device communication through a client, server and device-side daemon, with explicit device selection when several targets are connected. The lesson for an operator is broader than a command: a fleet control system must identify the intended device reliably. A script that sends an action to whichever phone happens to respond first is unsuitable for account-specific work.

For an iOS build, confirm the chosen tool’s host, signing and device requirements before purchasing hardware. Do not assume that an Android rack design transfers unchanged to iPhones. If you use hosted PhoneFarm access, the customer-facing path is its browser-based phone controls; the setup guide does not require you to build a local control host.

Networking is another shared component

Check both the local connection and the phone’s app traffic. Several simultaneous video uploads can compete for the same uplink. A separate proxy assignment does not automatically add capacity to an overloaded physical network.

For a hypothetical batch of twenty 50 MB uploads, the media alone totals about 1 GB. A link sustaining 10 megabits per second would need roughly 800 seconds to carry that data under idealized conditions, before protocol overhead and competing traffic. Staggering work may be more useful than adding phones to the same constrained link.

See proxies and networking for the difference between device access, outbound routes and observed location.

SIM, eSIM or Wi-Fi-only operation?

A SIM identifies a mobile subscription for cellular service. A physical SIM is a removable card; an eSIM provisions the subscription digitally on a compatible device. Neither is the same thing as an app account or a proxy subscription. Apple's eSIM explanation describes the digital-SIM model; device and carrier support still need checking.

Choose the connection from the workload. A fixed rack may use Wi-Fi for its internet connection. A cellular plan may be relevant when you need actual carrier connectivity, a supported phone-number service or a mobile-network test. Confirm whether a particular plan includes data, calls and SMS; do not assume a data-only plan supplies a recovery number.

For example, a brand may publish through Wi-Fi while the account owner's recovery number remains on a separately controlled business line. The data route and recovery contact solve different problems. Record both responsibilities so replacing a publishing phone does not accidentally remove the team's recovery path.

For hosted PhoneFarm access, follow the connection options actually provided by the service. The documented BYO flow takes proxy connection details; it does not imply that you can insert a physical SIM or provision your own eSIM on the hosted phone. PhoneFarm does not supply a dedicated IP address.

Apple Account, App Store access and app login are separate

For an owned iPhone fleet, distinguish the Apple Account used by the device, the identity used for Media & Purchases, and the account used inside TikTok or another app. Apple's purchase-device association list is itself different from the list of devices currently signed in to an Apple Account. See Apple's device-association explanation.

Sign in with Apple is an authentication choice offered by participating third-party apps. It lets an app create or access its own account using your Apple Account; it does not make the app account identical to the device or App Store account. Hide My Email may provide a relay address, so record the actual login method and keep its recovery dependency usable. See Apple's Sign in with Apple explanation.

A practical inventory can record “app installed using the organization's purchase identity; brand TikTok account uses its existing email login.” That tells the operator which owner to contact for an installation problem versus an app-login problem. It does not require recording passwords in the inventory.

None of these identity choices establishes that TikTok receives an Apple Account's complete history or grants a particular sign-up method guaranteed reach. Choose a method your organization can control and recover.

Build a small fleet you can diagnose

A useful pilot includes a representative phone model, correctly rated power equipment, a known data path where required, adequate networking, a clear control method and spare cables. Add basic records for device identity, app/OS version, assignment and last observed issue.

Test faults intentionally at a harmless boundary: disconnect a control session, reconnect, and verify the intended phone is still identifiable. Observe what happens when an upload fails before publication. Do not test destructive resets on an account that contains work you cannot recover.

Before enlarging the rack, answer: can another operator find Phone 3, reach its app and understand its current assignment? Can you replace one cable without bringing down five other phones? Can you distinguish a local host problem from a phone-side internet problem? Those answers predict maintainability better than a photo of a full rack.

When hosted or managed PhoneFarm access is a better fit

Hosted phone access removes the need to build this physical stack beside your team. You still need the account, useful content, a suitable network configuration and an operator who understands the workflow. Follow the setup checklist to see those remaining responsibilities.

For a managed physical fleet, discuss device requirements, operating scope, maintenance and escalation through PhoneFarm’s managed-service route. Compare the total work you would otherwise own, including replacements and support time. The strongest reason to rent is that the provided service solves the required workflow at an understandable cost, not that hardware ownership is always wrong.