Best open-source tools for running your own Android device farm

I’ve spent enough time crouched next to a USB hub at 2am, watching one phone in a rack of forty drop off adb for no reason anyone can explain, to have opinions about this stack. This list is for anyone building the same thing: a shelf, a rack, or a cupboard full of real Android phones wired into a PC (or several) for testing, automation, or remote access, and looking for the open-source software that actually runs it.

It is not for people testing on emulators only. Emulators solve a different problem, and most of the tools below either don’t help you there or assume real hardware with real USB quirks. It’s also not a list of paid device-farm SaaS. Firebase Test Lab, AWS Device Farm, and BrowserStack App Live all solve this problem too, just not self-hosted, so they’re out of scope here.

I picked based on what’s actually running in production farms I’ve read the source of or used myself, not what has the shiniest README.

How I picked

has to work against real, adb-connected hardware, not just an emulator image
solves, or is a clean building block for, one of: device visibility and remote control, adb multiplexing across many devices, scheduling test runs across a pool, or provisioning phones into the farm
still gets commits, releases, or active fork maintenance, not a repo gone silent for years with 200 open issues
documentation good enough that I could get it running without reading the source line by line
license lets you self-host, even commercially, without a call to a sales team
extra weight for tools that other tools on this list depend on, since half this ecosystem is built in layers

The picks

A few things I looked at and left out on purpose. The original openstf/stf repo, which its maintainers archived back in 2019 in favour of community forks, so I’m covering the fork below instead. minicap and minitouch, the native screen-capture and touch-injection binaries STF was originally built on, because they’re bundled inside the forks now rather than something you’d install standalone. And Android’s own Trade Federation, Google’s open-source continuous testing infrastructure for AOSP, left off because it’s built to test the Android platform itself, not your app, and it’s a much heavier adoption than anything else here. If any of this adb terminology is new, the rest of the blog covers it in more depth.

DeviceFarmer/stf

STF stands for Smartphone Test Farm, and it’s the closest thing here to a finished product: a web dashboard listing every phone plugged into your farm, letting anyone on the team click a device and remote control it from the browser, screen mirror plus touch, over websockets, with a reservation system so two people don’t grab the same phone at once.

Under the hood it runs “provider” processes, one per host machine, each holding an adb connection to every phone on that box and reporting device state to a central server. That’s the multiplexing layer: instead of forty terminal windows, STF’s providers do it for you. What is adb client-server daemon covers the client/server split this is built on top of.

browser-based remote control of any device in the farm, no separate viewer app
reservation and auth system, so a farm shared across a team doesn’t turn into a free-for-all
documented Kubernetes and Docker setups for scaling providers across more than one host as the rack grows
install is genuinely fiddly: RethinkDB, a matching Node version, and native minicap/minitouch binaries built per device ABI, and getting all three aligned costs most people an afternoon
issue tracker is full of unanswered issues considering how much infrastructure quietly depends on this project

Free, MIT license, self-hosted. github.com/DeviceFarmer/stf

DeviceFarmer/adbkit

This is the library STF’s providers actually use to talk adb, worth listing on its own if you’d rather build your own farm tooling than adopt STF wholesale. adbkit re-implements the adb wire protocol in pure JavaScript, so one Node process can track devices, push and pull files, run shell commands, and grab screenshots across dozens of phones without spawning a new adb subprocess per call.

The original openstf/adbkit stalled, so DeviceFarmer forked and kept it current. Once your farm outgrows one USB hub, you’ll want adb tcpip 5555 to switch a phone to network mode and connect over the LAN instead of a cable, and adbkit handles that connection the same way it handles USB.

pure JS, no native adb binary needed just to hold the protocol connection
small enough to embed in a custom scheduler or dashboard instead of shelling out to a CLI
doesn’t hold an exclusive lock the way an interactive adb shell session can, so it plays fine alongside scrcpy or Appium hitting the same device
it’s a library, not a product. you write the UI, the scheduler, and the auth yourself

Free, MIT license. github.com/DeviceFarmer/adbkit

uiautomator2 and atxserver2

