9 Best AWS Device Farm Alternatives in 2026

1. Sauce Labs Real Device Cloud

Sauce Labs runs a public real-device cloud plus an enterprise-only private device pool, and its documentation lists Appium, Espresso and XCUITest among its frameworks, along with Flutter and Maestro. Its documented data center endpoints are US West, US East, EU Central and Asia South, which is the clearest answer on this list to Device Farm's single Region.

• App formats - Mobile App Storage accepts .apk and .aab files for Android and .ipa or .zip files for iOS, up to 4 GB, and keeps them for up to 60 days.
• XCUITest scope - XCUITest runs on real devices only, because Sauce Labs does not support automated XCUITest runs on simulators.
• Check first - On real devices, newCommandTimeout is capped at 90 seconds, so any step that leaves the device idle for longer than that between commands will end the session.

2. TestMu AI (Formerly LambdaTest)

TestMu AI's Real Device Cloud gives you 10,000+ real Android and iOS devices, which you can use as a shared public cloud, a dedicated cloud reserved for your team, or an on-premise cloud behind your firewall. Appium, Espresso and XCUITest suites run on those devices, and you can upload .apk, .aab or .ipa files directly or from a URL.

• Migration path - Appium tests keep their code and only change the hub URL and capabilities, while Espresso and XCUITest builds upload as an app plus a test package, the same pair Device Farm uses. The Espresso testing tutorial shows that upload flow end to end.
• Scale - Suites run in parallel across many devices, and HyperExecute splits large suites into shards for up to 70% faster runs.
• Evidence - Each session can capture device logs, network logs and video, so a failed run arrives with what you need to debug it.
• Check first - Appium sessions run on emulators and simulators unless you set isRealMobile to true, and the most requested flagship phones on the shared public cloud can queue briefly at peak times.

For a product-level view of the two platforms, the AWS Device Farm alternative page compares the two products on billing, device access and session launch times.

3. Kobiton

Kobiton is a real-device platform that also offers Android virtual devices for manual sessions, and you can run it in its cloud, on privately hosted device slots, or fully on premise. Its pricing page lists scripted Appium, Selenium, Espresso and XCUITest, and its documentation covers Android 8 through 17 and iOS 12 through 27.

• App formats - Kobiton accepts .apk, .aab, .ipa and .zip uploads of up to 4 GB.
• Scriptless automation - Interactions captured during a manual session can be replayed as an automated test.
• XIUM - Kobiton describes XIUM as its own high-speed reimplementation of the Appium server.
• Check first - For native and hybrid apps, the first request must arrive within 30 minutes and every later request within 10 minutes, or the session ends.

4. pCloudy

pCloudy offers real iOS and Android devices with no emulators or simulators, and it runs Appium, Espresso and XCUITest automation alongside manual testing. You can buy public cloud access, reserve dedicated devices, or move to a private cloud or on-premise deployment, and its single-tenant private cloud is hosted across India, the USA, Dubai and Singapore.

• Android App Bundles - pCloudy accepts .aab files and converts them into device-specific APKs before installing them.
• Device features - Its docs cover image injection into the Android gallery and Face ID or Touch ID testing on iOS.
• Performance data - pCloudy advertises 60+ app performance metrics across speed, memory, CPU, battery and network.
• Check first - Published plans go up to 20 parallel tests, and anything above that needs a custom agreement with their sales team.

5. Bitbar (SmartBear)

Bitbar tests on real devices only, hosted in data centers in Poland and the United States. Its documentation lists Appium, Android Instrumentation, Espresso, Flutter and Robot Framework for Android, and Appium, Flutter, XCTest and XCUITest for iOS. You can also bring your own framework as a Docker container on Android or a customized VM on iOS, which is the nearest equivalent to Device Farm's custom test environments.

• Deployment - Choose dedicated devices reserved for your team in the public cloud, or a separate private cloud with dedicated devices and desktop browsers.
• Test length - The default test timeout is 1,800 seconds, and teams with an active plan can adjust it.
• Biometrics - Biometric authentication testing works in live testing and in both client-side and server-side Appium runs.
• Check first - Bitbar documents Android App Bundles for live testing, while its Appium app capability lists .apk and .app files, so confirm .aab support for automation before you rely on it.

