Run your suite on a real phone,
from the CI job you already have.
Emulators pass tests that real hardware fails. DeviceRent gives your existing Appium, Espresso or gradle setup a real Pixel 7a to talk to — as a local adb device, with no change to the suite and no device lab to operate.
One command, then your toolchain takes over.
The connector runs a small adb-server on the machine your tests run on and tunnels each adb conversation to the rented phone over an authenticated WebSocket. Your tools point at it through ANDROID_ADB_SERVER_PORT and behave exactly as they would against a phone on a cable.
- npx or Docker
- npx devicerent-connect needs Node 18+. The Docker image needs neither Node nor platform-tools on the host, which is usually what you want inside a CI runner.
- An API key and a rental id
- Both are read from environment variables, so nothing sensitive lands in the job definition. Keys are created from your account page on any active paid plan.
- Serial-pinned access
- The key is exchanged for a short-lived token scoped to one device serial. A ticket for one phone cannot be pointed at another one in the rack.
- adb forward handled for you
- The connector binds the listen port on your machine and tunnels each connection through, which is what lets Appium reach the on-device UiAutomator2 server.
- A hosted Appium endpoint
- On Pro and above there is a hosted Appium server, so you do not have to stand one up next to the runner at all.
- Billed by the minute
- A CI run costs the minutes it holds a device. At the Pro rate that is €0.01 a minute, so a ten-minute suite is ten cents of hardware.
The four things emulators get wrong.
An emulator is an excellent unit-test target and a poor integration one. These are the categories where a green emulator run and a red phone are routine rather than exceptional.
- Sensors and cameras
- Real ISP behaviour, real sensor noise, real permission flows against real hardware rather than a synthetic feed.
- Thermals and timing
- A phone that throttles changes your timings. Race conditions that never surface on a desktop-class emulator surface here.
- Vendor Android
- Stock Pixel behaviour is not the same as an AOSP image, and the gap widens with every OS release.
- Install and startup reality
- APK install, first-run permissions and cold start on real storage behave differently from a virtualised disk.
Automation needs a paid plan. The minutes are cheap.
Creating an automation API key requires an active paid subscription — Plus, Pro, Rent a Slot or Enterprise. Interactive browser sessions do not: those are pay-as-you-go on any account with credit. Plus runs €0.06 a device-minute, Pro €0.01, and a dedicated slot switches the meter off entirely for a device reserved to you.
Where this will not fit your pipeline.
Current facts about the rack and the bridge, not roadmap. If one of these is a requirement, budget for a different tool rather than finding out mid-migration.
- Maestro and Detox are not supported. Appium, Espresso and anything that speaks plain adb are.
- adb reverse is not carried by the bridge today, so suites that depend on it will not run.
- A broad device matrix per release. The rack is six identical Pixel 7a.
- iOS. There is none, and none is planned.
- Root-dependent instrumentation. Every phone has a locked bootloader, verified boot enforcing and no su binary.
- Unattended AI runs on a schedule. DeviceyAI is driven from a live session; triggers and cron runs are not built.
Questions
- Do my tests need changing?
- No. The rented phone appears as a local adb device, so Appium, Espresso and gradle address it the same way they address anything else adb can see. The change is one process running alongside your suite, not a rewrite.
- Which plans include automation keys?
- Any active paid plan — Plus, Pro, Rent a Slot or Enterprise. The hosted Appium endpoint is on Pro and above. Interactive browser sessions need no subscription at all, only credit.
- Can two CI jobs use devices at the same time?
- Yes, up to three devices concurrently per account. A dedicated slot is the better fit if a pipeline needs a device to be reliably free at a particular time, since nobody else can rent that one.
- How is a device cleaned between runs?
- A between-renter wipe is enforced before the device is rentable again and recorded in an append-only trail. The gate is fail-closed, so a phone with no wipe on file is not handed to the next renter.
- What happens if the rack is busy?
- The rental fails rather than degrading. There is no simulated device to fall back to — that mode was removed in September 2026 after it let a live session swap to a fake screen and keep billing.