View all services
Talk to QA Advisor
Browse the Knowledge Hub211 resources
/Tools Library/Sauce Labs
Tools Library · Review and guide

Sauce Labs review: pricing, alternatives and setup

Sauce Labs is a commercial testing cloud for web and mobile apps. It runs Selenium, Appium, Playwright, Cypress, Espresso and XCUITest suites on desktop browsers in virtual machines, Android emulators and iOS simulators, and real phones and tablets, and offers live interactive testing. Sauce Connect tunnels reach private environments, and the results dashboard keeps video, logs and history for each job.

QAble has evaluated this tool and works alongside it. The factual sections are complete; our view is bounded to what we have actually seen rather than a long-term verdict.

last reviewed
13 October 2026
version covered
Sauce Labs cloud with saucectl 0.216 and Sauce Connect 5, October 2026
licence
Commercial

Reviewed by Viral Patel

Co-Founder, QAbleLast reviewed 13 October 2026

At a glance

Sauce Labs at a glance

Official site
Vendor
Sauce Labs
Category
Device clouds
Licence
Commercial
Platforms
Real devices, Browsers, Emulators
Integrates with
Selenium, Appium, Playwright, Cypress, Jenkins
First released
2008
Version reviewed
Sauce Labs cloud with saucectl 0.216 and Sauce Connect 5, October 2026

Verdict

Our verdict on Sauce Labs

Strengths

  • Real devices, virtual desktop browsers, emulators and simulators from one account and dashboard
  • Unlimited users and testing minutes on the self-service plans; capacity is bought as parallel tests
  • saucectl runs Playwright, Cypress, TestCafe, Espresso and XCUITest suites in the cloud with built-in sharding
  • Data centres in the US, EU and Asia, with endpoints documented per region
  • Free accounts for qualifying open-source projects, and a free trial

Weaknesses

  • Sauce Connect 4 is end of life; older pipelines need migrating to Sauce Connect 5
  • Jobs show no pass or fail unless the test reports the result
  • Virtual devices are not available in the US East 4 and Asia South 2 data centres
  • Remote execution adds latency, so timeouts written for local runs need raising

Our take

Sauce Labs is broadly comparable to BrowserStack: real devices, virtual desktop browsers and emulators, a tunnel for private apps, and support for the major frameworks. The differences that tend to decide it are commercial terms, which data centre your data lives in, the private device cloud on the Enterprise plan for organisations that cannot share devices, and whether saucectl’s model of uploading your project to run on Sauce machines suits your Playwright or Cypress suite. QAble has evaluated it rather than maintained a long-running suite on it, so treat this as a bounded take. Run a trial with your own suite, not a demo, and measure stability and wall-clock time across your real matrix. If you are inheriting an older setup, check its tunnel first: Sauce Connect 4 reached end of life on 31 July 2026.

We have evaluated this tool rather than maintained a long-running suite on it, so this is a bounded view rather than a long-term verdict. The rest of this page is factual.

How it works

How Sauce Labs works

Two ways to run: remote sessions and saucectl

For Selenium and Appium, Sauce Labs is a remote WebDriver endpoint: your test runs on your machine or CI agent and opens a session against ondemand.<region>.saucelabs.com, with a sauce:options capability carrying credentials, the job name, build and tunnel. Every command crosses the network. For Playwright, Cypress, TestCafe, Espresso and XCUITest, the saucectl CLI works differently: it bundles the files under rootDir, uploads them, installs any npm packages you list, and runs the framework itself on Sauce Labs machines, sending back results and artefacts. The second model avoids per-command latency, but your test code and its dependencies must work in an environment you do not control.

Virtual and real device clouds

Sauce Labs sells two clouds. The Virtual Device Cloud provides desktop browsers on Windows and macOS virtual machines plus Android emulators and iOS simulators, which start quickly and suit most functional automation. The Real Device Cloud provides physical phones and tablets, for hardware-dependent behaviour, real performance and the exact device a customer reported. They are priced as separate plans. Your data centre matters here: the docs note that virtual device testing is not available in the US East 4 and Asia South 2 data centres, so the region you choose at sign-up shapes what you can run.