6. Perfecto (Perforce)

Perfecto, part of Perforce, offers real and virtual devices, and Perforce says it manages more than 10,000 devices across 11 global data centers. Its help center documents Espresso for Android 4.3 or later, XCUITest for iOS 15 or later, and Appium 2, with Selenium and Playwright for desktop web testing.

• App formats - Real devices take IPA, APK, APKS or AAB files, while virtual devices take ZIP files for iOS and APK or APKS files for Android.
• Private clouds - Perfecto offers private, dedicated clouds for teams that do not want to test on a shared public pool.
• Camera injection - You can inject images to simulate the camera, which helps with barcode readers and banking apps.
• Check first - Appium 1 executions ended on December 21, 2025, so any suite still pinned to Appium 1 needs an upgrade before it moves.

7. HeadSpin

HeadSpin focuses on testing under real-world conditions with SIM-enabled devices in 50+ locations worldwide, along with browsers, OTT media devices and smart TVs. Its integrations include Appium, Selenium, XCTest and Espresso, and you can deploy it as a shared cloud, a dedicated cloud, an air-gapped on-premise lab, or on-premise devices connected through a VPC.

• Performance KPIs - HeadSpin tracks 130+ built-in KPIs across UI, network, device and experience metrics.
• Video quality - Reference-free Video MOS scores what users see on screen, which matters for streaming and other video-heavy apps.
• Usage tiers - The entry tier is public cloud only with 40 hours of usage a month, while higher tiers add dedicated and air-gapped devices.
• Check first - I could not find documented .aab support on its public pages, so ask about it before you migrate a bundle-based pipeline.

8. TestGrid

TestGrid offers real iOS and Android devices in its cloud, dedicated hosted devices, and on-premise device labs that sit behind your firewall. Its documentation lists Appium, Selenium, Cypress, XCUITest, Espresso, Detox and WebdriverIO, and it runs XCUITest and Appium on real iOS devices without a jailbreak.

• Codeless authoring - Record and play and low-code automation sit alongside scripted tests in the same platform.
• Queueing - Tests that target the same device follow that device's concurrency limit and wait in a first in, first out queue.
• Check first - The app management docs list APK and IPA uploads only, so plan to keep building an APK if your pipeline produces .aab files.

9. Firebase Test Lab (Google)

Firebase Test Lab runs tests on real devices in a Google data center, plus virtual Android devices, and it accepts .aab files. It supports Espresso and UI Automator instrumentation tests, the Robo crawler that explores your app without a script, and XCTest on iOS, but Appium is not among its documented test types.

Google has deprecated Firebase Test Lab and will shut it down on September 30, 2027, according to the notice on its documentation. The suggested replacement, Developer Device Platform on Google Cloud, is in Preview and currently runs Android instrumentation and iOS XCTest tests through the gcloud beta device-run CLI.

• Test length - Tests default to 15 minutes, with a maximum of 45 minutes on physical devices and 60 minutes on virtual devices.
• Sharding - Sharding limits are 50 for physical devices, 200 for Arm virtual devices and 500 for x86 virtual devices.
• Check first - Moving here means planning a second migration within a year, so I would only pick it for Android-heavy teams already committed to Google Cloud.

Map the Test Spec to Capabilities

In a server-side run, your test spec starts Appium on AWS's test host and passes the device details in through DEVICEFARM_ environment variables. This trimmed excerpt follows the Appium Android example in AWS's test spec reference:

version: 0.1
android_test_host: amazon_linux_2

phases:
  install:
    commands:
      - devicefarm-cli use node 22
      - devicefarm-cli use appium 3
      - devicefarm-cli use java 17
  pre_test:
    commands:
      # Starts Appium on the AWS test host. The device details arrive as variables:
      # $DEVICEFARM_DEVICE_NAME, $DEVICEFARM_DEVICE_UDID,
      # $DEVICEFARM_DEVICE_OS_VERSION and $DEVICEFARM_APP_PATH
      - appium --default-capabilities "<built from the variables above>" >> $DEVICEFARM_LOG_DIR/appium.log 2>&1 &
  test:
    commands:
      - cd $DEVICEFARM_TEST_PACKAGE_PATH
      - java org.testng.TestNG -testjar *-tests.jar -d $DEVICEFARM_LOG_DIR/test-output

