We took an insecure shortcut! Our app needs a Gemini API key and we declared it as an environment variable. Although environment variables aren’t publicly readable in Cloud Run, they’re not the most secure option for storing API keys. This especially becomes an issue as you work with teams greater than 1, where not everyone should have access to sensitive data. But you still need a way for your app to access that sensitive data.

Google Cloud Secret Manager is a secure and centralized management system for storing, managing, and accessing sensitive information such as API keys, passwords, and certificates.

For our simple chat app, Secret Manager ensures that only the app has access to the API key and provides additional benefits such as key versioning and expiration, without requiring code changes to the app.

Making the code changes

We're going to migrate the app to use Secret Manager. We do so with the following prompt to my IDE of choice, Google Antigravity:

Instead of using an environment variable for the Gemini api key, use Google Cloud Secret Manager.

Antigravity provides the following implementation plan:

After proceeding with Antigravity's implementation plan, we see the following code changes:

We will accept the code changes, push the commit and merge it in GitHub. Once the code PR has been merged into the main branch, GitHub will kick off a build (as per our CI/CD setup in Part 1 of this blog series). GitHub indicates that a build is in progress with a yellow dot on the frontpage for the repo as follows.

You can also view the build output while it is in progress by clicking that dot. The build is being carried out by Google Cloud Build but the status is synchronised with GitHub so progress can be viewed there.

Due to our CI/CD setup, Cloud Run will deploy the newly created container image immediately. But we haven't actually configured Secret Manager yet!

Create secret

We now need to go to Google Cloud Secret Manager in the Google Cloud console and create a key as follows:

We need to note the path to the secret as we will need this path to access it later. You can see the project ID and name of the secret below.

Although we are now using Secret Manager to store our API key, we rely on two environment variables to point us to the key - the project ID (a number) and the name of the secret. We noted down the path from the screenshot above and it contained these pieces of information. Therefore we need to edit our Cloud Run deployment to declare these environment variables.

Now let's check out the app!

Uh oh! That was unexpected. The 403 error gives us a clue that this is a permissions problem. We created the secret but didn't allow it to be accessed by our Cloud Run instance. This is a feature! Secrets are access controlled such that only certain users have access to them.

Our Cloud Run app runs under a service account, a special type of Google account intended to represent a non-human user. We need to ensure that the service account has permission to read secrets. We will go to the Identity and Access Management (IAM) permissions for our service account and add the "Secret Manager Secret Accessor" permission as shown below.

Ok now we should be good to go!

And there we have it. We have successfully migrated our code from using an environment variable to retrieve our Gemini API key to using Google Cloud Secret Manager. This is not only more secure but also far more flexible. Check out Secret Manager here.

Creating the app

For the example app, I will create a basic chat app (using Gemini CLI).

You can see above that we've used the prompt generate an attractive looking python webapp that is a gemini chatbot using the gemini 3 flash model to build it. It was sufficiently capable but also very simple and it worked out of the box!

Note that the app is using the latest google-genai package. Gemini 3 has a knowledge cutoff of January 2025 and hence doesn't default to this package. To equip Gemini 3 with the latest knowledge, check out a previous blog post on Upskilling Antigravity and Gemini CLI for the Gemini API.

Creating a GitHub repository

Next, I want to push the code to GitHub - I will use the GitHub CLI. The first step is to create a local git repo and commit the code. The next step is to push the code to GitHub in a new private repo called simplechat.

📝 Note: The app is only comprised of two files: app.py and requirements.txt.

Deploying to Cloud Run

Cloud Run is a fully managed serverless platform that allows you to run containerised applications that automatically scale from zero to thousands of instances, ensuring you only pay for the exact resources your code consumes while it's active.

Let's now configure deployment to Google Cloud Run. The steps are as follows:

1. [Screenshot 1] Navigate to https://console.cloud.google.com/run/overview

2. [Screenshot 1] Select "Connect Repository"

3. [Screenshot 2] On the next screen, select "GitHub." Continuously deploy from a repository (source or function).

4. [Screenshot 2] Also select "Cloud Build".

5. [Screenshot 3] Click "Set up Cloud Build". This will expand a panel on the right-hand side of the window, where you can authenticate your GitHub account and connect your repository. Once you have done so, you will be on the third image below (bottom right).

6. [Screenshot 3] Give your Cloud Run service a name and region. I chose simplechat for the name and us-central1. For authentication, select "Allow public access" and click "Create".

7. [Screenshot 4] Under the "Creating service" section, you can see the status of creating the service, creating the build trigger, building and deploying from the repository. At the end of this, you'll have a URL to access the Cloud Run service.

