After the One-Click Deploy — Hardening an AI Studio Gemini App on Cloud Run for Real Production Use

Check 2: Is That URL Open to Literally Everyone?

The whole point of a one-click deploy is a URL you can try immediately, so the service is almost certainly deployed with unauthenticated access allowed. That's fine for showing a prototype around. But every request to this app triggers a Gemini API call, which costs money. An unauthenticated public URL is a counter where strangers can spend your tokens on your card.

If the audience is you and a handful of people, switching to Cloud Run's IAM authentication is the shortest path:

# Close unauthenticated access
gcloud run services update my-genai-app \
  --region=asia-northeast1 \
  --no-allow-unauthenticated
 
# Grant invoke rights only to people who should call it
gcloud run services add-iam-policy-binding my-genai-app \
  --region=asia-northeast1 \
  --member="user:teammate@example.com" \
  --role="roles/run.invoker"

Callers then pass an identity token; a quick smoke test looks like this:

curl -H "Authorization: Bearer $(gcloud auth print-identity-token)" \
  https://my-genai-app-xxxxxxxx-an.a.run.app/api/generate

If the app is meant for the general public, IAM won't cut it — you'll need application-level auth (Firebase Authentication or similar) plus rate limiting before opening the door again. The exact answer depends on the product, but the failure mode to avoid is the quiet one: "it stayed publicly open and I only noticed weeks later." Close first, then decide how to open.

Check 3: Decide the Cost Ceiling Before Traffic Decides It for You

A Gemini app's bill has two floors: Cloud Run execution costs and Gemini API token costs. The one that grows while you're not looking is the second, so cap both.

On the Cloud Run side, make the scaling limits explicit. For prototype-level traffic I start deliberately conservative and raise limits only when something real demands it:

gcloud run services update my-genai-app \
  --region=asia-northeast1 \
  --max-instances=2 \
  --concurrency=20

On the Gemini API side, Project Spend Caps let you set a monthly dollar ceiling per project. If a key leaks or a loop runs away, the blast radius becomes a fixed number — the fact that things stop at the cap is exactly the insurance you want. I wrote about pairing the hard cap with an app-side soft limit in Stopping Runaway Costs Twice: Project Spend Caps Plus an App-Side Soft Limit.

One more trade-off worth knowing as a number: cold starts. My Node-based containers typically answer their first request from idle in about 2–4 seconds. If that bothers you, --min-instances=1 keeps an instance warm — and bills you for the idle time. For a freshly promoted prototype I usually skip it and accept that the first request is slow.

Check 4: Take Ownership of the Generated Code

Right after a one-click deploy, the source of truth is the artifact inside AI Studio — not your repository, not your CI. Left alone, the service keeps living while nobody can quite say where the next change happens or who deployed what, when.

The fix is mundane: export the code, commit it to your own repository, and make source-based deploys the only path forward.

# Redeploy the same service from your own source tree
gcloud run deploy my-genai-app \
  --region=asia-northeast1 \
  --source=. \
  --no-allow-unauthenticated

Deploying to the same service name creates a new revision, so the URL and settings carry over. From then on, a GitHub Actions job running that command from main turns the one-click deploy into what it should be: the scaffolding for the first day, nothing more.

This is also the moment to spend thirty minutes actually reading the generated code. You don't need to understand all of it, but two things are worth verifying: which model name it calls Gemini with, and whether there is any retry or timeout handling at all. A hard-coded preview model name means a guaranteed future outage when that model is retired. I covered how to defend automation against this class of quiet platform breakage in Preventing Automation That Dies Silently — Preflight Gates for Gemini Platform Changes.

Check 5: Observability — Being Able to Answer "Is It Working?" with Numbers

Last, observation. Cloud Run picks up JSON written to stdout as structured logs, so even a single log line per Gemini call changes how much you can see:

import json, time
 
def log_generation(model: str, resp, started: float) -> None:
    """Emit one structured log line per Gemini call.
    Searchable and aggregatable as jsonPayload in Cloud Logging."""
    usage = resp.usage_metadata
    print(json.dumps({
        "severity": "INFO",
        "message": "gemini_generation",
        "model": model,
        "input_tokens": usage.prompt_token_count,
        "output_tokens": usage.candidates_token_count,
        "latency_ms": int((time.time() - started) * 1000),
    }))

The expected output is one line like this:

{"severity": "INFO", "message": "gemini_generation", "model": "gemini-flash-latest", "input_tokens": 412, "output_tokens": 380, "latency_ms": 2150}

With that in place, "how did token consumption move month over month" and "when exactly did latency degrade" become questions with numeric answers. Working solo, with no dedicated on-call rotation, I've found that log-based metrics plus two alert policies — error rate and latency, nothing fancier — are the cheapest reliability I can buy.

The Checklist, Side by Side — and When to Rewrite Instead

Here is the whole pass, initial state versus hardened state:

Sometimes, partway through this hardening pass, the honest conclusion is that rewriting beats adopting. My two criteria: I rewrite when the request boundary — input validation and output shaping — cannot be read out of the code, and when the app depends on a preview-only feature with no visible replacement. If the code is merely verbose but its boundaries are legible, lifting it into operation first and refactoring gradually has been faster and more stable for me every time. If you'd rather design a Gemini API server on Cloud Run from scratch, Gemini 3.1 Pro × Cloud Run: Building a Serverless AI API for Production walks through that architecture.

If you do one thing today, run gcloud run services describe against the service you have right now and read the environment variables and access settings with your own eyes. Every check in this list starts from there. I hope it gives you a solid starting point the next time a prototype suddenly asks to become a product.