Regions, data centres and endpoints

Each account works in one or more data centres: US West 1, US East 4, EU Central 1 and Asia South 2. The data centre decides where tests run and where artefacts are stored, which is the deciding factor for organisations with residency requirements. Self-service and trial users pick a data centre when they sign up; Enterprise customers agree theirs in the contract. Every client setting must agree on it: the WebDriver endpoint, the REST API host, saucectl’s region and the Sauce Connect region. A mismatch is a common reason for jobs that never appear or tunnels that tests cannot find.

Sauce Connect 5 for private apps

Sauce Connect is a proxy you run inside your network. It opens an outbound connection to Sauce Labs and carries traffic from remote browsers and devices back to hosts they cannot otherwise reach, such as localhost or an internal staging server. Version 5 starts with sc run and requires both a tunnel name and a region. Tests opt in by naming the tunnel, through tunnelName in sauce:options or the tunnel settings in saucectl’s config. Shutting the proxy down waits for active jobs to finish, so a CI step can stop it cleanly after the tests.

Strengths

What it does well

saucectl sharding and concurrency

In a saucectl config, each suite names a platform and browser, and concurrency sets how many run at once, up to your account’s allowance. Playwright suites can be sharded by spec or by concurrency, or into a fixed number of shards, so a large suite is spread across Sauce machines without writing a splitting script.

Per-job artefacts and history

Each job keeps a video, screenshots and logs, and jobs can be grouped by build and tagged for filtering in the Test Results dashboard. For Chrome, extendedDebugging records HAR files and console logs, which is what you need when a failure occurs only in the cloud.

Session limits that protect your concurrency

Sauce Labs ends sessions that stop sending commands after 90 seconds by default, and caps desktop test duration at 30 minutes by default and three hours at most. Those limits stop a hung test from holding a paid parallel slot for hours, and they can be tuned per test through idleTimeout and maxDuration.

One platform for adjacent products

Alongside the device clouds, Sauce Labs lists Sauce Visual for visual comparison, Sauce Error Reporting for crash and error data, Mobile App Distribution for beta builds, and Sauce AI products for test authoring and insights. Each is separately scoped and priced; they matter mainly if you want to consolidate vendors.

Official CI building blocks

Sauce Labs maintains GitHub Actions for both models: saucectl-run-action installs saucectl and runs a config, and sauce-connect-action starts a Sauce Connect 5 tunnel for the job. Using the official actions avoids pinning download URLs and keeps credentials as repository secrets.

Pricing

Sauce Labs pricing and licensing

Sauce Labs is commercial, with self-service plans priced per parallel test and an Enterprise tier on quote. The pricing page lists Live Testing for manual work, Virtual Device Cloud for automated and manual testing on virtual desktops, emulators and simulators, and Real Device Cloud for physical devices, each with unlimited users and testing minutes, billed annually or month to month. Enterprise adds AI agents, SSO, a private device cloud and premium support. There is a free trial, and free accounts for qualifying open-source projects.

  • Unit of cost: parallel tests. The self-service plans start at one parallel test, and the feature lists mention 1 to 24 concurrent sessions depending on the plan chosen.
  • List prices on saucelabs.com on 13 October 2026, for one parallel test billed annually: Live Testing $39 a month, Virtual Device Cloud $149 a month, Real Device Cloud $199 a month. Month-to-month billing costs more.
  • Enterprise: price on request, with a private device cloud, SSO, premium support and the Sauce AI agents.
  • Free options: a free trial without published terms on the pricing page, and free accounts for qualifying open-source projects.
  • Hidden costs: CI time spent on remote sessions, a host to run Sauce Connect, and engineering time to migrate tunnels and tune timeouts.

