Firebase App Distribution limits in 2026: 2 GB, 500 testers, 150 days
· 7 min read
Firebase App Distribution costs nothing, and its limits are generous for most teams. They still catch people out: a release that vanished from the tester page after five months, a QA vendor that pushed the project past 500 testers, an invitation that quietly expired. This guide lists every published limit, what each one means in practice and how to plan around it. All Firebase figures come from the official documentation as read on November 2, 2026, with the source linked next to each.
All the limits in one table
| Limit | Value | Source |
|---|---|---|
| Maximum file size | 2048 MiB for all binaries, "a little over 2 GB" | Troubleshooting |
| Testers per Firebase project | 500 | Add and remove testers |
| Testers per group | 200 | Same page |
| Raising the tester limits | A no-cost limit increase on request | Same page |
| Release lifetime | Removed when older than 150 days | Troubleshooting |
| Releases per app | 1,000; the oldest above the limit are deleted automatically | Same page |
| Invitation acceptance | 30 days; a notice appears 5 days before expiry | Same page |
| Invitation use | Can only be accepted once | Tester setup |
| App Testing agent (preview) | 200 AI-guided tests per month per project at no cost; 5 minute timeout per test | App Testing agent |
| Price | App Distribution is listed as no-cost | Firebase pricing |
2 GB file size
The 2048 MiB ceiling applies to IPAs, APKs and AABs alike. Very few test builds come near it, but games with bundled assets can. If an iOS upload fails within the limit, Firebase's troubleshooting page points at a specific cause: a CFBundleDisplayName in Info.plist written as an array, which App Distribution does not accept. Remove the array delimiters and rebuild. For IPAs that really are over the limit, Firebase suggests contacting support and asking about TestFlight.
500 testers per project, 200 per group
These two caps are separate. A project can hold 500 testers, and any one group can hold 200. So a project with three groups of 200 would hit the project cap before the third group is full.
What to do about it:
- Remove testers who left. Testers are counted per project, so old contractors and past beta users take up places. The REST API has
testers.batchRemovefor bulk cleanup. - Use groups for releases, not for storage. A group decides who gets which release; removing someone from a group does not free a project place.
- Ask for the increase. Firebase states that the increase is free. Ask before a public beta, not during it.
- Consider a public track for large betas. Hundreds of outside testers is often better served by TestFlight public links or Google Play open testing, which are made for that size.
150 days, then the release is gone
Every release appears in the dashboard for 150 days from upload. Thirty days before that, a notice appears in the console and in the tester web app. After it, the release is removed from both. Firebase is clear that "if your tester has installed the release, the local version of the app continues to run," so nothing breaks on phones. What breaks is reinstalling: a tester who deletes the app, gets a new phone or joins late cannot get that build any more.
Firebase's own workarounds:
- Before the release expires, download the IPA, delete the release and upload it again as a new build. The clock starts over.
- Download the release and archive it in Cloud Storage.
For most teams the practical answer is to keep build artifacts in CI, where you already have them, and treat Firebase as the delivery step. If a client needs a reference build that stays installable for a year, plan for it at the start.
1,000 releases per app
High frequency CI, such as one build per merged pull request, can reach 1,000 releases. At that point App Distribution deletes the oldest ones above the limit. To control what goes, the REST API can list and delete releases in bulk (releases.batchDelete).
Invitations expire after 30 days
A tester has 30 days to accept. Five days before expiry the console shows a notice next to the tester on a release, and you can renew by resending from the drop-down on the tester row. Two related rules from the docs are worth knowing:
- An invitation can be accepted once, with any Google account unless you turn on "Restrict invitation acceptance to recipient's email".
- A tester who never accepted the first invitation does not get release emails for later builds you add them to. Resend the invitation rather than adding them again.
When an upload does not create a release
This is not a numeric limit, but it behaves like one. For iOS, if you upload again without changing the version, the build number or the code, App Distribution does not create a new release and does not notify testers. If a build with the same version and build number was already distributed, only newly registered devices get emails. See register additional devices.
Limits that are not Firebase's
- Apple's device limit. Ad Hoc builds need each UDID in the profile, and Apple allows 100 devices per device type per membership year. Firebase notes the yearly limit in its UDID export steps.
- AAB requirements. To distribute AABs, the Firebase app must be linked to the matching app in Google Play. The troubleshooting page lists the conditions: Owner or Admin access in Play, Owner or Firebase Admin in Firebase, the same package name, and an app that has been reviewed and published on a Play track. Testers also turn on Internal app sharing in the Play Store app once.
- Cloud Functions for alerts. Sending new device or feedback alerts to Slack, Discord or Jira is done with Cloud Functions, which requires the Blaze plan (collecting feedback).
- Google accounts. Every tester needs one to accept, install and send feedback. See Firebase App Distribution without a Google account.
The App Testing agent quota
The App Testing agent is a preview feature for Android. You write test goals in plain language and Gemini drives the app. During the preview the default quota is 200 tests per month per project at no cost, and each test case on each device counts as one test: two cases on two devices is four tests. Tests time out after 5 minutes, and the agent cannot see screens protected with FLAG_SECURE. Contact Firebase support for a higher quota.
How AppForShare's limits compare
AppForShare is not free above the Free plan, and its Free plan is smaller than Firebase in two ways that matter: files up to 150 MB, and links that last 7 days. The paid plans are built around links that stay live.
| Firebase App Distribution | AppForShare Free | AppForShare Pro ($12/month) | AppForShare Team ($39/month) | |
|---|---|---|---|---|
| Max file | 2 GB | 150 MB | 2 GB | 4 GB |
| How long a build stays installable | 150 days | 7 days | While subscribed | While subscribed |
| Tester sign in | Google account | None | None | None; invited testers confirm by email link |
| Nudging testers | Resend an invitation before it expires | n/a | n/a | Per tester status and reminder emails |
| Bandwidth | No limit stated in the docs | 10 GB a month | 40 GB a month | 150 GB a month |
Pro and Team also add things Firebase does not have: channels with a stable link that always opens the newest build, install link controls (pause, stop date, install cap) and a store readiness check on every upload. Firebase has things AppForShare does not: device specific APKs from an AAB through Play, Crashlytics stability data and the App Testing agent. See pricing for every limit and the comparison page for features side by side.
Common questions
Does Firebase App Distribution cost anything?
The Firebase pricing page lists App Distribution as no-cost. Costs can come from related products, such as Cloud Functions on Blaze for alert routing.
What happens to installed apps after 150 days?
They keep working. Only the release in the dashboard and the tester web app is removed, so testers cannot install it again.
Can I get more than 500 testers?
Yes. Firebase offers a no-cost limit increase on request.
Why did my tester not get an email for the new build?
Common causes: they never accepted the first invitation, the email went to spam, they accepted with a different address, or the upload did not create a new release because the version and build number were unchanged.
