Publish a Bolt.new App to Google Play: AAB and 12 Testers

Short answer: Bolt cannot make an app bundle, and the build is not the slow part

Bolt.new runs entirely in your browser, so it cannot compile an Android binary. What it hands you is either a published web app at a bolt.host address, or an Expo (React Native) source project if you asked for a mobile app in your first prompt. Google Play needs a signed Android App Bundle instead: "Starting August 2021, new apps are required to publish with the Android App Bundle on Google Play." And if your Play account is a personal one created after November 13, 2023, Google adds a second gate on top of the format: "Developers with personal accounts created after November 13, 2023, must run a closed test for their app with a minimum of 12 testers who have been opted in continuously for at least 14 days."

One trap deserves warning about before anything else. Bolt's own Android instructions tell you to upload to the internal testing track first and then "go to Production" when you are ready. On a new personal account, Production is disabled until the closed-test requirement is met, and the testers you put on internal testing are locked out of your closed test until they opt out. Section five covers the fix, but the short version is: your first upload belongs on the closed testing track.

What does Bolt give you, and which path are you on?

Bolt's help center describes the engine plainly: "Bolt runs on WebContainers, a browser-based technology built by StackBlitz that runs a full development environment directly in your browser." There is no Android SDK, no Gradle and no keystore inside that environment, which is why there is no "Download APK" button and never will be. Everything downstream depends on which of Bolt's two project types you have.

