A friend who runs a small studio came to me last winter. He was about to scale from six phones to twenty and wanted to know which server to buy.
I asked how many he ran today. Six, on an old computer, and it had been stable for months.
So why buy a server? He paused and said he assumed that once you have enough phones you need one, because everyone talks about cloud control.
I have had that conversation several times. A lot of people are pushed to the cloud not by a requirement but by the assumption that everyone does it.
Why a server seems like the default
Cloud control does have real reasons behind it. When devices sit in data centres in different cities and the person managing them is in an office elsewhere, a local setup cannot help. You are not going to move twenty phones onto your desk.
Agency work is another case. The devices belong to a client, you only have remote access, and cloud networking is the only route.
Both of those are about devices not being within reach. If the phones are sitting in your own studio and one computer can connect them, then a server is solving a problem you do not have.
What a server adds is real cost: monthly fees, maintenance, network configuration, and data leaving your machine. Added up, plenty of small teams pay for all of that without needing it.
What local deployment actually looks like
The components are simple: one computer, one workstation program, and some phones.
Install the iEasyRun AI workstation on the computer and the matching program on each phone. As long as they share a local network, or are connected by cable, they can communicate. Task scheduling, execution records, assets and screenshots all live on that computer, with no third-party server involved.
How phones connect depends on what you have:
| Phone type | Connection | Suits |
|---|---|---|
| iPhone | USB cable | Most stable connection, mirroring visible while you watch |
| iPhone | WiFi | No cable, flexible placement |
| Android | WiFi | Phone in a pocket, tasks sent from the computer |
| HarmonyOS | USB cable | HarmonyOS devices attached to the computer |
The installation selection page compares all four routes. Pick by phone and by your space.
Once installed, the standard checks are: the workstation homepage opens, at least one phone shows as online on the devices page, and the conversation page can send that phone an instruction. Clear those three and the rest is adding devices.
How many devices is limited by what
This is the most common question and it has no standard answer, because it is not a software limit.
First, ports and power. Phones on cables consume the four to eight native USB ports a computer typically has, so a hub is needed. Hubs have a trap: without independent power, adding a few devices starts causing dropouts. At scale, use a powered hub and spread devices across different USB controllers.
Second, the network. Routers cap concurrent connections, and a consumer router carrying dozens of devices will start refusing new ones or reconnecting repeatedly. At that size, move to enterprise equipment or split devices across networks.
Third, and most underestimated, what your tasks do. Tapping and typing are light, and an ordinary computer handles fifteen or twenty devices. If every device also needs live mirroring plus screenshot recognition, the load multiplies and the ceiling drops noticeably.
My suggestion is not to go by theoretical numbers but to load test with your own tasks. Run ten devices and watch whether CPU and memory curves stay flat. Add more while they do, and stop before the inflection point.
When you genuinely need the cloud
Three situations where local really does fall short.
Devices are spread across locations. Different cities, nobody on site, and a local setup cannot reach them.
Several people need to watch the same fleet at once. A local workstation runs on one computer, so collaboration means sharing that machine. The cloud lets people log in from a browser.
Tenant isolation is required. If you are an agency renting grouped devices to different clients, each client needing its own isolated view, a single local machine cannot do it.
Outside those three, most managing a dozen phones scenarios are served fine by local deployment.
The trade-offs, stated plainly
Three things in its favour: data stays in, with screenshots, accounts and records on your own machine; no monthly cost, since the software is free and there is no server to buy; and it keeps running when the internet does not, because saved workflows execute locally. The blog post on phone automation data security covers the data side in more detail.
The costs are these:
Checking on devices means being at that computer, or at least leaving it on. Managing a fleet while travelling is not possible locally.
If the computer fails, tasks stop. The cloud can have redundant nodes; locally there is one machine.
Scaling means buying hardware. More devices means more computers, hubs and network gear, which is a physical cost rather than a click.
If those costs are acceptable, local is the cheaper route. If they are not, you have probably reached the size where the cloud makes sense.
Keeping multiple devices organised
Once device count grows, the hard part is never the operation, it is the management. Which phones are online, how far a task got, and which device failed all take more energy than tapping buttons. Three habits on the device page save a lot of that.
Give aliases properly. A random device identifier and a label reading sales-1 or test-a are completely different experiences.
Group by your own business logic. By category, by model, by purpose, whichever fits, as long as you can pick the right group when dispatching. Sending tasks by group is faster than ticking devices individually, and less error-prone.
Remember the hard rule: an offline device can be seen but cannot run tasks. Confirm the target is online before dispatching. If it shows offline, go back to the install page and check USB, WiFi, the phone-side program and the workstation.
Back to my friend. He did not buy a server. He put the money into a better computer and a powered hub instead, and the twenty phones have been running for over half a year. One thing he said last month stuck with me: what needs a server is not the number of phones, it is the distance between you and them.
If the phones are within reach, start by installing it and trying one device. The software is free, so there is no server bill to pay before you validate the idea.
Frequently asked questions
- Without a server, where do tasks and data live?
- On your own computer. iEasyRun is a locally run workstation, so task scheduling, execution records, screenshots and assets all stay on that machine. The phone-side program only receives instructions and performs actions, with no third-party server in between.
- How many phones can local deployment handle?
- There is no fixed software limit. What matters is USB ports and power, network capacity, and how heavy your tasks are. Light tasks such as tapping and typing scale far higher than heavy ones involving live mirroring plus screenshot recognition.
- What computer specification do I need?
- An ordinary office PC is enough to start. Screenshot capture and image recognition are what really load the machine, and that grows with device count and task weight. Past twenty or thirty devices, give it a dedicated computer rather than sharing with daily work.
- Do phones have to be plugged into the computer?
- Not always. Android connects over WiFi, so phones can sit in another room. iOS supports both USB and a wireless route, and HarmonyOS uses USB. Wired is usually more stable, wireless is more flexible in placement, so pick by your space.
- Can tasks run if the network goes down?
- If the computer and phones communicate over the local network, cutting that network cuts the link between them; devices connected by USB are unaffected by internet outages. One caveat: if a task relies on an online model to plan or generate a flow, that part is affected, while saved workflows run locally without calling a model.
- How does local deployment compare with cloud control?
- Cloud control is strong at remote management and centralised orchestration, which matters when devices sit in data centres across cities. Local deployment keeps data in-house, has no monthly server cost, and keeps working when the internet does not. Single-site setups usually favour local; genuinely distributed fleets need the cloud.
- Do a dozen phones interfere with each other?
- Not at the software level. Each device runs its own session, so tasks do not compete for the same context. Interference usually comes from hardware instead: one USB hub without enough power, or one router with too many concurrent connections. Grouping and splitting solve that.
- How should multiple devices be organised?
- Three habits on the device page: give each phone a readable alias, group devices by business line or model, and remember that an offline device can be seen but cannot run tasks. Dispatching by group is faster and makes failures easier to trace.
Runs on your own PC
No server to buy, install it and start managing devices
Software is completely free, runs locally, and keeps your records on your own machine.