Put BetaDrop at the end of your build pipeline
Most pipelines stop one step short. The build compiles, signs, and lands as an artifact in a storage tab someone has to dig out, download, and forward. The useful last step is different: a link a tester can open on their phone. Every integration on this page makes that the thing your pipeline emits: upload the .ipa or .apk, get back an OTA install link and QR code, and testers install from the browser with no accounts and no store review.
The common core is the CLI. It runs anywhere Node.js runs, which gives “which CI do you support?” a short answer: all of them. Two lines turn any job that produces a build into one that distributes it.
npm install -g @betadrop/cli
betadrop publish ./app-release.apk --ci # prints only the install URLIn CI the command authenticates from a BETADROP_TOKEN environment variable. You generate that token once in Settings and store it as a secret.
CI and automation
Start with wherever your builds already happen. Each guide ends with a pipeline that distributes beta builds automatically on every push, tag, or lane run.
Add one step to the workflow that already builds your app. Every push to main, tagged release, or merged PR uploads the APK or IPA and captures the install link as a step output, ready to drop into a PR comment or a release note. Use the packaged Action (uses: betadrop-app/upload-action@v1) or call the CLI directly when you want the step under your own control.
If building and signing already live in your Fastfile, distribution belongs there too. A lane step after gym or gradle shells out to the CLI, so the same lane that produces the binary ends with the link that gets it installed. That holds on your Mac and on every CI that runs your lanes.
Flutter-first CI, so the artifact paths are the ones flutter build produces. A post-build script installs the CLI and uploads the .apk or .ipa, with the token held as an encrypted environment variable rather than a literal in codemagic.yaml.
A Script step after Xcode Archive or Android Build, reading $BITRISE_IPA_PATH or $BITRISE_APK_PATH. Useful if you stayed on Bitrise for the macOS runners but want the distribution half somewhere testers do not need an account.
A deploy stage that picks up the build stage's artifacts and publishes them, with BETADROP_TOKEN as a masked CI/CD variable. Includes the macOS-runner caveat if you are building iOS on GitLab SaaS.
The tool the other integrations are built on, and the right choice when you want no abstraction at all. betadrop publish uploads a build from a terminal or any script; --ci prints only the install URL, and --name and --notes label the build so testers know what changed.
For builds that start in the editor rather than in CI. Connect Claude Code, Cursor, or Copilot to the BetaDrop MCP server and ship a build by asking for it: the assistant uploads the binary and returns the install link without you leaving the conversation.
Connect your AI assistant →Framework guides
Cross-platform toolchains each leave their binaries somewhere different. These guides start from your framework's build command and end at an install link.
One codebase, two binaries. The guide covers where flutter build apk and flutter build ipa leave their output, and how to publish both so Android and iOS testers get their links from the same pipeline run.
For bare React Native projects that build with Gradle and Xcode. Covers assembling a release APK and archiving an IPA, then wiring both into the CLI so even a JavaScript-only change reaches testers as an installable build.
Share a React Native build →EAS Build produces the artifact; BetaDrop distributes it. The guide shows how to take an internal-distribution build out of EAS and hand testers a link that installs without TestFlight or store review.
Distribute an Expo build →Game builds are the heaviest of the lot, and playtesters are rarely developers. This guide covers exporting from Unity for Android and iOS, then sharing a build as a QR code a playtester can scan from the couch.
Share a Unity build →Written for web developers who have never signed a binary. Covers where npx cap sync and the native build actually leave the .apk and .ipa, and the live-reload server URL that ships in a debug build and makes the app look broken on a tester's phone.
Workflows
What to do with the link once the pipeline produces one.
A “Download from BetaDrop” badge for a README or docs page. Point it at a standing link and the same button keeps serving whatever your pipeline published last.
Add a download button for your README →One install URL that stays put while the build behind it changes. The pipeline re-points it on each publish with the Action's standing-link input or the CLI's --standing-link flag.
An install link on every pull request, posted as one comment that the Action edits on each push, so a reviewer installs the branch they are reviewing.
Get pull request builds →Let a coding agent publish the build it just made through the MCP server and hand you back the install link, with what that means for the token it holds.
Read about AI agent app distribution →What a pipeline upload gets you
Authentication is a token, not a password: generate one under Settings → Developer → API tokens and store it as a secret in your CI system. Testers need nothing at all. No account, no companion app, no cable. They open the link or scan the QR code and install from the phone's browser. For iOS, BetaDrop generates the itms-services manifest automatically, and Apple's signing rules still apply: an ad-hoc build installs only on devices whose UDID is in the provisioning profile, and enterprise builds need the one-time trust step.
Links a pipeline creates behave exactly like links created by hand: builds up to 500 MB upload free, a link lives for 3 days by default, and a free account can extend it to 7 days.
When you don't need a pipeline integration
If you cut a tester build once a week, drag-and-drop is genuinely faster than maintaining a workflow file. The upload IPA and upload APK pages take a signed build and return a link in seconds, and your first upload needs no account. Automate when uploading becomes the chore: nightly builds, a link per pull request, or anything you catch yourself doing more than a couple of times a day.
And if your beta program needs public opt-in at scale (a link anyone can use, and thousands of testers you never collect a device id for), TestFlight is still the right tool for that last mile, and the comparison covers where each fits.
Frequently asked questions
Can my CI pipeline upload builds to BetaDrop?
Yes. Any CI pipeline can upload builds to BetaDrop: install the CLI inside the job with npm install -g @betadrop/cli, expose a CI token as the BETADROP_TOKEN environment variable, and run betadrop publish with the path to your .ipa or .apk. Adding --ci makes the command print only the install URL, so you can capture it into a step output, a PR comment, or a Slack message.
Do testers need BetaDrop accounts to install CI builds?
No. Testers install CI builds without any BetaDrop account: every upload produces an install link and QR code, and testers install straight from the phone's browser (Safari on iOS), with no cables and no store review wait. Apple's signing rules still apply to iOS builds: an ad-hoc build installs only on devices whose UDID is in the provisioning profile, and enterprise builds need the one-time trust step. Android APKs install directly once the tester allows installs from their browser.
How do BetaDrop CI tokens work?
Generate a token under Settings → Developer → API tokens on betadrop.app, then store it as an encrypted secret in your CI system. In CI, betadrop publish reads the token from the BETADROP_TOKEN environment variable, so it never appears in your workflow file or your logs. On your own machine, betadrop login --token saves it once instead. If a token ever leaks, revoke it from the same settings screen and issue a new one.
Which CI systems work with BetaDrop?
Any CI that can run Node.js — which in practice is all of them: GitHub Actions, GitLab CI, CircleCI, Bitrise, Codemagic, Jenkins, Azure Pipelines, or a plain shell script on a build machine. There is no per-vendor plugin to wait for, because the integration is the CLI itself: install @betadrop/cli in the job and call betadrop publish after your build step.
Ship your next green build to a phone
Install the CLI, publish the build your pipeline just produced, and send the link.
