Firebase Test Lab is shutting down. The price change comes first.

After more than ten years on the market, Firebase Test Lab is going away, and every team that runs its tests there has to decide what comes next. In late September 2026, Google marked Test Lab as deprecated and set a full shutdown for September 30, 2027. The consequences are bigger than the date suggests.

Test Lab is being folded into a new Google Cloud product, Developer Device Platform (DDP). The price goes up five months before the shutdown, and any CI pipeline still calling Test Lab stops working when it closes.

Important deadlines

1. Until April 30, 2027: DDP is in preview and matches Test Lab's rates.
2. April 30, 2027: matched pricing ends. Standard DDP rates and per-device subscriptions start.
3. September 30, 2027: Test Lab shuts down.

DDP also requires billing enabled. Google hasn't said whether Test Lab's free daily minutes (60 virtual, 30 physical on Blaze) carry over.

What the new prices look like

From April 30, 2027, emulator minutes cost 3.6x what Test Lab charges today, and physical-device minutes 2.4x.

DDP also offers subscriptions: $200 a month per emulator slot, $250 per physical device slot.

Sources: Firebase Test Lab pricing, Developer Device Platform pricing, Firebase Test Lab deprecation FAQ.

Who pays the most

Teams that run the full suite on every PR. Illustrative example: an Android suite using 2 emulator-hours per run, on 10 PRs a day, is 20 emulator-hours a day.

• On Test Lab today: 19 billable hours after the free daily hour, about $19 a day, or roughly $400 a month over 21 working days.
• On DDP from May 2027: 20 hours at $3.60, about $72 a day, or roughly $1,500 a month.

Same tests, same devices, nearly 4x the cost.

The easy fix is running the suite less often, which is how regressions move from pre-merge to post-merge.

What to check before April 2027

Treat April 30, 2027 as the real deadline.

1. Run your own numbers. Take your monthly physical and virtual device-hours from billing and apply the new rates.
2. Check test-type support. The DDP preview supports Android Instrumentation and iOS XCTest. The migration guide doesn't mention Robo or Game Loop.
3. Plan the CI rewrite. gcloud firebase test android run becomes gcloud beta device-run sessions submit instrumentation.
4. Compare before defaulting to DDP. You're rewriting the pipeline either way.

The time to compare is now, while DDP still costs the same as Test Lab. Run an alternative against your real suite before April, not in a rush in September.

Where Test Lab falls short

For some teams, price isn't the only problem. Test Lab has gaps that push teams to look elsewhere, whatever DDP ends up costing:

• Non-standard devices. Support for wearables and Android TV has been limited, and the devices available haven't always kept up with the libraries and OS versions apps depend on.
• No iOS simulators. iOS tests run only on physical devices, so every iOS run is billed at physical-device rates.
• Run time caps. A single run is capped at 45 minutes on physical devices and 60 minutes on virtual ones.

Our team at Marathon Labs has worked with teams that left Test Lab for exactly these reasons. Peloton, for example, hit a wall when their wearable app needed a Google Mobile Services library that Test Lab's devices didn't support, and the answer from Google was that support might come "someday." You can read how they solved it in the full case study.

What about other solutions?

Teams leaving Test Lab usually look at three options. The right one depends on what your suite actually needs.

Moving to DDP. This is the default path: same vendor, and the DDP preview supports Android Instrumentation and iOS XCTest. You'll still rewrite your CI commands, and from April 30, 2027 you'll pay the new rates above.

Moving to a real-device cloud. If your suite needs real hardware, like cameras, sensors or specific manufacturer builds, vendors such as Sauce Labs or BrowserStack are built for it. But if most of your tests don't depend on real hardware, running all of them on real devices means paying real-device rates and waiting on a fixed number of parallel sessions for every PR.

What we recommend is a hybrid model: real devices for the suites that actually need them, and virtual devices for everything else.

If your main goal is a fast, reliable tool that's painless to migrate to, we recommend Marathon Labs. Marathon runs Android emulators and iOS simulators and sizes the device pool automatically so a suite finishes in about 15 minutes. Failed tests are retried one by one on a different device, so a single flaky test doesn't mean rerunning everything. Setup is one CLI command, and there's a migration guide for Test Lab users.

Marathon is usage-based: $2/hour for Android, $3/hour for iOS simulators, billed per second, no slots. Per-hour rates are only part of it. What matters is total cost and run time on your own suite.

If you want those numbers, the free Test Suite Challenge runs your suite head to head.