artifacts:
  - $DEVICEFARM_LOG_DIR

A hosted grid needs no test spec, because the Appium server already runs in the cloud. Your test creates a remote session instead, and the values AWS injected as environment variables become explicit capabilities:

• Server URL - Point the driver at the TestMu AI mobile hub with your username and access key, instead of the local Appium server on port 4723 of the AWS test host.
• Device selection - Replace DEVICEFARM_DEVICE_NAME and DEVICEFARM_DEVICE_OS_VERSION with deviceName and platformVersion, and drop udid, because the cloud assigns a matching device for you.
• App - Replace DEVICEFARM_APP_PATH with the lt:// app ID that the upload API returns when you push your build.
• Real hardware - Add isRealMobile: true, or the session runs on an emulator or simulator.
• Client-side runs - If you used the Appium endpoint, delete the GetRemoteAccessSession call that fetched remoteDriverEndpoint and add the device capabilities back, since AWS's endpoint rejects udid and platformVersion.

Run the Same Test on Real Devices in Parallel

To check this path end to end, I ran one search test from the Ecommerce Playground on a Galaxy S25 with Android 15 and an iPhone 16 with iOS 18, both real devices, at the same time. This is the exact script I ran with Node.js and selenium-webdriver:

// npm install selenium-webdriver
const { Builder, By, until } = require("selenium-webdriver");

const HUB = "https://" + process.env.LT_USERNAME + ":" + process.env.LT_ACCESS_KEY + "@mobile-hub.lambdatest.com/wd/hub";

const devices = [
  {
    platformName: "Android",
    browserName: "Chrome",
    "lt:options": {
      deviceName: "Galaxy S25",
      platformVersion: "15",
      isRealMobile: true,
      build: "AWS Device Farm migration check",
      name: "Search - Galaxy S25",
      w3c: true
    }
  },
  {
    platformName: "iOS",
    browserName: "Safari",
    "lt:options": {
      deviceName: "iPhone 16",
      platformVersion: "18",
      isRealMobile: true,
      build: "AWS Device Farm migration check",
      name: "Search - iPhone 16",
      w3c: true
    }
  }
];

async function searchTest(caps) {
  const started = Date.now();
  const driver = await new Builder().usingServer(HUB).withCapabilities(caps).build();
  const sessionStart = (Date.now() - started) / 1000;
  let status = "failed";
  try {
    await driver.get("https://ecommerce-playground.lambdatest.io/index.php?route=product/search&search=iPhone");
    const first = await driver.wait(until.elementLocated(By.css(".product-layout h4 a")), 20000);
    const title = await first.getAttribute("textContent");
    if (!/iphone/i.test(title)) throw new Error("Unexpected first result: " + title);
    status = "passed";
  } finally {
    await driver.executeScript("lambda-status=" + status);
    await driver.quit();
  }
  console.log(caps["lt:options"].deviceName + ": " + status + ", session start " + sessionStart + "s, total " + (Date.now() - started) / 1000 + "s");
}

Promise.all(devices.map(searchTest)).catch((err) => {
  console.error(err);
  process.exitCode = 1;
});

This was the console output from the run on October 8, 2026:

Galaxy S25: passed, session start 31.681s, total 36.106s
iPhone 16: passed, session start 33.817s, total 38.81s

Across three runs on October 8, getting a real device took between 30 and 35 seconds, and the test itself finished in under 10 seconds on both phones. Both devices returned the same search results page:

Compare Results Before You Switch Off AWS

Run your real suite on both platforms for at least one release cycle before you cancel anything. Compare pass rates per device, how long each session waits for a device, and the evidence you get when a test fails, because those are what tell you whether the move saved your team time.

TestMu AI's App Automation dashboard lists each build's sessions with their results, video and logs, which makes that side-by-side review quicker than downloading artifacts job by job.