openatx’s stack is the Python-first alternative to the Node/STF world. uiautomator2 is a Python client that drives a small automation agent on the device, so automation code looks like d.click(x, y) instead of Java or Espresso. atxserver2 is openatx’s own farm manager, an STF-style console built specifically to pair with pools of uiautomator2-controlled devices.

If your team is already Python-heavy, this pairing means you never touch Node or RethinkDB at all. I’ve written about the automation side in more depth in android RPA with adb and uiautomator2, which covers what the on-device agent actually does.

automation code is plain Python, a lower bar for a QA team that isn’t full-time Java developers
atxserver2 gives device grouping and reservation without adopting STF’s Node stack
pairs cleanly with weditor, openatx’s element inspector, for figuring out what to click on unfamiliar apps
smaller community than Appium, and a chunk of the docs and issue history skews towards Chinese, which slows troubleshooting if you don’t read it
the on-device agent architecture has changed more than once over the project’s life, so older write-ups about it, including some of mine eventually, will drift out of date

Free, MIT license. github.com/openatx/uiautomator2, github.com/openatx/atxserver2

scrcpy

scrcpy isn’t a farm manager. It’s what you actually reach for once STF or atxserver2 tells you which phone in the rack is misbehaving and you need eyes on it right now, without walking over to the shelf. It mirrors and controls a device’s screen over adb, USB or TCP/IP, no root, nothing installed beyond a small server binary it pushes over on connect.

Point it at one serial out of forty with scrcpy -s <serial> and you’re looking at that phone’s screen inside a second. On a rack sharing one USB 2.0 hub’s bandwidth across many phones, the default bitrate and resolution can make things laggy in a way that looks like the phone is broken when it’s actually just scrcpy’s settings. I go through the fix in best scrcpy settings to fix lag and stuttering, and the full control walkthrough is in scrcpy guide: control Android from desktop.

fastest way to get eyes and touch input on one specific device in a large farm
actively maintained by Genymobile, frequent releases that keep pace with new Android versions
works over TCP/IP too, useful once the rack outgrows one machine’s USB ports
single-device by design. mirroring a whole rack means one scrcpy window per phone, which stops being visually useful past maybe six or eight windows

Free, Apache-2.0 license. github.com/Genymobile/scrcpy

Marathon

Getting a farm of devices is only half the problem. The other half is running your test suite across all of them evenly, without one phone finishing in ten seconds while another is still ninety minutes deep. Marathon, from MarathonLabs, is a cross-platform test runner that shards an instrumentation or UI test suite across a pool of adb-connected devices, retries flaky tests automatically, and reports results per device.

This is the scheduling piece specifically. STF or atxserver2 get you access to the phones; Marathon is what makes a CI run against forty real devices behave like forty devices working together instead of forty independent headaches. Real-device UI tests flake more than emulator ones for reasons that have nothing to do with your app, which I cover in why Android UI tests are flaky. Marathon’s retry and quarantine logic exists because of exactly that.

device pool discovery over adb out of the box, no separate inventory system
built-in flaky test retry and quarantine, instead of shell scripts bolted on after the fact
works for Android instrumentation tests and iOS XCUITest, if the farm ever grows a second platform
config is a YAML or Kotlin DSL that takes a genuinely annoying afternoon to get right the first time
it schedules tests, it doesn’t provision or manage the devices themselves, so STF, atxserver2, or your own tooling still sits underneath it

Free, Apache-2.0 license. github.com/MarathonLabs/marathon

appium-device-farm

If your team already has an Appium or WebdriverIO suite and just wants it to fan out across the rack instead of running one phone at a time, this Appium 2.0 plugin is the lowest-effort path. Install it with appium plugin install --source=npm appium-device-farm, point Appium at your pool of connected devices, and existing WebDriver capabilities get routed to whichever real phone is free, with a small dashboard showing what’s online.

It’s aimed at automated test routing, not manual device poking, so it’s a different tool from STF even with some overlap in what a dashboard shows. Taps and swipes issued through Appium’s UiAutomator2 driver come down to the same primitives covered in adb shell input: tap, swipe, text, keyevent, worth knowing when a gesture works over raw adb but not through your test framework, because that tells you where the bug actually is. Appium’s plugin architecture is documented at appium.io.

