Part of: CI/CD Beta App Distribution
One install link, every build
Every upload normally mints its own install URL, so shipping a build means sending everyone a new link. A standing link is a URL you claim once and re-point at each new build. The people holding it always get your current version, and you never send another link.
An install link
Belongs to one build. It is minted on upload, it stops working when that build expires, and the next build gets a different one. Perfect for a one-off handoff.
/install/?i=Ab3xYz → build #417
A standing link
Belongs to you. You point it at whichever build should be current, as often as you like. The URL never changes, so it can live in a README, a client email or a wiki without going stale.
/install/?i=acmebeta → whichever build you point it at
Both are ordinary over-the-air install links to a tester: they open the URL on their phone and install from the browser. The only difference is who decides what is behind it, and for how long.
How it works
Claim a name once
Pick six to twelve letters or digits — acmebeta, clientqa, nightly. That becomes your URL, and it is yours until you release it.
Point it at a build
From the dashboard, the upload form, the CLI or your CI. The link starts serving that build the moment you do.
Stop re-sending links
Testers and clients keep the URL you already gave them. Ship again, point it again, and they get the new build next time they open it.
Let your pipeline point it
The CLI and the GitHub Action both take the name and point it at the build they just uploaded, so a merge is the whole release process. If the name cannot be used at all — wrong plan, unclaimed, a typo — the run stops before it uploads anything. If the upload lands but the link could not be moved afterwards, you still get that build's own install URL and the step reports the failure, so a green run means the standing link really did move.
betadrop publish ./build/MyApp.ipa --standing-link acmebeta
- name: Publish to BetaDrop
uses: betadrop-app/upload-action@v1
with:
file: app/build/outputs/apk/release/*.apk
token: ${{ secrets.BETADROP_TOKEN }}
standing-link: acmebeta
The older --channel flag and channel: input still work and always will — they are the same feature under its previous name. Setup for fastlane, GitLab CI, Bitrise and Codemagic is on the integrations pages.
What a standing link does not do
The name is doing one job — addressing — and it is worth being precise about the three things people reasonably expect it to do as well.
It does not notify anyone
Re-pointing sends no email and no push, and no installed app updates itself. A standing link is pull, not push: the tester gets the new build the next time they open the URL. If people need to know, tell them.
It does not change access rules
Whatever password, device limit or download limit is set on the build behind it still applies, exactly as it would to that build's own link. A standing link is addressing, not access control.
It does not extend retention
The build behind it still expires on its own schedule — 3 days by default. The link survives; the build does not. Keep publishing to it, rather than buying a longer expiry for one build.
Choosing the name
Six to twelve letters and digits, no hyphens or underscores. Capitalisation shows the way you typed it, but names collide case-insensitively, so AcmeBeta and acmebeta are the same name and only one account can hold it.
A set of generic names is reserved and will be refused, because they shadow real hosts and infrastructure — beta, staging, testing, preview, sandbox, internal, production, download, docs and status among them. Something specific to you or your client works better anyway: it is the URL they will be looking at.
Questions
What is a standing link?
A standing link is a fixed install URL you own — betadrop.app/install/?i=acmebeta — that you point at any build you have uploaded. The build behind it changes every time you ship; the URL never does. That is the whole feature. It is a level of indirection over a normal install link — not a folder, a feed, or a group of testers.
How is a standing link different from the install link I already get?
Every upload mints its own install link, tied to that one build. When the build expires — after 3 days by default — that link stops working, and shipping a new build means sending everyone a new URL. A standing link is claimed once and re-pointed forever, so the person holding it never has to be sent anything again.
Do testers get the new build automatically when I point a standing link at it?
No. A standing link is pull, not push. Pointing it at a new build changes what the URL serves from that moment, but nothing is sent to anyone and no already-installed app updates itself. A tester gets the new build when they next open the link. If people need to be told, tell them — BetaDrop does not email on a re-point.
Does this update an app a tester has already installed?
No. Nothing is pushed and nothing is patched — a standing link only changes which build the URL hands out. The tester installs a whole build, the same way they would from any install link. If you have used Expo EAS Update or Ionic Appflow, those ship JavaScript into an app that is already on the device; this is a different mechanism, and it is why we do not call this a channel.
Can my CI point the standing link at the build it just made?
Yes, and that is the setup it is built for. The GitHub Action takes a standing-link input, and the CLI takes --standing-link <slug> on betadrop publish; both point the standing link at the build they just uploaded. If the standing link cannot be used at all — wrong plan, unclaimed slug, typo — the run stops before uploading. If the upload succeeds but the standing link could not be moved afterwards, you still get the build's own install link, the step reports the failure, and the run does not go green on a standing link that did not move.
What happens when the build behind a standing link expires?
The standing link keeps existing and keeps being yours, but the link serves an expired page until you point it at a live build. A standing link does not extend retention: the build behind it still follows your plan's window — up to 7 days on the free plan and a year on Pro. For a link that lives in a README or on a client's wiki, the fix is to keep publishing to the standing link, not to buy a longer expiry.
If CI publishes to a standing link on every merge, do the old builds pile up?
Yes, and this is worth planning for. Pointing a standing link at a new build does not retire, delete or shorten the one it just left — that build keeps its own install link and keeps counting against your storage quota until its own expiry passes. A nightly standing link on a busy repo is therefore a storage clock as well as a URL. Shorten the expiry on CI builds, or delete the ones you have moved past.
Do I need a paid plan, and what happens if my plan lapses?
Standing links are a Pro and Studio feature. If a paid plan lapses, the split is worth knowing: the standing link keeps resolving, so no link you handed out breaks — but every management action stops immediately. You cannot point it at a new build, rename it, or even release the name, until the plan is active again. Nothing is deleted.
What can a standing link be called, and how many can I have?
Six to twelve letters and digits, no hyphens or underscores. Capitalisation is preserved for display but names collide case-insensitively, so AcmeBeta and acmebeta are the same name. Many of the obvious ones are reserved and will be refused: beta, staging, testing, preview, sandbox, internal, production, develop, download, docs and status among them. Names like acmebeta, nightly or clientqa are fine. An account can hold up to 50 standing links, which is a limit against name-squatting rather than a plan tier.
Can I rename a standing link, or take a name back after releasing it?
You can change a standing link's label — the private name you see in the dashboard — without touching the URL. The slug in the URL is the standing link's identity and is not editable: to change it you release the standing link and claim a new one, which breaks every link already handed out. Releasing a name returns it to the shared pool, and anyone can then claim it, so do not release a slug you intend to reuse later.
Does a standing link let people skip a build's password or device limit?
No. A standing link changes which build a URL resolves to; it does not change what that build requires. Whatever password, device limit or download limit is set on the build behind it applies exactly as it would to the build's own link. A standing link is addressing, not access control.
Can I point the download button at a standing link instead of a build?
Yes, and for anything long-lived you should. A "Download from BetaDrop" badge pointed at one build goes stale the next time you ship; pointed at a standing link it keeps installing whatever that link currently serves, with nothing to re-copy. The embed panel under an install link offers the standing link as the target when one is serving that app.
Stop re-sending links after every release
Standing links are part of the Pro and Studio plans. Everything else about publishing a build — the install page, the QR code, the CLI, the GitHub Action — works on the free plan first, so you can try the whole flow before you need one.