Checked against the vendor’s own pages on 13 October 2026. Pricing changes; confirm on the official site before buying.

Getting started

Getting started with Sauce Labs

Setup, step by step

  1. Note your username, access key and data centre from the Sauce Labs user settings and header.
  2. Export SAUCE_USERNAME and SAUCE_ACCESS_KEY as environment variables.
  3. For Selenium or Appium, point a remote driver at your data centre’s ondemand endpoint with sauce:options.
  4. For Playwright or Cypress, install saucectl, run saucectl configure, and add a .sauce/config.yml.
  5. Report the test result back to the job, then check video and logs in the Test Results dashboard.

Install

# Selenium (Python)
pip install selenium pytest

# saucectl, for Playwright, Cypress, TestCafe, Espresso and XCUITest
npm install -g saucectl
saucectl configure

A first example

# conftest.py: a Sauce Labs session for pytest, based on Sauce's demo-python
import os

import pytest
from selenium import webdriver
from selenium.webdriver.chrome.options import Options as ChromeOptions

# Use the endpoint for your data centre (US West 1 shown)
SAUCE_URL = "https://ondemand.us-west-1.saucelabs.com/wd/hub"


@pytest.fixture
def driver(request):
    options = ChromeOptions()
    options.browser_version = "latest"
    options.platform_name = "Windows 11"
    options.set_capability("sauce:options", {
        "username": os.environ["SAUCE_USERNAME"],
        "accessKey": os.environ["SAUCE_ACCESS_KEY"],
        "name": request.node.name,
        "build": os.environ.get("GITHUB_RUN_ID", "local"),
    })
    driver = webdriver.Remote(command_executor=SAUCE_URL, options=options)
    yield driver
    # Without this, the job shows as complete but neither passed nor failed
    failed = request.session.testsfailed > 0
    driver.execute_script(f"sauce:job-result={'failed' if failed else 'passed'}")
    driver.quit()


# test_login.py
def test_valid_login(driver):
    driver.get("https://www.saucedemo.com")
    driver.find_element("id", "user-name").send_keys("standard_user")
    driver.find_element("id", "password").send_keys("secret_sauce")
    driver.find_element("id", "login-button").click()
    assert driver.current_url.endswith("/inventory.html")

What trips people up first

Jobs that run but say nothing. The first remote test usually works, and then the dashboard shows it as complete rather than passed or failed, because Sauce Labs cannot see your assertions. Send sauce:job-result with passed or failed at the end of each test, as in the fixture above, or use saucectl, which reports results itself. The other early trap is the data centre: an account created in EU Central 1 that points at the US West endpoint, or a tunnel started in one region and used from another, produces authentication errors or tunnels that cannot be found. Check the region in the top right of the web app.

In practice

Using Sauce Labs in practice

Running Playwright through saucectl

saucectl reads .sauce/config.yml, uploads everything under rootDir that .sauceignore does not exclude, and runs each suite on the platform it names. Keep rootDir as small as possible and ignore node_modules, reports and build output, or every run uploads them. Pin the Playwright version to the one in package.json so the cloud matches your local runs, and set concurrency to your account’s allowance or below, since the docs warn that a higher value can lead to dropped jobs. Use shard: spec to spread a large suite across machines. Any params you set, such as browserName or workers, are passed to Playwright as command-line flags and override your playwright.config.

# .sauce/config.yml
apiVersion: v1alpha
kind: playwright
sauce:
  region: eu-central-1        # must match your account's data centre
  concurrency: 5              # at or below your parallel allowance
  metadata:
    tags: [e2e, checkout]
playwright:
  version: package.json       # use the version the project already pins
  configFile: playwright.config.ts
rootDir: ./                   # trimmed by .sauceignore
suites:
  - name: Chromium on Windows 11
    platformName: Windows 11
    shard: spec               # one job per spec file
    params:
      browserName: chromium
      project: chromium
  - name: WebKit on macOS
    platformName: macOS 13
    shard: spec
    params:
      browserName: webkit
      project: webkit