• Web project (the default): what you get is a live URL after Publish — \"Bolt hosts your site for free at a bolt.host address\" — plus a source ZIP on download. Route to Google Play: wrap the URL with Capacitor into an .aab, then closed test it.
• Expo mobile project (you said \"mobile app\" in your first prompt): React Native source, previewable on your phone through Expo Go by QR code. Route to Google Play: eas build --platform android produces the .aab directly — no wrapper.

Bolt is blunt about the fork: "Projects created for web do not easily switch over to mobile." If a Play Store listing was part of the plan from day one, a web project you are now trying to convert is prompt-fighting you for every screen. Starting over with "mobile app" in the first prompt is usually cheaper than the conversion.

Bolt's list of publish targets includes "Android: Google Play Beta (for testing) and Google Play Store (for public access)." "Play Beta" there means Play Console's testing tracks, not a separate store — and which testing track you are allowed to use first depends entirely on your developer account type.

How do you turn a Bolt project into a signed AAB?

On the Expo path, Bolt's own documentation carries you most of the way. The prerequisites are "a computer with Node.js LTS and Git installed", an Expo account, and — for Android — "a Google Play Developer account". Then, in order:

1. Download the code from Bolt and open it in a code editor.
2. npm install -g eas-cli, then eas login with your Expo account.
3. npm install, then npx expo-doctor to catch setup problems before they become build failures.
4. Edit app.json: set the display name and the slug. Both are load-bearing; the slug is permanent after your first build.
5. eas init, then eas build:configure to generate the build configuration.
6. eas build --platform android, then "download the build file (APK or AAB) from the link provided in the CLI".

One more check sits on the build itself, and its deadline has already passed: \"Starting August 31, 2026: New apps and app updates must target Android 16 (API level 36) or higher to be submitted to Google Play.\" An under-targeted bundle is refused at the upload screen, before the testing question ever comes up. A Bolt project scaffolded on an older Expo SDK can come out targeting less, so confirm the API level your build actually produced before you upload.

On signing, Bolt's troubleshooting section says only: "Check that all required certificates are set up in your Apple and Google Developer accounts. EAS can guide you through certificate setup." If this is your first Android build, let EAS manage the keys and keep the account you built from — the signing fingerprint is what ties every future update to this listing.

On the web-project path, the equivalent step is wrapping your bolt.host URL in a native shell. Capacitor is the standard tool, and the build commands are identical to wrapping any other web app — we wrote the full sequence in our guide to publishing a Lovable app to Google Play, and nothing in it is Lovable-specific. Both paths end at the same artifact: a signed .aab you can upload to Play Console.

Which Bolt and Play Console settings can you never change?

Two, one from each side of the handoff, and AI-built projects walk into both because the builder never had a store listing in mind.

• The Expo slug. Bolt's Expo page states it flatly: "You can't change the slug after you create your first build, so choose carefully." Bolt will generate one from your project name; rename it to something you would accept as a permanent identifier before you run the first build.
• The package name. Google's wording is just as final: "Once you upload an artifact, the package name for that app is fixed and cannot be changed." Pick com.yourdomain.appname deliberately, because every update you ever ship has to wear it.

Everything else on the Play Console side — store listing text, screenshots, content rating, countries — can be revised later. These two cannot, which is why they belong in the checklist before the first build rather than after the first rejection.

Why shouldn't I start on the internal testing track like Bolt's docs say?

Because for a new personal account that sequence cannot reach Production at all. Bolt's Android steps are: "Set up internal testing: Go to Testing > Internal testing. Create a release. Upload your build file. Add email addresses of people you want to test the app." — and then "When ready for public release: In Google Play Console, go to Production. Create a release and upload your build." Google's requirement page closes that door: "Google Play requires personal developer accounts created after November 13, 2023, to test their apps before those apps are eligible for distribution on Google Play. Certain features in Play Console, such as Production (Test and release > Production) and Pre-registration, remain disabled until developers meet these testing requirements."

The second half of the problem is what happens to your testers. Google is explicit: "A user who opts into your app's internal test is no longer eligible to receive an open or closed test. To access an open or closed test, the user must first opt out of the internal test and then opt in to the open or closed test." Internal testing time does not count toward the 14 days, and every friend you collect there has to be walked through an opt-out before they can become one of your 12.

The order that works on a new personal account: closed testing track first, 12 testers opted in for 14 continuous days, apply for production access from the Dashboard, then Production. If you have already been turned down at the last step, our breakdown of production access rejections covers the reasons Google actually gives.

What does the 14-day closed test involve for a Bolt app?

The mechanics are the same for a wrapped web app as for any native build — nothing about how the binary was produced changes the requirement. Three details decide whether your clock actually starts.

• The opt-in link needs a published release. Google: "The opt-in link displays only when an app status is 'Published'. Apps in 'Draft' or 'Pending publication' status do not display an opt-in link." And after the first publish, "the test link can take several hours to become available to testers." Testers who try the link in the first hour get a false failure, not a real one.
• Tester lists have documented limits. "You can create up to 200 lists, and each list can contain up to 2,000 users. You can create up to 50 lists per track." For a 12-tester run you will never approach them, but the same list can be reused across your apps — testers still have to opt in per app.
• A Google Group adds a second gate. "Only members of the specified Google Groups can join your test," and "users must join the group before opting into your test." An invited-but-not-accepted member looks identical to an outsider to Play Console.

Engagement is the part that quietly sends Bolt-built apps back for more testing. Google lists "insufficient tester engagement during the testing period" among the reasons it requires a continued closed test. A freshly wrapped web app is exactly the shape that triggers it: testers open it once, recognize a website, and go quiet for the rest of the fortnight. Give testers two or three concrete tasks — create an account, run the main flow, change a setting — instead of "try it out". If your counter reads zero a day after sending invites, why Play Console says 0 testers opted in walks the seven causes in the order we check them.

Will Google accept a website in an app shell?

A web shell of your own site is not automatically a policy problem, but it is not automatically safe either. Google's Spam policy targets a different animal: "We don't allow apps whose primary purpose is to drive affiliate traffic to a website or provide a webview of a website without permission from the website owner or administrator." You own the site, so the permission clause is not your risk. The rule that does apply is in the functionality policy: "We do not allow apps that only have limited functionality and content."

In practice that means the wrapped build should do at least one thing the browser version does not: a real offline screen instead of a dead WebView, local saved state, notifications, native navigation, camera or file access where the app plausibly needs it. Site chrome — headers, footers, "open in browser" banners — should be hidden inside the app rather than shipped as furniture. A reviewer should be able to find things in your app that Chrome on the same URL cannot do.

If your Bolt project shipped with sign-in, the reviewers and testers both need a way in. Add working demo credentials under App content, or expect a stall — we cover exactly what Google's App access section asks for in test credentials for reviewers.

How long does Bolt.new to Google Play actually take?

Roughly three to four weeks for an account the 12-tester rule applies to. Based on our analysis of 1,500+ closed-testing campaigns, the calendar is dominated by the required window, not by the build, and the schedule breaks down like this:

1. Days 1–3: pick the Expo or wrap path, fix the slug and package name, produce and sign the .aab, complete the store listing, privacy policy, data safety form, content rating and target audience.
2. Days 4–17: the closed test itself — release published, opt-in link shared, 12 testers opted in and kept opted in.
3. Day 17 onward: apply for production access from the Dashboard, answer Google's questions, wait for the review outcome.

Two things compress that: starting the closed test before the store listing is finished (the test does not require a finished listing, only a working build and a published release), and recruiting more than 12 testers up front, so a single dropout on day 9 does not restart anyone's count.

Frequently asked questions

Can I publish a Bolt app to Google Play directly from Bolt? No. Bolt publishes to a bolt.host web address or hands you an Expo project; the upload to Play Console, the AAB, and the review all happen outside it.

Do I need Android Studio to publish a Bolt app? Not on the Expo path. Bolt's prerequisites list only "a computer with Node.js LTS and Git installed", an Expo account, and a Google Play developer account — the Android build runs on Expo's build service and you download the finished file. Android Studio is only unavoidable if you hand-build a native shell around a web project.

Does the 12-tester rule apply to my Bolt app? If your Play account is a personal one created after November 13, 2023, yes, and it applies no matter what produced the binary. If your account predates that date or is an organization account, check your Dashboard — the closed test requirement is scoped to new personal accounts.

Will Google reject my app because AI wrote it? No. Authorship is not a rejection category. What gets reviewed is policy compliance, functionality and stability — the same three things a human-written app is judged on.

Can the testers from my internal test become my 12? Only after they opt out of internal testing. Until then they are ineligible for the closed test, and the days they spent on the internal track count for nothing.

Is hosting my app at a bolt.host URL enough to be "on Google Play"? No. Google Play distributes app bundles, not URLs, and an add-to-home-screen prompt is not store presence. The URL is an ingredient in an app; it is not the app.

What to do today

• Decide the path before you build another prompt: Expo project if the Play listing is the goal, web project only if the browser is the product.
• Rename the slug and set the package name before the first build — both are permanent the moment the artifact exists.
• Build the .aab, upload it to a closed testing track, and publish the release so the opt-in link appears.
• Send the opt-in link yourself, ask each tester for a screenshot of their opt-in confirmation, and watch the Dashboard counter rather than your inbox.
• Read the closed testing requirements page once before you start, not after your first rejection.

If recruiting and holding 12 testers for 14 continuous days is the part you cannot spare time for, that is the service we run: daily engagement monitoring and tester recruitment built specifically around this requirement, with plans on the pricing page.