Sauce Labs and the Art of Renting Time

Imagine a hundred tests, each taking a minute. Run them one after another and you have time for lunch. Run them on a hundred machines and, in the ideal case, you barely have time to decide what to eat. Sauce Labs grew out of this change in arithmetic. The work was still necessary. The waiting was negotiable.

That distinction matters to anyone who has encountered a checkout that will not check out. An application can work on the machine that made it and fail on the machine that matters: the customer’s. Sauce Labs sells engineering teams a place to investigate that possibility before a release, and tools to understand failures afterward. Its unglamorous subject is the gap between an intended experience and an actual one. There is quite a business in that gap.

First, the click needed somewhere to go

Sauce Labs began in San Francisco in 2008. Among its founders were Jason Huggins, creator of Selenium, John Dunham, and Steven Hazel. Selenium made browser interactions programmable. A test could navigate a page, enter information, and check the result. The commercial opportunity lay in giving those tests a maintained cloud environment in which to run.

Huggins’s account includes a revealing change of mind. Early Selenium operated through JavaScript inside the browser, which limited what it could control. A print dialog, for example, belonged to the operating system. Watching Simon Stewart demonstrate WebDriver in 2007 persuaded Huggins that this different architecture should become Selenium’s future. The lesson preceded the company: a clever tool still has to meet the world outside its original boundaries.

“If you’ve got 100 tests and they all take a minute to run, let’s get 100 machines.”

Jason Huggins, recalling the idea behind cloud execution

John Dunham supplied the acronym: Selenium Acceleration Using Cloud Execution. SAUCE. A name that sounds suspiciously like something served with lunch was, in fact, an infrastructure proposal.

The phone drawer becomes a service

Today, the product includes desktop browser environments, mobile emulators and simulators, and physical Android and iOS devices. Teams can use public devices or dedicated private pools. Sauce Labs handles device procurement, operating-system updates, and hardware refreshes. The company’s expertise includes keeping that varied infrastructure available and attaching useful diagnostic information to a test run.

Consider a mobile engineer investigating a failure on a particular phone. The Real Device Cloud plugin can put a remote device session inside the code editor, alongside device and network logs. The engineer can install an app, reproduce the problem, inspect the evidence, and try another build. There is still debugging to do. At least the phone does not have to be borrowed from someone who has gone home.

The testing framework remains a separate choice. Sauce Labs supports tools such as Selenium, Appium, and Cypress. Its Cypress documentation describes running existing projects through the saucectl command-line tool and connecting them to CI systems. That is an important part of the proposition: teams can bring familiar automation into a managed environment.

Compatibility deserves a precise reading. The documented Playwright connection through Selenium Grid uses Chrome DevTools Protocol and lists Chrome and Microsoft Edge on supported platforms. A buyer should check the specific framework, browser, and operating-system route their suite needs. A broad platform description is less useful than a working trial of the actual workload.

Walmart had to change the meeting, too

Walmart’s 2018 case study describes manual testing that held deployments to twice a month. Teams used different tools and lacked aligned goals. More testing machines could not settle those disagreements. Walmart developed its own automation platform, established a Center of Excellence, and standardized frameworks and practices. Sauce Labs supplied execution environments and test information within that broader overhaul.

The useful thing to copy is the division of labor. Decide how teams will test and who owns a failure. Buy infrastructure where maintaining it distracts from that work. A company can rent a device cloud and still have departments arguing about whether a red test matters. The case study gives the cultural changes a place in the explanation; procurement should give them a place in the budget.

This is the market Sauce Labs serves: developers, quality-assurance engineers, and DevOps teams whose application requirements extend across browsers and devices. Retailers are a natural example, but its public customer materials also name financial-services, healthcare, and media companies. Their shared concern is whether an important customer action survives the next release.

Read the price in simultaneous clicks

The published entry plans start at $39 a month for Live Testing, $149 for Virtual Device Cloud, and $199 for Real Device Cloud when billed annually. Each entry price buys one parallel test. Plans include unlimited users and testing minutes; enterprise offerings add capabilities such as private devices, support, and AI agents.

Concurrency is the operative word. One slot runs one test at a time. Adding capacity can shorten the queue when tests are independent and ready to run. It does little for a chain of tests that must wait on one another. Buyers should measure the wait in their own pipeline before deciding how much parallel capacity to purchase.

There is also a perfectly respectable case for owning the infrastructure. A small, stable browser matrix and an existing team capable of maintaining a Selenium Grid may make a managed cloud less compelling. Sauce Labs competes with BrowserStack, Perfecto, and TestMu AI, while a self-managed grid remains another route. Its case rests on the combination of execution, diagnostics, device coverage, and enterprise services. Compare those against the workload, rather than awarding points for the longest feature list.

A passed test is only one kind of evidence

Functional automation asks whether an action produces the expected result. Visual testing looks for changes in appearance. Beta distribution puts app builds into users’ hands. These are related inquiries, but they reveal different problems. A button can work while its label becomes unreadable; a scripted journey can pass while an unanticipated journey crashes.

Sauce Labs’s 2021 acquisition of Backtrace brought production error monitoring into the portfolio. Backtrace captures information about faults and their surrounding environment, helping teams group, investigate, and prioritize errors. The reasoning is straightforward: failures after release can show where the next round of tests needs attention.

Partnerships extend that approach. Deque’s axe tools integrate accessibility checks into Sauce Labs workflows. Accessibility expertise and execution infrastructure do different jobs here. Putting them together lets a team gather more evidence within an established process, although a scan still needs someone to interpret and act on its findings.

Now the script is part of the queue

The company’s expansion has had financial backing. It announced $70 million in growth funding in 2016, a $50 million Riverwood investment in 2019, and additional TPG investment in 2022. The 2019 announcement explicitly described plans to move beyond functional testing. The subsequent product portfolio makes that ambition visible.

In March 2026, Sauce Labs announced general availability of AI test authoring: describe intended behavior and generate executable tests, with review and editing built in. In July it launched AURA, short for AI-Unified Release Assurance, connecting authoring, execution, analysis, and feedback. August brought enterprise model choice. These moves address work that renting machines alone cannot eliminate: deciding what to test and interpreting what comes back.

The hardware keeps changing, too. On September 29, 2026, Sauce Labs announced ARM-native virtual Android testing on Google Cloud’s C4A metal infrastructure. Its stated target includes the translation overhead and compatibility constraints of running ARM-based workloads in x86 environments. Even a virtual lab must pay attention to the physical world.

The company publishes ambitious AI performance claims. A team evaluating the service should instead begin with a stubborn journey of its own: signing in, paying, uploading, or recovering from an error. Inspect the generated checks. Run them on the required environments. Measure queue time, diagnosis time, and failures that still escape. An elegant test that checks the wrong thing is an elegant waste of electricity.

Sauce Labs’s enduring idea is useful because it is modest enough to examine. Give necessary work enough machines, enough context, and a place in the release process. Then find the next source of waiting. Software teams can copy that habit whether they buy the service or build their own lab. The customer, meanwhile, would quite like the button to work.