reporters:
  spotlight:
    enabled: true             # prints failed jobs at the end of the run

Wiring it into GitHub Actions

The official saucectl-run-action installs saucectl and runs your config, with credentials from repository secrets and options such as region, concurrency and tunnel name as inputs. Pass GITHUB_TOKEN in the environment, as the action’s README asks, or the action can hit GitHub’s API rate limit when it downloads saucectl. For an application that is not publicly reachable, start Sauce Connect 5 earlier in the job, for example with sauce-connect-action at v3, which supports only Sauce Connect 5, and pass the same tunnel name to saucectl. Keep the pull-request run to one or two suites and run the full matrix on a schedule, since every suite consumes concurrency for its duration.

# .github/workflows/sauce.yml
name: sauce
on:
  pull_request:
  schedule:
    - cron: '0 3 * * *'
jobs:
  playwright-on-sauce:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - uses: saucelabs/saucectl-run-action@v4
        env:
          GITHUB_TOKEN: ${{ github.token }}   # avoids GitHub API rate limits
        with:
          sauce-username: ${{ secrets.SAUCE_USERNAME }}
          sauce-access-key: ${{ secrets.SAUCE_ACCESS_KEY }}
          config-file: .sauce/config.yml
          region: eu-central-1
          concurrency: 5

Moving tunnels to Sauce Connect 5

Any pipeline still downloading the Sauce Connect 4 binary stopped working at the end of July 2026, when Sauce Labs stopped accepting its traffic. The migration is mostly command-line changes: start the tunnel with sc run instead of the bare binary, always pass a tunnel name and a region, and rename tunnelIdentifier to tunnelName in capabilities, since the old name is deprecated. Some SC4 features are gone, including the Selenium relay, the PID file and the readyfile, so scripts that waited on a readyfile need to watch for the Sauce Connect is up message or use the official action instead. The sc legacy command translates an old configuration file to the new format.

Keeping jobs readable and costs predictable

Give every job a name from the test, a build value from the CI run, and tags for the suite and team, so the dashboard can be filtered when something breaks at scale. Report the job result from every test. Keep sessions short: one test per session, no long sleeps, and sensible idleTimeout and maxDuration values so a hung test releases its slot. Concurrency is shared across the account, so agree a budget per pipeline and schedule large matrices outside working hours. Review the platform list against your analytics a few times a year, because every unused browser version in a matrix costs a parallel slot on every run.

Pitfalls

Common pitfalls

Jobs left without a pass or fail status

Why it happens: Remote Selenium and Appium sessions only report what the browser did, not whether your assertions passed, so jobs end as complete and the dashboard cannot show failures.

The fix: Execute sauce:job-result=passed or failed at the end of each test from a fixture or hook, or use saucectl, which reports results itself.

Scripts still built around Sauce Connect 4

Why it happens: Sauce Connect 4 reached end of life on 31 July 2026, and Sauce Labs no longer accepts its traffic. Version 5 also requires a tunnel name and a region and dropped the readyfile and Selenium relay.

The fix: Install Sauce Connect 5, start it with sc run, update capabilities to tunnelName, and use sc legacy to convert an existing configuration.

The wrong data centre in one place

Why it happens: Endpoint, REST API, saucectl region and tunnel region are configured separately. If one points at another data centre, jobs disappear from view or cannot find the tunnel.

The fix: Keep the region in one CI variable and derive the endpoint, saucectl region and tunnel region from it.

Uploading the whole repository on every saucectl run

Why it happens: saucectl bundles everything under rootDir that .sauceignore does not exclude, so node_modules, reports and build output make every run slower to start.

The fix: Set rootDir to the test project, add a .sauceignore, and declare npm dependencies in the config so they are installed on the Sauce machine.

Concurrency set higher than the account allows

Why it happens: The saucectl docs warn that setting concurrency above your allowance may result in jobs being dropped by the server, which looks like random infrastructure failure.

