Google AI Studio App Works in Preview but Gets 403 After Publishing

You’ve built an app in Google AI Studio. It works in preview, so you publish it, open the live link and try the same feature. Instead of a result, you get a 403 error. Perhaps the page loads but Gemini stops responding. Perhaps visitors can’t open the app at all.

A Google AI Studio app can return 403 after publishing because Cloud Run is rejecting access, the Gemini API is denying a request, or the published application is using different credentials or permissions from preview. Before you generate another key or republish everything, establish which service returned the 403.

Why does Google AI Studio work in preview but return 403 when published?

Google AI Studio publishes full-stack apps to Cloud Run, outside its preview environment. Google documents that the Gemini API key is normally supplied securely to the server-side environment during a Cloud Run deployment.

A 403 doesn’t automatically mean an API key is missing. The deployed service might be private, the API key might lack permission for the resource being requested, or an application component might be sending a request under the wrong identity.

This isn’t a hypothetical distinction. In a Google AI Developers Forum discussion from March and April 2026, several people reported successful previews and failed live Gemini calls. They did not establish one universal cause.

1. Find out which request is actually returning 403

Open the published URL in a private browser window and repeat the failing action. Open your browser’s Network panel and inspect the failed request. Record its URL or host, status code, request method and the error message returned. Never share the full request if it contains a token or API key.

• The entire published page returns 403: investigate the app’s public access, sharing settings or Cloud Run invocation permissions first.
• The page loads, but a Gemini-powered feature fails: identify whether the 403 comes from the Gemini API or from your own backend endpoint.
• Only certain users or protected actions fail: check your application’s sign-in and authorisation rules rather than treating every 403 as a Google deployment problem.
• The browser reports a different status, but the interface says 403: examine server logs. Your backend may be catching an upstream 403 and returning another response to the browser.

The host and response body should determine your next check.

2. Check whether the app is shared, published or privately deployed

Google AI Studio has both sharing and publishing workflows. Don’t assume a shared preview link and a published Cloud Run URL have the same access rules. Google’s Build mode guidance notes that a shared app can show a 403 Access Restricted message because of browser extensions or build issues.

If the actual Cloud Run service refuses the first request, inspect its authentication settings. Cloud Run services can require authenticated callers. A visitor without the necessary invocation permission can receive 403 before your app’s code runs.

Don’t solve that by making every service public. A public frontend may need open access; a private API may not. First confirm what the endpoint is supposed to expose, who should be able to call it and which authentication layer is responsible. Google’s Cloud Run troubleshooting guidance explains the distinction.

3. If Gemini returns 403, investigate the API permission

Suppose the site opens normally, but clicking Generate, Analyse or Summarise produces a failure. The browser request may reach your backend successfully while the backend’s call to Gemini is rejected. Changing public access won’t fix that.

Google’s API error reference identifies a 403 permission-denied response as a request that lacks permission for the resource. Check the error message and credential’s project.

Useful questions include: Is the live application calling the intended API? Does the credential belong to the expected Google Cloud project? Is it permitted to access the chosen model or resource? Has an administrator changed restrictions or project access? Does the error explicitly state that project access has been denied?

Don’t confuse 403 with other failures. Google’s current error guidance distinguishes missing or invalid credentials, depleted payment balance and rate-limit responses from permission-denied errors. Treat the actual status and message as evidence, not interchangeable descriptions of an API problem.

4. Check the deployed secret without exposing it

AI Studio currently documents automatic server-side management of GEMINI_API_KEY for its generated apps, including Cloud Run deployments. So advice from older forum conversations about manually adding keys to every container shouldn’t become your first step. That blanket workaround could create a security problem.

Instead, confirm that the live revision has the intended secret or environment-variable reference, that the application reads the expected variable name and that the server-side code makes the Gemini request. Check for the variable without exposing its value.

If you exported the code as a ZIP and deployed it independently, the setup is different. Google states that you’ll need to configure the server-side key in that hosting environment yourself. Even then, don’t add it to frontend JavaScript or a public repository. If a key has already been exposed, rotate it using Google’s supported process.

5. Compare the working preview with the actual live revision

Before changing code, record the AI Studio project, deployed Cloud Run service, Google Cloud project, region and active revision. Confirm that the public URL points to the service you think you’ve published.

Next, compare the failing feature’s route, the model being requested, the relevant secret reference and the application logs. Look for a specific difference.

Some forum contributors reported problems around deployment revisions and multi-container configurations. User reports are clues, not a diagnosis. A revision might be serving the wrong configuration, or the request might reach Google successfully and then be refused for a separate permissions reason. Check what the evidence actually shows before changing a container or restoring an earlier version.

6. Use Cloud Run logs to separate a blocked request from broken application code

If you have access to the associated Google Cloud project, inspect Cloud Run request logs and application logs around the time of a failed test. Look for the request reaching your application, any outgoing Gemini call and the returned error details.

If Cloud Run denies invocation before your app handles the request, the application log may contain little or nothing about that attempted visit. If your app runs and then Gemini returns permission denied, the application should have enough diagnostic context to show that the upstream operation failed without recording the secret itself.

Save the redacted error and timestamp. Avoid repeatedly republishing just to see whether the failure disappears. Replacing working revisions can make it harder to compare the last good deployment with the first failing one.

7. Avoid the fixes that can make the situation worse

When the app worked five minutes ago, trying another AI prompt is tempting. A 403 may have nothing to do with the frontend code, so asking the builder to rewrite components repeatedly can add unrelated changes without restoring access.

• Don’t paste API keys into prompts, browser code, public issue threads or screenshots.
• Don’t remove key restrictions or grant broad public access simply to make the error disappear.
• Don’t delete a working Cloud Run revision before recording its configuration.
• Don’t rotate several credentials at once; you’ll lose track of which change mattered.
• Don’t migrate databases, rebuild the app or switch hosting until you’ve identified the failing boundary.

Change one thing at a time and retest the same request.

8. What if the problem is on Google’s side?

Sometimes your configuration checks out and the request still fails. Google developer-forum reports include cases where users said valid credentials and different deployments produced the same 403. A community report doesn’t prove an infrastructure incident, but it does mean you shouldn’t promise that changing an environment variable will solve every case.

Check the relevant Google service status and any current support discussions. If the error concerns account-level or project-level access that Google controls, prepare a clear support case with the project identifier, affected service, redacted error, timestamp, first failing revision and steps to reproduce. Don’t publish secret values or customer information.

Where a previous revision is demonstrably working, a controlled rollback may be an option after assessing what else changed, including data and integrations. It isn’t a universal fix, and it shouldn’t be done blindly on a live commercial application.

When is a paid diagnosis sensible?

If you’ve established that the deployed app returns 403 but can’t identify which permission, credential or deployment boundary is responsible, stop making speculative changes. That matters when customers depend on a broken live feature.

For a proper investigation, I’d want the failing URL or feature, the full redacted error, the difference between preview and live behaviour, the deployment method, recent changes and access to the relevant logs where appropriate. That evidence lets me distinguish a repairable application or configuration issue from something requiring Google support.

You can also read my guides to AI apps that work in preview but not live and API calls that work locally but fail after deployment if those broader symptoms apply.

My recommendation: identify the service returning 403, preserve the last working deployment and investigate the exact permission failure before changing anything else. The right fix depends on the evidence, not on how many times you republish.

Need help with a published Google AI Studio 403 error?

If these checks haven’t identified the cause, I can investigate your AI-built app through a paid diagnostic. You’ll get an assessment of what’s failing, the likely cause and what should happen next. Any repair work is quoted separately.