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 phone 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 plan, Free included.
- 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 every plan, Free included, there is a hosted Appium server, so you do not have to stand one up next to the runner at all.
- Hosted Playwright for Chrome and WebViews
- The same key buys a private address for Playwright's _android.connect(), to drive Chrome on the phone and the WebViews in your own debuggable app. JavaScript and TypeScript only — Playwright has no Android support in its other languages — on Playwright 1.64.x.
- 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
- Vendor skins are not the same as each other, and none of them is the same as an AOSP image. The rack runs stock Android 16–17 on the Pixel 7a; One UI on Android 16 on the Galaxy A16 and Galaxy A54; HyperOS 2 on Android 15 on the Redmi Note 13, 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.
No plan required. You pay for minutes.
Automation needs an account with credit on it and nothing else — no subscription, no tier. A run costs €0.10 a device-minute at list, deducted from the same wallet a browser session draws on, and it stops by itself when that wallet reaches zero. A subscription lowers the rate rather than unlocking the door: 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 five Pixel 7a, one Galaxy A16, one Galaxy A54 and one Redmi Note 13.
- 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.
Further reading
Sub-second ADB: how we connect you to a phone over Tailscale
What your CI job is actually talking to when it runs adb against a rented phone.
Rebuilding the session page into an actual workbench
Shell, logcat and the inspector side by side — the interactive half of the same session your suite drives.
The terminal app
npx devicerent rents a phone, installs your APK and runs Espresso from the shell your build already runs in.
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?
- All of them, including Free — automation stopped requiring a subscription on 19 September 2026. The connector and the hosted Appium and Playwright endpoints all need an account in good standing with credit in the wallet, which is the same rule a browser session follows. What a paid plan changes is the per-minute rate those runs are billed at, and the monthly credit that pays for them.
- 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.