The fix: Set concurrency at or below your purchased parallel tests, and lower it per pipeline if several teams share the account.

Tests killed after 90 seconds of silence

Why it happens: idleTimeout ends sessions that send no command for 90 seconds by default, so a test that waits on a slow back-end process without polling the browser is cut off.

The fix: Poll the browser while waiting, move long set-up out of the session, or raise idleTimeout deliberately for that test rather than globally.

Compared

Sauce Labs alternatives compared

ToolReal mobile devicesDesktop browsersAutomation pricingFree option
Sauce LabsYes, Real Device CloudWindows and macOS virtual machinesPer parallel test, monthly or annualTrial; free for qualifying open source
BrowserStackYes, iOS and AndroidWindows and macOS, incl. real SafariPer parallel test, annual plansTrial; free for open source
LambdaTestYes, iOS and AndroidYes, including a Linux-only planPlans by parallel count, billed annually100 free automation minutes; now TestMu AI
AWS Device FarmYes, iOS and AndroidYes, desktop browser testing via SeleniumPer device minute or unmetered slotOne-time free trial of device minutes

FAQ

Frequently asked questions

What are the best Sauce Labs alternatives?

The alternatives most often weighed against Sauce Labs are BrowserStack, LambdaTest and AWS Device Farm. The comparison on this page sets them side by side on real mobile devices, desktop browsers, automation pricing and free option, and the verdict above says where Sauce Labs is the wrong choice and which of them to pick instead.

Is Sauce Labs free?

There is no permanent free plan for commercial use. Sauce Labs offers a free trial and free accounts for qualifying open-source projects. Paid self-service plans, Live Testing, Virtual Device Cloud and Real Device Cloud, are priced per parallel test with unlimited users and minutes, billed annually or month to month, and Enterprise is priced on request.

Sauce Labs vs BrowserStack: what is the difference?

Functionally they overlap heavily: real devices, desktop browsers, emulators and simulators, a tunnel for private apps, and support for Selenium, Appium, Playwright and Cypress. Sauce Labs runs Playwright and Cypress by uploading your project with saucectl and offers a private device cloud on Enterprise; BrowserStack runs Playwright through its SDK and offers self-hosted desktop grids. Compare pricing, regions and stability with a trial of your own suite.

What is Sauce Connect and do I need it?

Sauce Connect is a proxy you run inside your network so that Sauce Labs browsers and devices can reach applications they cannot reach over the internet, such as localhost or an internal staging server. You need it only for non-public applications. Use Sauce Connect 5: version 4 reached end of life on 31 July 2026, and version 5 requires a tunnel name and a region.

Can Sauce Labs run Playwright and Cypress tests?

Yes, through saucectl. It uploads your project to Sauce Labs, installs the declared dependencies, and runs Playwright or Cypress on Sauce machines across the platforms in your config, with sharding and concurrency controlled from the same file. Results, videos and logs appear in the Sauce Labs dashboard, and the official GitHub Action runs saucectl in CI.

How do I mark a Sauce Labs job as passed or failed?

For Selenium and Appium, execute the script sauce:job-result=passed or sauce:job-result=failed through the driver at the end of the test, typically in a fixture, hook or JUnit test watcher. saucectl-based runs report results automatically. Setting the status is what makes failures visible and filterable in the Test Results dashboard.

Which Sauce Labs data centre should I use?

The one nearest your application and your data obligations. Sauce Labs runs US West 1, US East 4, EU Central 1 and Asia South 2, and the data centre decides where tests run and artefacts are stored. Virtual device testing is not available in US East 4 or Asia South 2. Self-service users choose at sign-up; Enterprise customers agree it in the contract.

Alternatives

Sauce Labs alternatives worth weighing

Resources

Where to go next

Ready

Picking the wrong tool costs more than picking late.

QAble advises on toolchain decisions and then implements them, with engineers who have run these tools on real delivery. Start with a free QA audit.

Talk to QA Advisor