Can I run Playwright browser tests in a cloud sandbox?

Yes. The PillDrops playwright template ships Playwright 1.61.1 with chromium-1228 baked in, so a suite installs and runs in seconds against a real Chromium inside a disposable, isolated sandbox — pointed at any URL, from the portal, the CLI, or CI.

Can I run Android mobile tests in the cloud?

Yes. The android template boots a real Android 14 (SDK 34) emulator with adb and appium, runs your script end-to-end, records the whole session, and returns a GREEN/RED verdict with a full evidence bundle.

How do I gate CI merges on browser and mobile tests?

Run `pilldrops test ./e2e/suite.sh` as a step in GitHub Actions. It boots a fresh sandbox, runs the suite, and exits non-zero on RED so the merge is blocked; every sandbox tears itself down afterward.

BROWSER + MOBILE E2E · DISPOSABLE SANDBOXES

Run real browser & mobile tests in throwaway sandboxes.

Playwright driving a real Chromium, and a real Android 14 emulator with adb and appium — booted fresh, run in seconds, torn down after. From the portal, the CLI, or your CI. One command in, a GREEN/RED verdict and full evidence out.

Deploy a template See how it runs →

Validated live on the production fleet · Playwright 1.61.1 · chromium-1228 · Android 14 / SDK 34

pilldrops test ./suite.sh GREEN

$ pilldrops test ./suite.sh
→ booting sandbox … playwright · microVM
→ chromium-1228 baked · @playwright/test@1.61.1
→ running 5 tests …
  ✓ auth + session persists
  ✓ search filters + live re-query
  ✓ long form · upload ×2 · iframe · download csv
  ✓ popup handled as separate page
  ✓ multiple tabs live simultaneously
✓ VERDICT: GREEN — 5/5 passed in 15s · 0 orphans

5/5

Playwright tests passed

GREEN

Android emulator verdict

PASS

cross-platform 2FA flow

4/4

failures recovered

orphan sandboxes

[01] — Capabilities / the full test stack, baked

Real browser, real device,
real evidence.

Every capability below was executed live on the production fleet — a real browser driving our own app, a real Android device, real coordination between sandboxes.

🔒 pilldrops.com

Browser · Playwright

A real Chromium, pointed at your production app

Here it is driving our own app, pilldrops.com. The playwright template ships Playwright CLI 1.61.1 with chromium-1228 baked in — no browser download. A five-test suite ran clean in ~15 seconds, no crashes.

Point it at any URL — staging, a preview URL, or a local app on an exposed port
Session persistence honored across direct navigation to protected pages
Multi-file upload and verified CSV download pulled back to disk
Iframes, window.open popups and target=_blank tabs, all handled
Full trace + video + HTML report bundle, console logs captured

pilldrops.com on a mobile viewport — the app under test, on a phone.

pilldrops.com · mobile

pilldrops test · androidGreen

$ pilldrops test ./mobile.sh
→ AVD boot · Android 14
→ adb + appium · rec ●
  ✓ launch + intent nav
  ✓ permission granted
  ✓ input · scroll
✓ GREEN · video saved

Mobile · Android emulator

A real Android 14 device, scripted end-to-end

The android template boots a Galaxy S10 / Android 14 (SDK 34) AVD with adb, appium and 223 packages — native app automation, plus your web app in a real mobile browser. Through pilldrops test the emulator boots itself, records the whole session, and returns a GREEN/RED verdict.

Your web app on a phone — the same pilldrops.com, mobile layout
Native flows too: intent navigation, app list and fling-scroll at 1440×3040
Runtime permission grant read back off the device: CAMERA: granted=true
Automatic screen recording served in the live report

🔒 pilldrops.com

browser sandbox ⇄ backend ⇄ phone sandboxPass

browser → start login → phone approves
→ txn a3f9…c1 created
  status: pending → approved → LOGIN_COMPLETE
✓ both sandboxes torn down · 0 orphans

Cross-platform

Web and phone, coordinated in one task

Drive two independent sandboxes at once — a microVM browser and a Docker Android emulator — through a shared backend in a single task. In the validated run, Playwright started a push-approval login, the Android sandbox approved it, and the web side polled through to LOGIN_COMPLETE.

Backend transitions observed live: pending → approved → LOGIN_COMPLETE
Real transaction id round-tripped between the two devices
Exactly the OTP, confirmation and push-approval flows QA needs to cover — end to end

CaseInjected failureRecovery

R1Click a selector that doesn't existRetried correct selector ✓

R2Browser context closed mid-flowRelaunched, re-logged in ✓

R31.5s injected network latencyCompleted in 1603ms ✓

R4Forced timeout on missing elementFell back to known page ✓

AI agent · recovery

Detect, retry, fail over — or surface the typed error

The whole validation was planned and executed by an AI agent against high-level objectives: it wrote the specs, drove browser and device across sandboxes, and recovered from real failures mid-run — a port mismatch, a stale server's EADDRINUSE, an expired approval wait.

4/4 injected failures detected and recovered
Where recovery is impossible, the typed Playwright error is surfaced — not swallowed
Every sandbox tears itself down when the run ends — 0 orphans

[02] — How it works / from empty sandbox to CI gate

Six steps, one command,
the same in CI.

The same path whether you start in the portal or the terminal. Each step produces something you can watch or keep.

01 · Pick a template

Choose your surface

playwright for browser, or android / mobile-test for the emulator. Chromium and the AVD are already baked.

02 · Write the test

Bring your spec

Drop in a @playwright/test suite or an adb/appium script — or paste it into the portal editor. No local setup.

03 · Run it

One command

pilldrops test ./suite.sh boots a fresh sandbox, installs deps, and launches the browser or the emulator.

04 · Watch it live

Stream as it goes

Exec output streams back in real time; the emulator run is screen-recorded, and the live report is served on a preview URL.

05 · Get the verdict

GREEN or RED, with proof

A clear verdict plus the evidence bundle: trace, video, screenshots, console logs and any files the test downloaded.

06 · Wire into CI

Gate your merges

The same one-liner drops into GitHub Actions. Block the merge on the verdict; every sandbox tears itself down.

[03] — Get started / portal or terminal

Start from the portal,
or from your terminal.

Same engine underneath. Pick the door that fits how you work — no CLI required to get a real run.

FROM THE PORTAL · NO CLI

A browser is all you need

Deploy a template from the dashboard, paste your spec into the editor, hit Run, and watch the streaming logs — then open the preview URL for the live report and screen recording.

playwrightandroidlive reportevidence bundle

Open the dashboard →

FROM THE TERMINAL · CI

One command locally, the same in CI

$ pilldrops test ./e2e/suite.sh
# → boot · run · record · verdict
✓ VERDICT: GREEN — evidence bundled

github actionsone-linermerge gate

Read the docs →

SHIP THE TESTS YOU'VE BEEN DEFERRING

Get a real verdict
on your next run.

Deploy a template, paste a spec, and watch a live browser or a real Android 14 device run it — then wire the exact same command into CI.

Deploy a template Browse the guides

Real browser, real device,real evidence.