Moving test builds off Loadly: links, settings, scripts and cleanup

Moving test builds off Loadly (loadly.io, run by Pgyer) is a small job in files and a bigger one in habits. Loadly links never expire, so testers and clients may have saved links from months ago, and scripts may call its API from CI. This checklist takes the move in order: what to upload again, what replaces a permanent link, how install settings map, how to swap the script, what to tell testers and how to clean up on Loadly. It uses AppForShare as the destination because that is the tool we make; the first and last steps apply to any target. The short product guide is Move from Loadly.

Loadly details are as read on its home page, help pages and API docs on November 3, 2026.

What moves and what stays

On Loadly	What to do
Builds still in testing	Upload them again
Old builds on permanent links	Delete the ones uploaded with an account; the rest stay on Loadly
Short link per app	A channel link with your own address (Pro and Team)
Password install	Password per build (Free) or per extra link (Pro and Team)
Invite install	Private project with invited testers (Team)
Question and answer install	A password, or one extra link per audience
Install end date	Stop date on the build or an extra link (Pro and Team)
API upload script	The CLI, GitHub Action or fastlane plugin
app/check update calls	The in-app update check per channel (Pro and Team)

Step 1: list what is still in use

Because Loadly links never expire, the list of links out in the world can be long. Before you upload anything, list the builds testers or clients still use: one per app and platform is usually enough. Older builds do not need to move; they need to stop being handed out, which is step 7.

Step 2: upload the builds still in testing

For one or two builds, the web upload box is enough, and a guest upload needs no account. Files up to 150 MB work on Free; larger builds need Pro (2 GB) or Team (4 GB), so check sizes first, since Loadly took 2 GB for free. An Android .aab works with a free account and becomes one APK testers install.

For many builds, or both platforms at once, use the CLI on Pro or Team:

export APPFORSHARE_TOKEN=afs_your_token
npx appforshare init --channel beta
npx appforshare upload --ios-notes "Login fix" --android-notes "Login fix, Android 15"

init finds where your iOS and Android builds land in Flutter, React Native and native projects and writes appforshare.config.json. upload with no file then sends the newest build of each platform in one run (CLI 1.11.0).

While you upload, check each iOS build's profile. Loadly kept the link alive, but an ad hoc build still stops installing when its profile ends. Our IPA inspector shows the expiry date and device list in the browser.

Step 3: replace permanent links with a channel

This is the main change. AppForShare links follow your plan: 3 days without an account, 7 days on Free, as long as you subscribe on Pro and Team. On Free, $2 once keeps one link live for 60 days. Instead of one link per build that never dies, hand out one channel link that never changes.

A channel such as Beta has one link and QR code that always open the newest build you put into it. iPhones get the iOS build, Android phones the Android build. If your Loadly scripts set a short link name per app, pick a matching channel address:

npx appforshare upload app.ipa --channel beta
npx appforshare channel-address acme-beta --channel beta --app com.example.shop

Testers then keep one address, and a bad build can be rolled back by putting the previous one into the channel.

Step 4: map install settings

• Public becomes a plain link, on every plan.
• Password becomes a password per build (Free and up), or a password per extra link so each client has its own (Pro up to 3 per build, Team up to 20).
• Invite only becomes a private project that only invited testers open (Team), with tester groups and install status.
• Question and answer has no direct match. A password does the same job and is harder to guess.
• End date becomes a stop date. Link controls also pause a link or cap its installs (Pro and Team).
• Start date has no match today. Share the link when the build should open, or pause the link and resume it then.

Step 5: swap the API script

A Loadly script posts form data with _api_key and file to https://api.loadly.io/apiv2/app/upload, often with buildPassword, buildUpdateDescription and buildChannelShortcut. Replace it with the CLI and an APPFORSHARE_TOKEN secret from Dashboard, Settings:

npx appforshare upload app-release.apk --notes "Checkout fix" --password "$BUILD_PASSWORD" --channel beta

In GitHub Actions use appforshare/appforshare-action@v1; with fastlane, the fastlane-plugin-appforshare plugin. Both run the same upload and can return the store readiness result, and the CLI can fail the job on a blocked build. If your scripts were written for Diawi before Loadly, the Diawi compatible API takes them with a URL change. If your test build called app/check to look for updates, use the in-app update check: a public JSON address per channel, compiled into beta builds only.

Step 6: tell testers

Send one short message with the channel link and three lines:

• This link always opens the newest build; save it instead of older links.
• iPhone testers: check your device once at the UDID finder and tap Remember this device, so each install page says whether your iPhone is in the build.
• Send problems with the Send feedback button on the install page; screenshots welcome.

Testers need no account. Tester feedback works on every plan with an account, with no SDK. On Pro, each iOS project also has an onboarding link that saves new devices to your list.

Step 7: clean up on Loadly

Old builds on links that never expire keep spreading after you move. Sign in to Loadly and delete the builds you uploaded with your account, starting with any that hold a test server address or an unreleased feature.

Builds uploaded without an account are harder. Loadly's help page on deleting says that apps uploaded without an associated Loadly account cannot be disabled or deleted manually. If one of those must come down, contact Loadly support through its site and give the link. For the future, wherever you host, upload signed in so you keep control of your builds.

What you give up, and what you gain

Said plainly: you give up free 2 GB files, links with no end date, a start date on install windows and the app icon inside the QR code. You gain uploads you can always remove and restore for 7 days, .aab support, install help on the page, feedback without an SDK, store readiness checks on every account build, CI tools and an MCP server, and tester and client tools on Team. The full table is AppForShare vs Loadly, and the reasons people move are in Loadly alternative.

Common questions

Do my Loadly links stop working when I move?

No. They stay on Loadly until you delete the builds there. That is why step 7 matters.

Can I import builds from Loadly?

No. Upload the builds still in testing again. Most teams need only the newest build per app.

Is there a link that never expires on AppForShare?

A channel link stays live while you subscribe on Pro or Team and always opens the newest build. On Free, $2 once keeps one link live for 60 days.