BetaDrop docs
.ipa or an .apk; you get an HTTPS install page and a QR code; the tester installs over the air with no store, no invitation and no account of their own. These pages are the reference for doing that by hand and then automating it.In 30 seconds
There are exactly three ways to publish a build, and they all end at the same place — a build in your account with an install link. In the browser, drag the file onto the IPA uploader or the APK uploader. From a terminal or a CI runner, use the CLI. From an AI assistant that speaks MCP, use the MCP server. The GitHub Action is the CLI with a YAML face on it.
# no account, no install, nothing to configure:
open https://betadrop.app/upload-apk/ # drop the .apk, copy the link
# or, once you have a token:
npm install -g @betadrop/cli
betadrop publish ./app-release.apkNothing above needs an account except the second half, and the free tier accepts a file up to 500 MB. If you have five minutes and a build lying around, the quickstart is the page to read; if you already know what BetaDrop does and want a flag, skip to the reference pages.
The pages
Vocabulary
Six words that appear on every page in this section. Nothing here is BetaDrop-specific jargon for its own sake — each one names a thing you will see in a URL, a dashboard column or a command's output.
| Term | What it means |
|---|---|
| Build | One uploaded binary — an iOS .ipa or an Android .apk — plus the metadata read out of it (app name, version, build number, bundle identifier, icon). A new upload is always a new build; nothing is ever overwritten in place. |
| Install link | The public URL a tester opens, of the form betadrop.app/install/<id> for a signed-in upload and betadrop.app/app/<id> for a guest one. It renders an install page that detects the device and serves the right install mechanism, so the same link works whether it is opened on a phone or forwarded to a laptop. |
| Short id | The 6–12 character token at the end of an install link. It is what the CLI prints, what the Action returns as its install-url output, and the only part of the URL worth storing anywhere. |
| Guest upload | An upload made without signing in. Same install page, same QR code, shorter clock: 24 hours. It can be claimed later by signing in, which binds the existing file to your account — the link keeps working and nothing is re-uploaded. |
| Expiry | When a build stops being installable. Guest links expire after 24 hours; a signed-in build starts at 3 days and a free account can push it to 7 days. Expiry means deletion, not archiving — a scheduled job removes the file from storage. |
| API token | A bd_live_… secret that authenticates the CLI, the GitHub Action and the MCP server. Create one in the dashboard under Settings → Developer → API tokens. It is shown once; store it in a secret manager, never in a repository. |
Getting an API token
Every automated surface — CLI in CI, GitHub Action, MCP server — authenticates with the same kind of secret, so this is the one setup step worth doing before you read any of the three reference pages. In the dashboard, open Settings → Developer → API tokens and create one. The plaintext value starts with bd_live_ and is displayed exactly once.
- Store it where secrets live: a GitHub repository or organisation secret for the Action, your CI provider's secret store, or a password manager for local use. Never a committed file, and never an inline value in a workflow.
- Scope and lifetime are yours to choose. A token can be limited to publishing rather than full access, and given an expiry in days — see the MCP page for the exact fields, since token creation is one of the tools it exposes.
- Working on your own machine, you do not need to handle the token at all:
betadrop loginruns a browser sign-in and stores the credential for you. Tokens are for the places a browser cannot open.
What is not in these docs
Docs are reference. Several things a developer legitimately wants live elsewhere on this site, and pointing at them is more useful than a thinner second copy here.
- Integrations — complete, copy-ready pipelines: GitHub Actions workflows for Gradle and Xcode builds, a fastlane lane, and framework guides for Flutter, React Native, Expo and Unity.
- Security — how uploads are stored, who can reach a link, what deletion means, and the answers a reviewer asks before an unreleased build goes anywhere.
- Free tools — the IPA, APK and AAB inspectors, the signature checker, the provisioning-profile decoder and the UDID checker. All browser-side, none of them require an upload to an account.
- Device-side install failures — "App not installed", "Untrusted Enterprise Developer", an
itms-serviceslink that does nothing — have their own troubleshooting posts, linked from the quickstart at the step where they actually happen.
Frequently asked questions
Do I need a BetaDrop account to distribute a build?
No. Uploading without signing in is the default path and it produces a working install link — that is what the quickstart starts with. The trade is the clock: a guest link lasts 24 hours. Signing in for a free account sets the expiry per build, starting at 3 days and extendable up to 7 days, and gives you a dashboard, download counts and the ability to revoke a link early. A guest upload made before you signed up can be claimed afterwards, which binds the same file to your account rather than re-uploading it.
What files can I publish to BetaDrop?
Compiled mobile builds: an iOS .ipa or an Android .apk, up to 500 MB per file on the free tier. The CLI, the GitHub Action and the MCP server all accept exactly those two extensions and reject anything else before uploading a byte. Android App Bundles (.aab) cannot be installed on a device directly, so they are not publishable — BetaDrop's .aab support is the free inspector tool, not distribution. Static websites are a separate product surface with its own limits.
Is there a public HTTP API I can call directly?
Not a documented, supported one. The published clients — the @betadrop/cli npm package, the betadrop-app/upload-action GitHub Action, and the @betadrop/mcp server — are the supported automation surface, and each of these pages documents one of them. The Action is itself a thin wrapper around the CLI, so anything scriptable from a shell is already reachable. If you need an endpoint the clients do not expose, say so on the contact page rather than reverse-engineering one: undocumented routes carry no compatibility promise.
How do these docs differ from the integrations pages?
The integrations pages are walkthroughs: a complete GitHub Actions workflow for a Flutter or Gradle build, a Fastfile lane with the surrounding context, and the reasoning for why a pipeline is arranged that way. These docs are reference — the commands, flags, inputs and tool names, stated once and exhaustively, with no build pipeline assumed. Read an integration page to set something up; read these to look something up.
