THE WORLD IS NOT STANDING STILL.RSS
BIG CHANGE.
BIG CHANGE, one tap away
BIG CHANGE, one tap away

Make room for the big picture.

Add BIG CHANGE to your home screen or desktop. It opens in its own window, with the latest stories when you’re online.

iPhone & iPad
Open bigchange.ai in Safari. Tap Share, then Add to Home Screen. Turn on Open as Web App if shown, then tap Add.
Android
Open bigchange.ai in Chrome. In the browser menu, choose Install app or Add to Home screen.
Desktop
In Chrome or Edge, use the install icon in the address bar or the browser’s app menu. In Safari on Mac, choose File → Add to Dock.

Markdown edition

# Build and release a Google AI Studio web app on Cloud Run

> Start from an approved app brief, inspect AI Studio's generated code, test optional Firebase and access rules, then verify a Cloud Run release.

By BIG CHANGE Editorial

Published: 2026-10-22T04:21:38.072Z
Updated: 2026-10-22T04:21:38.072Z
Canonical: https://bigchange.ai/blog/google-ai-studio-build-cloud-run-web-app-guide

![Conceptual charcoal illustration of one person holding a landscape tablet with a nearly blank, unbranded web-app surface.](https://bigchange.ai/api/media/file/ai-studio-cloud-run-app-review-hero-v2.png)
AI-generated conceptual illustration by BIG CHANGE.

Google AI Studio can turn an app description into a web frontend, a Node.js server and a working preview. Its Publish flow can then deploy that app to Cloud Run. Between those two steps, the owner still has to inspect the generated code, test the intended task and decide who may use the live service. Google says a Cloud Run deployment gets a public URL and uses the owner's Gemini API key for every user's Gemini calls. [Build mode](https://ai.google.dev/gemini-api/docs/aistudio-build-mode) and [deployment](https://ai.google.dev/gemini-api/docs/aistudio-deploying) documentation describe the path; this guide has not run an app or an account through it.

This is for an owner who has a real, approved web-app task and can authorize its data, costs and release. Start with the actual brief, not a made-up demonstration. Finish only when the reviewed revision has passed its task and access checks at the live URL, with the release decision and usage recorded.

## The big change

- **What changed:** AI Studio's documented Build route joins generated web client and server code, optional Firebase, and direct Cloud Run publication. An owner can take one approved brief through that route without moving the app to another host. Publish produces a public URL.
- **Why it matters:** Deployment sits in the workspace where the app was generated, but the release decision still belongs to the owner. The generated server can handle data, and every live user's Gemini calls use the owner's key. Access and usage therefore determine who can use the service and what it costs.
- **What to watch:** The boundary for a restricted service is effective access at the public endpoint. Private AI Studio project sharing controls collaboration; an app sign-in screen alone does not establish host or data authorization. The actual account tier, allowed and denied live checks, and usage readback decide whether a particular release fits its audience and budget.

## Prepare the brief and account

Write down the intended users, the input they may provide, the output the app must return, and the actions it must allow. Add permitted test data, a known expected result, a failure case and any device or accessibility requirements. Decide what data may be sent to AI Studio or Gemini. If the task involves restricted users or records, name who should be allowed and who should be denied. The owner needs authority to use the account, approve those inputs and accept a specific release.

Check Build mode in the intended AI Studio account and choose a **web app** in the platform picker. Google also offers Android generation, which is a different publishing route. Check the available deployment tier on this account before planning a release. Google's [deployment guide](https://ai.google.dev/gemini-api/docs/aistudio-deploying) says eligible Starter Tier accounts can deploy at most two services without setting up billing; a Workspace account, current or past paid Cloud billing, or insufficient account activity can rule it out. Standard deployment requires a Google Cloud project linked to AI Studio with billing enabled. The person who approves the release should check the account's actual eligibility, remaining service capacity, quotas and charges. Gemini API usage, optional Firebase use and Cloud Run hosting have separate limits and possible costs; a Starter Tier label does not settle all of them.

## 1. Generate the web app from the real task

Open [AI Studio Build mode](https://aistudio.google.com/apps) and enter the approved brief: intended users, allowed data, inputs, expected outputs, key interactions, error behavior and acceptance checks. Tell Build to use a web app. You can ask it to propose a plan first and review whatever it returns, but Google's documentation does not promise a separate plan-approval control. Do not submit restricted data merely to see whether the prompt works.

Run generation and note the app revision and the files it produced. Google's [Build documentation](https://ai.google.dev/gemini-api/docs/aistudio-build-mode) describes a live preview beside the generated files. Treat that preview as a place to inspect and test the app, not evidence that the real task has passed.

## 2. Inspect the generated source and its data path

Open **Code** in the preview pane. Trace each user input from the browser through any server route to a model, external service or storage, then back to the displayed output. Inspect the client and Node.js server files, installed packages, model calls, network destinations, error paths and any generated permissions. Check that the app does only what the approved brief permits. Record the revision you inspected; a later Build chat edit changes the thing you must review.

For a new web app using Gemini, Google says AI Studio configures `GEMINI_API_KEY` as a server-side secret, visible in **Settings → Secrets**, and makes Gemini calls from the server. Confirm the actual generated code follows that path. A secret must not be hardcoded in browser code, source files or displayed responses. Add any approved third-party key through Secrets and inspect where server code uses it. AI Studio's [full-stack guide](https://ai.google.dev/gemini-api/docs/aistudio-fullstack) documents the server runtime, packages and Secrets; it does not certify each generated dependency or data flow.

If another person needs source access, AI Studio documents GitHub sync and ZIP export. Check the exact revision and repository permissions before using either route. Source control can help maintain the app, but AI Studio's direct Cloud Run path does not require a GitHub setup first.

## 3. Add Firebase only when the task needs it

If the brief requires records to survive a session or users to sign in, ask Build to add the relevant [Firebase integration](https://ai.google.dev/gemini-api/docs/aistudio-fullstack). Google documents Firestore for persistent data and Firebase Authentication for Google sign-in. Inspect which project was provisioned, what collections and fields the app uses, how identity reaches server and database operations, and the effective access rules. Have the owner approve the real data to be stored and its retention and access policy.

In the preview, test an allowed read and write with permitted data and a denied read or write from an identity that should not have access. Reload or start another session to check persistence when it is required. A sign-in screen alone does not prove that another user's records are protected, and it does not restrict who can reach the Cloud Run host. If the brief needs neither persistence nor sign-in, record that choice and leave Firebase out.

## 4. Test the actual task in preview

Enter representative permitted input and compare the result with the brief's expected output. Repeat the task after a reload when retained state matters. Test missing or invalid input, a failing service path, and the defined error message. Check the layout and interaction on the devices named in the brief, including keyboard use if that is required. For restricted users or records, run both allowed and denied cases. Record the input, expected behavior, observed result and revision for each check; mark an unrun check as unrun.

Use Build chat or a direct Code edit to fix a failed case. Review the changed files and rerun every affected check. Google's Build page describes both edit routes. A plausible screen or a generated claim of successful execution does not replace the owner's observed result.

## 5. Make a release decision before Publish

Review the exact revision, dependencies, secret placement, data permissions, test results, target audience, deployment tier, service capacity, expected usage and billing exposure. AI Studio projects are private by default and can be shared with named people, who may view and fork their code. That sharing setting does not make the deployed Cloud Run endpoint private: Google describes a **public URL**. Application sign-in controls an app's behavior; effective hosting access and authorization to each protected operation need separate checks.

If the app handles restricted data or is meant only for a restricted audience, establish the effective hosting and application controls approved for this specific account and verify that an unauthorized viewer cannot reach protected functions or data **before** publication. If those controls cannot be established and checked, withhold the restricted app. The owner should then explicitly approve the particular revision, audience, tier and cost exposure. This decision is a release gate, not a request for AI Studio to judge whether the app is safe.

## 6. Publish and verify the live service

Use **Publish** in Build only after that decision. Google's published **Starter Tier** sequence is **Publish → Get Started → Publish App**; follow the controls actually offered in the reader's account for its eligible tier rather than assuming the same screens for standard deployment. The [deployment guide](https://ai.google.dev/gemini-api/docs/aistudio-deploying) says AI Studio returns a Cloud Run URL when deployment completes. Record that URL, the service identity, the reviewed app revision and the tier. If Publish times out or returns an uncertain result, read back the AI Studio app and corresponding Cloud Run service before trying it again; avoid an unexamined duplicate release.

Open the live URL as an intended viewer and repeat the core task, invalid-input and error checks. Where restrictions are required, open it as a denied viewer too, and try the protected operations and data paths, not merely the sign-in screen. Check persistence from a fresh session if the task needs it, and confirm mobile and desktop behavior at the live URL. Read the actual usage, quotas and billing after release. Google says the deployed app uses the owner's key for all users' Gemini calls, so unexpected public use has a cost path even when the key itself remains server-side.

If a live task or access check fails, follow the owner's approved route to restrict or unpublish the service, then repair the affected source or rules and run a new review before another release. If generation, Firebase setup or preview fails earlier, inspect the specific error and configuration, make a bounded correction and rerun the failed acceptance check. Do not loosen access rules to make a demo pass.

## Sources & further reading

- [Build apps in Google AI Studio](https://ai.google.dev/gemini-api/docs/aistudio-build-mode), Google AI for Developers, updated 20 October 2026. Documents web generation, Code and preview, server-side key handling, sharing, GitHub sync and the public Cloud Run URL.
- [Develop full-stack apps in Google AI Studio](https://ai.google.dev/gemini-api/docs/aistudio-fullstack), Google AI for Developers, updated 20 October 2026. Details Node.js, Secrets, optional Firestore and Google sign-in.
- [Deploying from Google AI Studio](https://ai.google.dev/gemini-api/docs/aistudio-deploying), Google AI for Developers, updated 28 September 2026. Sets out Starter eligibility, the two-service limit, standard billing requirements and the documented Publish path. Account availability and prices require a fresh check at release.

## Sources

- [Build apps in Google AI Studio](https://ai.google.dev/gemini-api/docs/aistudio-build-mode)
- [Develop full-stack apps in Google AI Studio](https://ai.google.dev/gemini-api/docs/aistudio-fullstack)
- [Deploying from Google AI Studio](https://ai.google.dev/gemini-api/docs/aistudio-deploying)