Preview your APK build from GitHub Actions: a running app on every PR

Your workflow already produces the artifact nobody opens — an APK zip attached to a run, downloaded by no one, installed by fewer. Add one step and the same build lands on a cloud phone, with its preview link posted as a PR comment. Review stops being archaeology: the reviewer clicks, the app is running, the feature is either there or it isn't.

Try it with a live device

PreviewAPK is in private beta. Get early access to test your own builds.

The artifact graveyard

CI builds are where good intentions go to be zipped. The APK is the one output that can't be evaluated from a diff, a log, or a screenshot gallery — it has to run. So it doesn't get evaluated: it gets merged on the strength of the code review, and the first run happens in staging, or in a user's hand. The tooling made building automatic and left previewing manual, and manual steps in a pipeline are the ones that quietly stop happening.

The workflow

Store your PreviewAPK API key as a repository secret named PREVIEWAPK_API_KEY, then add a step after your build:

- name: Preview the build
  env:
    PREVIEWAPK_API_KEY: ${{ secrets.PREVIEWAPK_API_KEY }}
  run: |
    curl -o previewapk.py https://previewapk.siteport.site/cli/previewapk.py
    python3 previewapk.py use "Device 1"
    python3 previewapk.py push app/build/outputs/apk/debug/app-debug.apk --run
    python3 previewapk.py links

Pushing to a running device hot-swaps the new build in live; pushing to an idle one attaches it, and --run starts the session. Post the session link from links as a PR comment (the CI recipes include a ready-made comment step with the GitHub CLI) and every reviewer gets the running app, not the zip.

Why the link matters more than the build

Reviewers actually review

A link that opens a running app gets clicked; an artifact gets archived. The PR conversation changes from "LGTM, probably" to comments on the thing itself — the spacing, the flow, the empty state nobody screenshotted.

Agents close their own loop

If an AI agent opened the PR, the same key lets it verify before a human looks: it pushes via the identical CLI in its own environment, drives the app, screenshots the result, and pastes evidence into the PR. The preview link in the comment is then a link to a session that was actually tested — the agent testing loop with a paper trail.

Clients skip the install dance

The same link serves the non-technical stakeholder: no artifact download, no unknown-sources prompt, no "which file do I open." The app, running, in their browser — view-only, so it can be pasted anywhere safely.

One device per project is the usual shape

A device slot is $19/month, flat, unlimited runs. One per project covers the PR loop: builds attach or hot-swap, the preview link never changes, and your README, PR template, and comments can all carry the same URL forever. When the team grows, add devices — the CLI selects per run, so parallel projects never collide.

How PreviewAPK works

  1. Push a build — CLI, API, or an MCP tool call from your agent. The APK attaches to your device.
  2. It boots in seconds on a cloud Android phone and streams to your browser — no SDK, no emulator, nothing to install, on either side.
  3. Drive it, or let your agent drive it — taps, typing, screenshots, UI hierarchy, and the session log, all through the same account.
  4. Hand over the link — every session carries a view-only share link for the human who needs to see it.

One device runs one app at a time, priced flat at $19/month per device with unlimited runs. The agent guide and the docs cover the CLI, API, and MCP in full.

Not on GitHub Actions? The same three commands work in any CI — see the CI recipes — and agents can skip CI entirely with the MCP server.

FAQ

How do I preview an APK built by GitHub Actions?

Add a step after your build job: download the PreviewAPK CLI (one Python file), run previewapk push with your API key stored as a repository secret, and post the session's share link in a PR comment once the run is live. The build boots on a cloud phone; anyone with the link watches it run. The full workflow is on this page, and /docs/ci/ has the annotated version.

Which link should the PR comment use?

The session link (the /v/ link) of the run your workflow just started. Fetch it with previewapk links after the run goes live and comment that. It streams the build view-only while the session runs — and because it dies with the session, the comment always points at the run it belongs to, never at a newer build that quietly replaced it.

Can reviewers drive the app from the PR link?

No — by design. Links only watch; driving requires the owner's portal login or an API key. Reviewers see the real app running and can ask for changes with evidence; teammates with portal access can take over the same session and drive it themselves.

What does it cost to add CI previews?

The workflow step is free; the device it pushes to is a flat $19/month with unlimited runs. Most teams keep one device per project — every PR build hot-swaps onto it while it's live, or attaches while it's off.

Does this work with other CI systems?

Yes — anything that can run a Python file and hold a secret: GitLab CI, CircleCI, Bitrise, Codemagic, Jenkins. The recipes live in /docs/ci/. This page covers GitHub Actions because it's where most of the builds are.