How to Build a Phone Farm: The Parts List, and the Part Everyone Forgets

A phone farm is a rack of real smartphones you can drive from one place. People build them to test apps on hardware instead of in an emulator, to run the same flow across many devices at once, to keep one device per account or per client, and to see what an app actually does on a phone that has a battery, a camera and a radio in it.

The idea is simple. The build is not. What follows is the full parts list, in the order you hit the problems, and an honest look at what you save by doing it yourself and what you do not.

One slot, six problems

Before you count phones, count what a single phone in a farm needs. Every decision in the build scales out of this one picture.

Miss any one of the six and the farm works right up until it does not. A phone that overheats throttles instead of erroring. A phone with no route of its own is indistinguishable from the nineteen beside it. A phone you cannot address by name is a phone you have to walk over to.

The six subsystems

1. Mounting

Phones laid flat on a shelf is the classic first build and the classic first failure. Each device needs its screen reachable, its port reachable, and enough clearance that it is not sitting in its neighbor's heat. Upright on the long edge in a slotted cradle is the dense answer: every device gets the same air path, and every device is one reach from the front. Ten phones on a shelf is untidy. Twenty is a thermal problem you cannot fan your way out of.

2. Power and charging

Twenty phones charging is twenty power budgets. The naive build is a multiport charger on an extension lead with everything pinned at 100 percent forever, which is the worst long-term state for a lithium cell and the reason farm phones swell. Plan for enough current that a device does not drain while it works, cables rated to live plugged in permanently rather than a bag of gas station leads, and some way to cut one slot without pulling the rack apart.

3. Airflow

A phone running a video app is a small, constant heat source, and Android throttles long before it complains. What you want is a defined path: air in one face, across the devices, out the other, with fans sized to the enclosure rather than to whatever was in the parts bin. If your automation gets measurably slower over the first hour of a run, this is almost always why.

4. The device link

You need a way to send input and read the screen for every device. Wired means USB, which means hubs, and the discovery that consumer hubs enumerate twenty devices unevenly, drop ports under load and need their own power. Wireless means no cable to fail and a hard dependency on the network being healthy. Either way, budget time for the state where nineteen devices answer and one does not, because that state is the daily reality of running a farm.

5. Network identity

This is the subsystem people skip and then regret. Put every phone on one Wi-Fi network behind one router and you have twenty devices sharing one public address, one route and one identity. Android devices with a SIM slot and mobile data each get their own carrier route, their own address and their own number. It costs more per device, and it is the difference between a rack of phones and a rack that behaves like phones.

6. Control address

Every device needs a stable handle: a slot number or a name that means the same phone tomorrow morning. Serial numbers churn when devices reconnect, and a farm addressed by "whatever port it came up on" will eventually run the right flow on the wrong device, which is worse than not running it at all.

The seventh thing, and the one that takes the longest

Steps one to six are shopping and a screwdriver. You can get through them in a weekend and a couple of returns. Step seven is a software project, and it is the one that decides whether you own a phone farm or a shelf of phones.

Every farm needs the same control plane, and no amount of aluminium gives you any of it. On one device you can get surprisingly far with adb for input and scrcpy for mirroring. The gap between that and twenty devices running unattended is where the project lives: reconnect logic, a device that comes back with a different identifier, a flow that half-succeeded, a phone that fell asleep, a screen that changed because the app shipped on Tuesday.

It is also the part you keep paying for. Apps move buttons, Android changes behavior between versions, and a farm is only as good as the software that noticed.

So what does it cost?

Do not take a number from a blog post here. Prices for hubs, chargers and rack parts move constantly and depend heavily on where you buy. Price your own list against these lines:

• Chassis or shelving, and cradles or mounts for each device.
• Power: charging capacity for every slot at once, plus cables built to stay plugged in.
• Cooling: fans, and an enclosure that gives them something to push air through.
• The link: powered hubs and cables, or the access point capacity to keep twenty devices reachable.
• The network: SIMs and data plans if you want per-device routes. This one is monthly, not one-off.
• A controller: whatever machine stays awake to run the thing.
• The phones. Whatever the frame costs, twenty devices cost more.

Then add the two costs nobody puts on the list: the hours it takes to write and debug the control plane, and the maintenance tail that follows it forever. If your hourly rate is a real number, run it against the estimate honestly. That is usually the line that decides the build.

The bought version

We build one, which is why this post exists. AiPhoneFarm is a 2U 19 inch short-depth metal deck, 482 by 89 by 350 mm, with twenty cradle slots where phones stand upright on their long edge. Cooling and power are inside. So is the controller: the deck joins your Wi-Fi and runs the control software itself, so there is no host PC anywhere in the chain.

The software that ships on it is the seventh item above: a live grid of every connected screen, broadcast input to one device or all of them, record and replay for flows, scheduling with staggered starts, per-device profiles, and health monitoring for battery, temperature and connectivity. It is driven from a browser on your network, from a JavaScript SDK, or over MCP.

It is 399 € once, VAT and shipping included, and ships within three weeks. The control software runs on a 100 €/year plan, and the first year is already in the deck price. That plan buys updates and access to the source on GitHub. If it lapses the deck keeps running exactly as it is; what stops is new versions. A deck bought right now also carries three months of the AiSlop.cc Creator video plan, 59 €/month afterwards.

Phones are still yours to source, and SIM slots with 5G data are still worth the trouble.

See the deck and the full specifications →

Frequently asked questions

How many phones should I start with?

Fewer than you think. A farm you can actually keep healthy at four devices teaches you more than twenty devices you never finish wiring. One deck holds twenty and the control software addresses up to twenty per deck on a single plan, with no per-device license, so there is room to grow into it. Past twenty it is a second deck with its own plan.

Do the phones need SIM cards?

Strongly recommended. A phone on its own mobile connection has its own IP, its own carrier route and its own number, rather than sharing one address with every other device in the rack. It is the single biggest difference between a rack of phones and a rack of phones on one Wi-Fi network.

Do I need a PC to keep it running?

Not with the deck: the controller ships inside it, so the rack needs power and Wi-Fi and nothing else. In a DIY build, yes, and remember that machine has to stay awake, stay patched and stay plugged in for as long as the farm runs.

Is running a phone farm allowed?

The hardware and the software are general-purpose device automation tools, the same category as any test rig. You are responsible for operating within the terms of service of every platform you touch, and for the accounts and the content you run. Owning the devices does not change what the platforms allow.

Keep reading

Still deciding whether you need real hardware at all? Read emulators versus real Android devices. Once the rack exists, pointing an AI agent at it over MCP is where it gets interesting.