Share a build

A share link lets someone who is not in your workspace open an uploaded build on a live device. It is the way to hand a build to a client, a stakeholder or an external tester: they open the link in a browser and try the app, and they never sign in or install anything.

The link is the accessCopy Anchor Link

There are two different ideas in SpawnDroid, and it is worth keeping them apart:

• Workspace membership is for your team. A member is invited to the organisation, signs in, and sees the console. Members are a seat on your plan, and they can see the workspace's artifacts and runs.
• A share link is for everyone else. It is an unlisted URL that carries an opaque, random token. The person you send it to needs no account, no invite and no seat. The token in the URL is the whole capability — anyone holding the link can open the build, and no one else can.

So a client does not need a workspace invite, and you should not send one. Inviting a client into your organisation would give them a full member seat, let them see every other artifact in the workspace, and consume a paid seat. A share link is scoped to a single build.

Create a linkCopy Anchor Link

1. Open the artifact and press Share in the header.
2. Choose how long the link should live — 24 hours, 7 days, 30 days, or no expiry — and press Create link.
3. Copy the URL immediately. Only a hash of the token is stored, so the full link is shown once and cannot be recovered later. If you lose it, revoke it and make a new one.

Only workspace admins can create or revoke share links. Any member can see the list of links that exist.

https://app.spawndroid.io/p/shr_1f8c…9b2e

What the recipient seesCopy Anchor Link

The link opens a page with the build's name, version and package. If a device is already running for that build, the visitor joins it. If not, they press Launch live demo and a device starts, installs the build and appears in the page. The first boot usually takes under a minute. There are no device controls and no Logcat — a shared link shows the app, nothing else.

Nothing starts just because the page was opened. A device is booted only when the visitor presses Launch, so a link that gets unfurled by a chat app, an email scanner or a crawler does not consume a runner.

Limits, and how a link stays safeCopy Anchor Link

A share link runs on the workspace's infrastructure, so it is bounded the same way the console is:

• Parallel runners. Starting a device through a link uses one of your plan's parallel runners. If every runner in the workspace is busy, the visitor is told the workspace is busy rather than being served a device.
• No eviction. A link never stops a session a member is running to make room for itself. If you are streaming and a client opens the link, they join the device you already have open.
• Shared, not one-per-viewer. Everyone who opens the same link shares one device for that build; ten visitors do not start ten devices.
• Idle reaping. When nobody is watching, the device host returns the runner to the pool automatically, exactly as it does for a console session.
• A boot throttle. One link can start a limited number of devices in a rolling window, so a public URL cannot be used to churn devices.
• Revocation is immediate. Revoking a link — or letting it expire — stops it resolving on the very next request.

Revoke a linkCopy Anchor Link

Open the same Share dialog. Every link for the build is listed with its status, expiry and view count. Press the trash icon next to an active link to revoke it. Revocation is permanent and takes effect on the next request; the link cannot be un-revoked.

Why not just invite them to the organisation?Copy Anchor Link

Because a link and a seat solve different problems. A seat gives someone ongoing access to your whole workspace; a link gives one person a single build for a limited time. Use a seat for a teammate and a plan for how many you have. Use a link for anyone outside the team.

See alsoCopy Anchor Link

• Quickstart: upload a build and run it in the console.
• Core concepts: workspaces, artifacts, runners and sessions.
• Plans and limits: parallel runners, seats and retention.