Google Cloud Integrations
Recipe Box is written, tested, agent-extended, and review-gated. One step remains in the lifecycle from G00: deploy. This module shows how Gemini Code Assist extends into Google Cloud — and puts your API on a public URL.
One Assistant Across the Whole Stack
Think of a hotel concierge versus six different help desks. In most companies, the coding助手 helps you code, then you walk to a different "desk" for deployment (DevOps wiki), another for the database (the SQL guru), another for analytics — each with its own queue and its own jargon. The pain is the handoff: every desk transition loses context and an afternoon. Gemini for Google Cloud is the concierge model: the same assistant identity follows you from the IDE (writing code) to the Cloud console (deploying it) to BigQuery (querying its data), with context appropriate to each room. You learned its personality in G01–G09; this module just walks it into new rooms.
Gemini Code Assist Standard/Enterprise includes integrations across Google Cloud surfaces. From the IDE, the headline is the /deploy smart command (deploy the current app to Cloud Run from chat). In the Cloud console and product UIs, Gemini appears natively inside Firebase, BigQuery, Colab Enterprise, Database Studio — and on Enterprise, Apigee and Application Integration. The unifying idea: your Code Assist license is also your AI key to the cloud tooling.
The Integration Map
🚀 Cloud Run (today's lab)
Serverless containers: give it source code, get a public HTTPS URL that scales to zero. The IDE's /deploy command targets it directly.
🔥 Firebase
Gemini in Firebase assists app development — explain crashes, generate rules, query docs — inside the Firebase console.
Standard • Enterprise📊 BigQuery
Gemini in BigQuery writes and explains SQL, suggests transformations, and helps explore datasets — natural language to query and back.
Standard • Enterprise🗃️ Database Studio & Colab Enterprise
SQL assistance in Cloud's database editor; AI pair-programming in managed notebooks for data science workflows.
Standard • Enterprise🔗 Apigee & Application Integration
API spec generation and integration-flow building with AI assistance — for API-platform teams.
Enterprise only🎓 Want depth on cloud + AI agents?
The sibling course Building with Gemini CLI has a full module on Google Cloud MCP servers — driving cloud resources from the agent loop.
Cross-referenceDeploying from Chat: How /deploy Works
The /deploy smart command packages your workspace and deploys it to Cloud RunGoogle Cloud's serverless container platform. It builds your source into a container (using buildpacks or your Dockerfile), runs it behind a public HTTPS URL, autoscales with traffic, and scales to zero (no cost) when idle. using your selected Google Cloud project. Under the hood it's equivalent to gcloud run deploy --source .: Cloud Build turns source into a container via buildpacksAutomated build tooling that inspects your source (requirements.txt, package.json...) and produces a container image without you writing a Dockerfile., then Cloud Run serves it.
Buildpacks make assumptions your app must meet — the three that matter for Python: a requirements.txt declaring dependencies, a production server (gunicorn, not Flask's debug server), and binding to the PORT environment variable Cloud Run injects.
"Works on my machine" to "works on a URL" is historically a wall: Dockerfiles, registries, load balancers, TLS. Cloud Run + buildpacks compress that wall to one command, and /deploy moves the command into the chat where you already are. For prototypes and small services, the time from working code to shareable URL drops from a day to ~5 minutes — and scale-to-zero means a demo app like Recipe Box costs pennies (or nothing) per month.
Lab: Recipe Box, Live on the Internet
Costs & prerequisites: a Google Cloud account with billing enabled (new accounts get free credits; Cloud Run's free tier covers this lab generously — expect $0 for a demo that you shut down after), the gcloud CLI installed, and your Recipe Box from G09. No billing? Do the no-cloud fallback below instead — same lessons, local container.
Make the app production-shaped (use Gemini to do it)
Recipe Box currently runs Flask's debug server on a hardcoded port — both deploy-blockers. In agent mode:
Prepare this app for Cloud Run deployment:
1. Create requirements.txt with flask and gunicorn (pinned versions).
2. Create a Procfile: web: gunicorn --bind 0.0.0.0:$PORT app:app
3. In app.py, make the __main__ block read PORT from the environment
(default 5001) and disable debug mode when ENV var FLASK_DEBUG is absent.
4. SQLite on Cloud Run is ephemeral (container filesystem resets on
restart) — add a comment in storage.py documenting this limitation
and that production would use Cloud SQL.
Show the plan first.
requirements.txt to build the image; the Procfile tells Cloud Run how to start a production server; PORT is injected by Cloud Run at runtime — hardcoded ports fail health checks. GOTCHA: item 4 is honesty, not code: every container restart wipes SQLite. Fine for a demo; wrong for real data. Knowing your storage story before deploying is the mark of someone who's done this twice.Set up the cloud project (one time)
gcloud auth login
gcloud projects create recipe-box-demo-YOURNAME --set-as-default
# Link billing in the console: console.cloud.google.com/billing
gcloud services enable run.googleapis.com cloudbuild.googleapis.com
Deploy — from chat or from the terminal
Path A (the integration): in Gemini Code Assist chat, run /deploy. It detects the app, confirms the target project/region, and walks through the deployment with progress in the chat panel.
Path B (equivalent, and what /deploy automates):
gcloud run deploy recipe-box --source . --region us-central1 --allow-unauthenticated
Verify like an operator, then clean up
# Exercise the live API (replace with your URL)
curl -X POST https://recipe-box-xxxxx-uc.a.run.app/recipes -H "Content-Type: application/json" -d "{\"name\": \"Cloud Toast\", \"ingredients\": [\"bread\"], \"minutes\": 5, \"tags\": [\"quick\"]}"
curl "https://recipe-box-xxxxx-uc.a.run.app/recipes?tag=quick"
# Read the logs — ask Gemini chat to explain anything surprising in them
gcloud run services logs read recipe-box --region us-central1 --limit 20
# Clean up when done (stops all charges)
gcloud run services delete recipe-box --region us-central1
No-Cloud Fallback: Same Lessons, Local Container
No billing account? You can still practice the production-shaping skills — they're identical; only the runtime differs. With Docker Desktop installed, ask agent mode:
Write a Dockerfile for this Flask app (python:3.12-slim, install
requirements.txt, run gunicorn binding to PORT with default 8080),
then give me the docker build and run commands for port 8080.
docker build -t recipe-box .
docker run -p 8080:8080 -e PORT=8080 recipe-box
curl http://localhost:8080/recipes
Everything you containerized here is exactly what buildpacks automate on Cloud Run — when you later get cloud access, Step 3 will work unchanged.
You crossed the writes-code/runs-code divide: production server, PORT contract, ephemeral-storage awareness, deploy, live verification, logs, cleanup. Gemini assisted at every step — preparing the app in agent mode, deploying via /deploy, explaining logs in chat. One module remains: the enterprise picture, and your capstone.
Knowledge Check
1. What does the /deploy smart command do?
2. Which three things did Recipe Box need before Cloud Run would run it properly?
3. Why is SQLite a problem on Cloud Run?
4. "Scale to zero" means…
5. Beyond the IDE, where does a Standard/Enterprise license surface Gemini assistance?
Quiz Complete!
Ready for G11: Enterprise, Security & Capstone →