reuses an existing Appium/WebDriver suite unmodified, no automation rewrite
works across multiple host machines, so you’re not capped at one PC’s USB ports
simple device status dashboard, so you’re not guessing what’s online from log output
you still own Appium server setup and per-device capability config, Android version, screen size, and so on, which gets tedious past a dozen phones
less useful than STF if what you actually want is casual manual remote control rather than routed automated tests

Free, Apache-2.0 license. github.com/AppiumTestDistribution/appium-device-farm

Comparison table

tool	price	primary strength	primary weakness
DeviceFarmer/stf	free, MIT	browser remote control plus reservations for the whole rack	fiddly install: RethinkDB, native binaries, pinned Node version
DeviceFarmer/adbkit	free, MIT	pure-JS adb multiplexing to build your own tooling on	just a library, no UI or scheduler included
uiautomator2 + atxserver2	free, MIT	Python automation paired with its own farm console	smaller community, docs skew towards Chinese
scrcpy	free, Apache-2.0	fastest way to actually look at one device	not built to visualise the whole rack at once
Marathon	free, Apache-2.0	sharding and flaky-test retry across the pool	config DSL has a learning curve, doesn’t manage the phones
appium-device-farm	free, Apache-2.0	routes an existing Appium suite across the farm	still need Appium server plus per-device capability setup

How to choose

If you’re starting from nothing and want one thing a small team can use to see and reserve real phones without writing glue code, start with DeviceFarmer/stf despite the install pain. It’s the only project here that’s a finished product rather than a library or plugin, and once it’s running, everyone gets browser access without you building a viewer.

If your team already writes Python and would rather not touch Node or RethinkDB at all, go straight to uiautomator2 paired with atxserver2. Smaller community, and you’ll occasionally land on an issue thread written in Chinese, but the automation code is easier for most QA teams to pick up than Espresso, and you get a comparable farm console without STF’s install chain.

If you already have a working Appium or WebDriver suite, appium-device-farm is the cheapest add-on in every sense, since it doesn’t ask you to rewrite anything, only route it. Layer Marathon on top of whichever farm manager you land on if flaky tests and uneven scheduling are the actual pain, because none of the farm managers here solve that on their own.

Two hardware realities matter more than the software past a certain size. One PC only has so many practical USB ports before power delivery gets unreliable, so plan for adb over TCP/IP and multiple hosts earlier than you think you’ll need to. And every phone needs its adb RSA key authorized before any of these tools can see it, covered in adb authorization: RSA keys explained; past a couple dozen phones, doing that by hand every time gets old fast, so script it early.

If the honest answer is you don’t want to run physical hardware yourself, that’s a real option too. cloudf.one rents real Android phones on dedicated hardware in Singapore, Singapore-only, each with a persistent Singapore mobile IP, and you control the phone from the browser, no rack, no RethinkDB, no USB hub to babysit. Worth knowing going in: there’s no self-service adb. Appium and adb only reach a rented phone through a WireGuard tunnel set up on request, you email [email protected] and they configure it, it’s not a self-serve toggle in a dashboard. If your workflow assumes you can point Appium at a rented phone the instant you sign up the way you would your own rack, that’s the gap to plan around.

Verdict / top pick

For the case this list is actually about, a self-hosted rack of real Android phones that more than one person needs to see and use, DeviceFarmer/stf is still my pick despite the install being the worst part of the whole stack. Nothing else here gives browser remote control and device reservations out of the box. If your team is Python-first, uiautomator2 plus atxserver2 is the equally valid second answer, and honestly the one I’d point a smaller team toward first, since the install pain is lower.

One honest gap: I’ve run Marathon against Android device pools but not against a mixed Android and iOS farm, so I can’t personally vouch for how well its cross-platform story holds up, only that it’s documented to work that way.

Written by Xavier Fok

disclosure: this article may contain affiliate links. if you buy through them we may earn a commission at no extra cost to you. verdicts are independent of payouts. last reviewed by Xavier Fok on 2026-09-23.