OpenSTF is dead. What to do with your device lab in 2026

If you run a self-hosted Android device lab, you are probably running OpenSTF, and you have probably noticed that nobody is coming to fix it.

The original openstf/stf repository went quiet around 2020. The project was never formally killed — it just stopped. Issues stayed open, PRs stopped merging, and the Docker images stopped tracking new Android releases. What followed is one of the more interesting slow-motion problems in mobile testing: a large number of working device labs, built on a stack whose maintenance has effectively ended, still running because nobody has had a forcing event yet.

This is an honest look at where that leaves you in 2026, what the actual options are, and where the trade-offs sit. We build a competing thing, so read accordingly — but the parts about STF are checkable, and the parts where we are the wrong answer are marked.

What STF actually was

Smartphone Test Farm did something genuinely hard and did it well: it took a rack of physical Android devices attached to a host, and gave you a browser UI that could see and control any of them. Screen mirroring, remote input, a shell, app install, device reservation, a REST API. It was the reference implementation of "a device lab you can use from a browser", and for a lot of teams it still is.

The architecture is a set of Node services — a websocket app, a device-side agent, a provider process per host, RethinkDB for state, a storage service for uploads. That decomposition was reasonable in 2016 and is a substantial part of why the project is hard to revive now.

What actually broke

Not the core idea. The core idea works. The problems are structural and they compound:

RethinkDB. STF's state store. The company behind RethinkDB shut down in 2016; the database became a community project and its momentum has been modest since. Building a 2026 device lab on it means adopting a second orphaned dependency to run your first one.

The Android treadmill. Every Android release moves something that a device-control stack depends on — the input injection path, screen capture permissions, what a non-root shell can reach, how dumpsys output is formatted. STF's minicap and minitouch binaries are per-ABI, per-SDK native components. When a new Android version lands and your capture stops working, the fix is a native binary rebuild that nobody upstream is doing.

Scoped storage and permission tightening. Android has spent a decade steadily removing the ability of one process to observe and manipulate another. Much of what a device-control agent needs to do sits precisely in that shrinking space.

Node and dependency rot. A 2020-era Node service tree does not npm install cleanly in 2026. Transitive dependencies have CVEs, some have been unpublished, and the build has native modules that expect toolchains that have moved on.

None of these individually kills a lab. Together they mean the honest cost of running STF today is "keep one engineer who knows the codebase", and that engineer's time is the most expensive thing in the equation.

DeviceFarmer: the fork that exists

DeviceFarmer/stf is the community continuation, and it is the reason plenty of labs are still standing. It has taken real maintenance work — dependency updates, newer Android support, published images.

If you are on STF today and it works, DeviceFarmer is the lowest-risk move you can make, and you should evaluate it before anything on this page. Migrating from an abandoned upstream to a maintained fork is a much smaller project than migrating off the platform.

Understand what it is, though: a volunteer-maintained fork of a large legacy codebase, carrying the same architectural inheritance — RethinkDB, the native capture binaries, the multi-service topology. It is keeping a valuable thing alive. It is not a rewrite, and it does not make the treadmill go away.

The four honest options

Stay on STF, unmaintained

Viable if your device set is frozen and your Android versions are frozen. Labs pinned to specific older devices for regression testing can run like this for years. The risk is not gradual — it is a step function, on the day a security review, an OS update, or a dead host forces a rebuild you can no longer perform.

Move to DeviceFarmer

The default recommendation. Smallest change, keeps your workflows, buys real time. Budget for the migration properly and check your specific devices are supported before committing.

Buy a commercial device cloud

BrowserStack, Sauce Labs, AWS Device Farm, Firebase Test Lab, LambdaTest. If what your lab is actually for is running a test matrix across many device models before release, this is the right answer and has been for a while. You stop operating hardware entirely.

The catch is the thing STF users tend to care about most: you do not get a raw root-capable shell. These platforms expose sessions, not devices. That is a structural consequence of multi-tenancy — a tenant with su on a shared device breaks the isolation guarantee the whole platform rests on — and no amount of asking will change it. If your lab exists because you need root, custom kernels, Magisk modules, or a device in a specific modified state, a commercial cloud does not replace it.

Rent specific real devices with raw ADB

This is the category we are in, alongside a few other small players. You do not own hardware, and you still get a device rather than a session — a real phone with a real shell, reachable from your own tooling.

Where we are honestly the wrong answer: we are six Pixel 7a. If you need forty device models, we cannot serve you and are not pretending to. If you need iOS, we do not have it. If you need root, we do not have that either yet — our bootloaders are locked, so a lab that exists to run Magisk modules or custom kernels is not something we can replace today. And if your lab's value is that the devices sit on your own network under your own control for compliance reasons, renting does not solve that.

Where it fits: you need a specific real phone with a raw ADB shell, driven from a script, and you do not want to be the person who owns the USB hub.

If you are migrating, do this first

Before choosing anything, work out what your lab is actually for. In our experience the answers split cleanly, and the split determines the answer:

• Coverage — many models, automated runs, pre-release matrix. Buy a commercial cloud. Your lab was a cost centre standing in for a product that now exists.
• Control — root, custom ROMs, instrumentation that needs elevated privileges, hardware you have modified. No commercial cloud will serve you, and today neither will we. Stay self-hosted on DeviceFarmer.
• Latency or locality — the devices need to be on your network, or physically near something. Stay self-hosted. Nothing remote fixes this.

Most labs think they are the second and are actually the first. It is worth being rigorous about, because the answer changes what you should spend the next quarter doing.

The thing worth saying plainly

STF was a good piece of software that solved a real problem, and the fact that a volunteer fork is still carrying it six years after upstream went quiet says something about how well it was built.

But the reason it went quiet is worth sitting with: maintaining a device-control stack against a moving OS is genuinely hard, unglamorous, permanent work. That is the actual product in this category. Any replacement you pick — fork, cloud, or rental — you are choosing who does that work. Make sure it is someone who is going to keep doing it.