Gemini CLI repairs a failed Cloud Run deployment
Seroter reports that Gemini CLI deployed his app to Cloud Run, read logs after it failed to start, corrected the missing port configuration and redeployed.
seroter.com
Original prompt
Shared by the source author. See source notes for context.
Ship this code to Cloud Run in us-west1 using my seroter-project-base project.
Reach people exploring AI agents
See placements →Evidence at a glance
Sourced account- Source author
- Richard Seroter
- Original account
- Read the source ↗
- Published
- Source link checked
- Reported result
- Seroter reports that Gemini CLI deployed his app to Cloud Run, read logs after it failed to start, corrected the missing port configuration and redeployed.
- Human involvement
- Seroter keeps shell-command approvals enabled. He also demonstrates rejecting a later incorrect CI/CD deployment and requesting corrected files for review.
A linked account supports attribution. It does not mean we independently reproduced its result.
Report an issue with this case
Open correction emailOpens your email app with the case link included. Nothing is sent automatically.
How the agent did it
- Give Gemini a source deployment target, region and project.
- Use the connected Cloud Run MCP server to deploy the app.
- Inspect service logs when the deployed app fails to start.
Richard Seroter used Gemini CLI to build and deploy a family vacation calendar application. The deployment request specified Cloud Run, a region and a Google Cloud project, and asked the agent to deploy source files rather than make a container manually. He had connected a Cloud Run MCP server, which supplied a structured deployment tool.
The initial deployment completed, but the service did not start correctly. Gemini inspected the service logs and identified a missing reference to the listening port. It changed the application and redeployed. This is the concrete agent behaviour in the account: the task continued from tool execution into observing a failure and correcting it.
Seroter kept command approvals enabled during his experiments. In a later CI/CD trial, he rejected an incorrect deployment request, supplied current Cloud Deploy documentation and asked to inspect the corrected files before proceeding. That later workflow also needed several failed-build iterations. The account illustrates why an operator should provide an explicit target and retain approval of infrastructure changes. It does not establish that every generated configuration is correct or that the calendar was production hardened; the reported result is a repaired deployment in his own experiment.
Prompt
Original prompt
Source: Blog · Richard Seroter
Frequently asked questions
What failed after the first deployment?
The service did not start because the application lacked the appropriate listening-port reference.
How did Gemini find the problem?
Seroter says the agent read Cloud Run service logs, diagnosed the issue and changed the code.
Were infrastructure changes unattended?
Seroter kept approvals enabled and describes rejecting an incorrect deployment in his related CI/CD experiment.
More details
Remaining steps
- Correct the port configuration and redeploy.
About this account
The agent selected a deployment tool, checked service logs after failure, diagnosed the port problem and updated the code before another deployment.
Firsthand account by Richard Seroter; original publication date verified against Primary page publication date. Outcomes are the author’s reports, not independently reproduced. Original prompt excerpt transcribed from the primary account; excerpt only, not the complete prompt. Preserve the source-specific context when adapting it.
Credit: Richard Seroter
Source published
Added to Agents In Use
Source checked
Tools and topics
Gemini CLI · Cloud Run MCP · Google Cloud CLI · Cloud Run
Deployment · Failure recovery · Logs
Editorial completeness: 100/100. Measures documented fields, not agent performance or verified outcomes.