A position paper

Why Farmly.

The case for moving from a single-process Appium plugin to a distributed Hub-Node device orchestrator — and what you get on the other side.

Engineering rationale
~6 min read
Last revised 2026

The plugin worked great for small setups. Then the lab grew, the team grew, the SLAs got teeth — and a single Appium process was suddenly carrying a load it was never designed to hold.

The Farmly thesis

Farmly is the evolution of appium-device-farm — same lineage, distributed architecture, built for the size of farm your CI now actually depends on.

Yesterday · v1

appium-device-farm

Monolithic Appium plugin

appium plugin install device-farm

One process. One point of failure.

evolved
Today · v2

Farmly Hub-Node

Distributed orchestrator + runners

hub + nodes + postgres

Independent nodes. Isolated failures.

10–500+

Devices per farm

99.9%

Hub uptime target

3 pkgs

Cleanly separated

0 restarts

On node deploys

§ 01

Why we moved to Hub-Node.

Production farms ran into the same five walls. Each had a forcing function — and each got a clean architectural answer.

Single process → Distributed

Failures stay local

One node crashes, the others keep serving. The hub routes around the failure — no single process can take the entire farm offline.

HTTP → WebSocket

Persistent transport

WebSocket replaces HTTP polling: faster round-trips, automatic reconnection, no brittle long-running session glue.

HUB

orchestrator

NODE

runner

WEB

frontend

Monorepo → Modular

Three packages, clean boundaries

Hub, Node, and Frontend ship as independent packages — versioned separately, tested in isolation, deployed without coordination.

hub
node

independent release timelines

Coupled → Decoupled

Deploy without interrupting tests

Roll out a node update without restarting the hub. Patch the hub without dropping running sessions. Both sides version on their own clock.

n1
n2
n3
postgres

row-level locking

LokiJS / SQLite → PostgreSQL

A real multi-node database

Row-level locking, true concurrency, write durability. LokiJS and SQLite couldn't safely handle multiple writers — Postgres does, and the farm scales to match.

§ 02

At-a-glance comparison

Two architectures, same problem space — picked apart row by row.

AspectPlugin · appium-device-farmOrchestrator · Farmly
ArchitectureMonolithic Appium pluginDistributed Hub-Node system
Installationappium plugin install device-farmHub + Node services + PostgreSQL
CommunicationHTTP pollingWebSocket (persistent, faster)
CodebaseMonorepo (cluttered)Clean separation (3 packages)
ScalabilitySupports multiple nodesOptimized for 10–500+ devices
High availabilitySingle point of failureNode failures don't affect Hub
DatabaseLokiJS + Prisma/SQLitePostgreSQL (multi-node concurrency)
Deployment updatesRequires Appium restartHub & Nodes update independently
Fault isolationCrash affects all devicesCrash affects only that node
Use caseSmall teams, CI/CDProduction farms, enterprises
ObservabilityLimited (mixed Appium logs)OpenTelemetry (traces, metrics, logs)
§ 03

Which should you use?

Both are alive. Both are supported. The right answer is the one that matches the shape of your operation.

Stick with the plugin

Small team, single host

  • Managing fewer than 10 devices
  • One developer or a tight squad
  • Simple CI/CD pipeline, no HA needs
  • You want minimal setup complexity
Recommended at scaleAdopt Hub-Node

Production farm, real load

  • Managing 10+ devices, often hundreds
  • Enterprise or shared platform team
  • 99.9% uptime is non-negotiable
  • Devices spread across labs and regions
  • Scalability and fault tolerance matter
§ 04

What you get with Farmly

Twelve capabilities — eight you already expect from a device farm, four that only come from going Hub-Node.

01

Enhanced session management

Streamline test workflows for efficiency — setup and oversight of driver sessions on iOS simulators, tvOS devices, and Android devices, all from one control plane.

02

Automated device recognition

Hassle-free testing as the system auto-detects connected Android, iOS, and tvOS devices — both simulators and real hardware — before session initiation.

03

Proactive pool management

During execution, the device pool updates with newly available hardware so tests always run on the freshest resources available.

04

Parallel testing, port-isolated

Concurrent runs through random-port allocation — boosts efficiency and decreases total testing duration without collisions.

05

Remote test execution

Built for distributed teams and diverse testing settings. Run on devices that live anywhere your network can reach.

06

Hands-on manual control

Testers get full device commands for exploratory, debugging, and user-interaction tests — depth and quality without leaving the platform.

07

Cloud-based testing

Integrates with cloud providers, allowing executions on cloud-hosted devices when on-prem capacity needs to flex.

08

Advanced reporting insights

An extensive dashboard delivers in-depth analysis of outcomes — informed decisions, strategic planning, no spreadsheet archaeology.

09

Fault-isolated by design

A crash takes down one node's devices, never the whole farm. The Hub keeps routing tests around the failure.

10

WebSocket transport

Persistent, faster, auto-reconnecting connections replace HTTP polling — better latency, better error recovery, less noise.

11

PostgreSQL state

Multi-node concurrency with row-level locking. No more LokiJS / SQLite tug-of-war when nodes scale past one.

12

OpenTelemetry built in

Traces, metrics, and logs — not a mixed Appium log file. Plug it into Grafana, Tempo, or your stack of choice.

Ready when you are

Build the farm your team actually deserves.

Start with the setup guide, plug in your first node, and watch the Hub light up. From single laptop to 500-device lab — same path.