📝 I'd said earlier that the app is only two files app.py and requirements.txt. The neat thing about deploying through Cloud Run is that it uses Buildpacks. Because of Buildpacks, we don't even need to write a Dockerfile; it inspects the code, detects Python, and containerises it automatically.

Configuring API keys securely

After deploying the app, there's an error! The API key is missing.

To fix this, the Cloud Run deployment needs to be edited to declare the GEMINI_API_KEY environment variable.

The steps to do this are:

1. [Screenshot 1] On the Cloud Run deployment page, click "Edit and Deploy New Revision".

2. [Screenshot 2] Select "Variables & Secrets" and click "Add variable".

3. [Screenshot 3] Call the variable "GEMINI_API_KEY" and fill in its value. Click "Deploy".

This will deploy a new revision of the app (using the previously built container image), where the environment variable will be accessible.

📝 We just injected our GEMINI_API_KEY as a plaintext environment variable. This is fine for our simple chat app, but as your app grows, you'll want to lock this down. The industry-standard next step is to use Google Cloud Secret Manager. You can store the key there and configure Cloud Run to pull it securely at runtime, ensuring your secrets are properly encrypted and access-controlled.

Confirm that changing source code deploys automatically to Cloud Run

Now I will update the heading to force a source code change, push to GitHub and observe the automated Cloud Run deployment. The source code change is:

Pushing this code will immediately trigger a Cloud Build.

Once this is finished, the updated app is instantly available on Cloud Run.

In this blog post, I created a simple Gemini chat app using Gemini CLI. I pushed the repository to GitHub, configured a new Cloud Run service that connects to the GitHub repo, added my secrets (through environment variables) and demonstrated the automated deployments through code pushes. I now have a production ready setup. As the app grows, this setup will allow me to quickly iterate.

Over the years, I’ve maintained the codebase, mostly to update my dependencies in response to CVEs. I’ve recently been making these security changes using Antigravity and Gemini 3 Pro. I would manually test all these changes between releases.

Antigravity with Gemini gets you started quickly

MetaRefCard is written in Go which has excellent tooling for building & running tests. Antigravity and Gemini are able to utilise them very well.

To start, I asked Antigravity to build out a comprehensive set of tests. The result was a decent number of unit tests but I couldn't judge how comprehensive it was. Go’s testing framework can actually provide this data.

It’s easy to generate the output yourself.

ankur@:~/devel/metarefcard$ go test -coverprofile=coverage.out ./... && go tool cover -func=coverage.out
ok metarefcard              29.241s coverage: 0.0% of statements
ok metarefcard/mrc          0.584s  coverage: 0.0% of statements
ok metarefcard/mrc/common   0.003s  coverage: 1.3% of statements
ok metarefcard/mrc/fs2020   0.004s  coverage: 60.9% of statements
ok metarefcard/mrc/sws      0.011s  coverage: 77.3% of statements

main.go:13:               main                           0.0%
main.go:22:               parseCliArgs                   0.0%
mrc/common/devices.go:4:  LoadDevicesInfo                0.0%
mrc/common/game.go:40:    TitleCaser                     0.0%
mrc/common/game.go:86:    GameBindsAsString              0.0%
mrc/common/game.go:114:   Keys                           0.0%
mrc/common/image.go:17:   GenerateImages                 0.0%
mrc/common/image.go:69:   prepImgGenData                 0.0%
mrc/common/image.go:91:   populateImage                  0.0%
mrc/common/image.go:177:  decodeJpg                      0.0%
mrc/common/image.go:194:  measureString                  0.0%
mrc/common/image.go:201:  calcFontSize                   0.0%
mrc/common/image.go:250:  prepareContexts                0.0%
mrc/common/image.go:261:  getPixelMultiplier             0.0%
mrc/common/image.go:269:  drawTextWithBackgroundRec      0.0%
mrc/common/image.go:289:  addImageHeader                 0.0%
mrc/common/image.go:315:  addMRCLogo                     0.0%
mrc/common/logger.go:12:  Dbg                            0.0%
mrc/common/logger.go:17:  Msg                            0.0%
mrc/common/logger.go:24:  Err                            0.0%
mrc/common/logger.go:31:  Fatal                          0.0%
mrc/common/logger.go:36:  NewLog                         0.0%
mrc/common/model.go:10:   LoadGameModel                  0.0%
mrc/common/model.go:17:   FilterDevices                  0.0%
mrc/common/model.go:40:   GenerateContextColours         0.0%
mrc/common/model.go:66:   PopulateImageOverlays          0.0%
mrc/common/model.go:115:  GenerateImageOverlays          0.0%
mrc/common/util.go:18:    Keys                           100.0%
mrc/common/util.go:27:    LoadYaml                       0.0%
mrc/common/util.go:43:    YamlObjectAsString             0.0%
mrc/common/util.go:55:    loadFont                       0.0%
mrc/common/util.go:79:    loadFont                       0.0%
mrc/fs2020/fs2020.go:31:  GetGameInfo                    0.0%
mrc/fs2020/fs2020.go:36:  handleRequest                  0.0%
mrc/fs2020/fs2020.go:54:  loadInputFiles                 79.6%
mrc/fs2020/fs2020.go:234: matchGameInputToModel          0.0%
mrc/fs2020/fs2020.go:262: matchGameInputToModelByRegex   43.6%
mrc/metarefcard.go:36:    GetServer                      0.0%
mrc/metarefcard.go:94:    loadLocalFiles                 0.0%
mrc/metarefcard.go:106:   loadFormFiles                  0.0%
mrc/metarefcard.go:131:   sendResponse                   0.0%
mrc/metarefcard.go:195:   String                         0.0%
mrc/metarefcard.go:200:   Set                            0.0%
mrc/metarefcard.go:206:   GetFilesFromDir                0.0%
mrc/sws/sws.go:31:        GetGameInfo                    0.0%
mrc/sws/sws.go:36:        handleRequest                  0.0%
mrc/sws/sws.go:52:        loadInputFiles                 86.5%
mrc/sws/sws.go:181:       addAction                      100.0%
mrc/sws/sws.go:207:       getInputTypeAsField            85.7%
mrc/sws/sws.go:227:       interpretInput                 66.7%
mrc/sws/sws.go:302:       matchGameInputToModel          0.0%
total:                    (statements)                   29%

The initial test coverage wasn’t great at 29% but it was clear which files and functions had less coverage.

Guiding the model to expand coverage

One of the nice things about Go’s testing coverage report is that it can tell you test coverage per function. This way, I could see where my testing gaps were. I started asking Antigravity to increase coverage overall and when that had diminishing returns, I asked to increase coverage of specific functions.

I had to guide the process much more and ask questions about why it couldn’t go higher. This is a modern way of agentic engineering where my focus wasn’t on each line of code but instead it was about guiding the outcome.

Completing test coverage

Using this technique, I spent the next couple of hours having Antigravity eventually get my test coverage to 99.7%, with the only code not covered by unit tests being the main function. Again, this required back and forth with the tool.

I’m really satisfied with where I ended up. In a few hours, I had a very comprehensive test suite and felt a lot more confident to automatically make changes in the future.

If you’ve got a codebase that could do with additional test coverage, it’s easy to get started with Antigravity.

In the screenshot below, you can see that we are using “Gemini 3 Pro (High)” (currently Google’s best model) with the following prompt:

create a new python webapp that calls the gemini API using the latest gemini model

Immediately you can see a problem in the code. The app is using the deprecated google-generativeai package and we can see that the code is also calling the outdated gemini-1.5-flash model.

Why does this happen? Shouldn’t Antigravity and Gemini 3 Pro write code that leverages the latest packages and models? Simply put, it has to do with the model’s knowledge cutoff. Even though Gemini 3 Pro was launched in December 2025, the model’s knowledge cutoff is January 2025. Gemini 3 Pro doesn’t know about models and packages that launched afterwards. Therefore, the model is defaulting to older packages and models. This issue is not unique to Gemini and all models face it.

Thankfully there’s a fix for this! Antigravity supports Agent Skills to make this easier. “Agent Skills are a lightweight, open format for extending AI agent capabilities with specialized knowledge and workflows.” We can use Agent Skills to equip Antigravity and Gemini 3 Pro (or whichever model you use) with the latest knowledge.

The Google Gemini team recently launched the Gemini Skills GitHub repository.

This repo contains a skill that Antigravity’s agents can use to guide the model towards using the latest Gemini API packages (across a range of languages) and the latest models.

Once we’ve added this skill to ~/.gemini/antigravity/skills/gemini-api-dev/SKILL.md, we can retry our prompt. We immediately see the desired results.

While AI models are incredibly powerful, their knowledge cutoffs will always be a limiting factor in the fast-paced world of software development. Fortunately, Agent Skills provide a lightweight and effective bridge. By giving Google Antigravity up-to-date context, you can ensure your agentic IDE is always writing modern, relevant code. Head over to the Gemini Skills GitHub repository to grab this skill, or try writing your own custom skills to tailor Antigravity to your specific needs.