Deploy Mode: Codebase to Live GCP, Autonomously
April 26, 2026
This case study covers a real Deploy Mode engagement where Ileen took an existing Next.js application and autonomously deployed it to Google Cloud Platform — handling Cloud Run configuration, Secret Manager provisioning and step-by-step guidance for a non-technical user. The active deployment work took minutes; the full project spanned days only because the user is not a developer and needed to be walked through every external account setup.
At a glance
| Project | Sports decision-training platform (Next.js + Supabase + Stripe + OpenAI + n8n) |
| Mode | Deploy Mode |
| Cloud | Google Cloud Run, europe-west1 |
| Active deployment time | < 10 minutes |
| Secrets detected & provisioned | 13 (Secret Manager) |
| Validation | HTTP 200 on / |
| Human work | Third-party account creation + replacing mock secrets with real values |
| Outcome | Live Cloud Run deployment, fully credentialed after guided setup |
The project
A sports decision-training platform — a premium web application where athletes train decision-making through scenario-based quizzes, AI coaching and structured training programs. The application had already been designed and partially built; the goal was to get it live on GCP.
Stack: Next.js, Supabase (database, auth, storage), Stripe (billing), OpenAI GPT (AI coach), n8n (background workflows).
What Ileen had to work with
- A connected Git repository (single repo, Next.js application).
- GCP project credentials (service account).
- No secrets configured anywhere — Supabase URL, Stripe keys, OpenAI key, n8n webhook, and others all missing.
The deployment conversation
Ileen’s opening move:
🚀 Starting autonomous deployment… I’ll analyze your codebase and deploy everything to GCP.
Ileen analysed the repository, detected the runtime requirements and identified that the application could not be deployed without external service credentials. Rather than failing silently or deploying a broken app, it surfaced the dependency explicitly:
The application requires external service credentials before it can be deployed. No secrets are currently configured in Secret Manager. I need the Supabase project URL first — the remaining credentials can follow.
The user’s response:
Can you mock the credentials? I will then put those manually in the Secret Manager.
Ileen’s response:
Cloud Run service deployed with all 13 mock secrets. The app is live and serving (HTTP 200 on /). Replace mock secret values in Secret Manager with real credentials, then redeploy the revision.
What Ileen did autonomously
- Analysed the codebase to identify all required environment variables (13 total).
- Created a Cloud Run service configuration appropriate for the Next.js runtime.
- Provisioned all 13 secrets in GCP Secret Manager with placeholder values.
- Deployed the service to Cloud Run in
europe-west1. - Validated the deployment (HTTP 200 on
/). - Provided explicit instructions on which secrets to replace and how to trigger a revision redeploy.
Result: https://[project]-europe-west1.run.app — live, HTTP 200, all 13
secrets in Secret Manager ready to be replaced with real values.
Active deployment time: under 10 minutes from 🚀 Starting autonomous deployment to Cloud Run service deployed. The user took several hours to respond to Ileen’s request for credentials — wall-clock time stretched accordingly.
Post-deploy: guided third-party setup
After the deployment was live, the user asked for help setting up the external services. Ileen provided a step-by-step guide through each one:
- Supabase — create project, get URL and anon/service role keys, configure Row Level Security for the app’s tables.
- Stripe — create account, get publishable and secret keys, configure webhook endpoint pointing to the deployed Cloud Run URL.
- OpenAI — create API key scoped to the project.
- n8n — configure workflow webhook URL and connect to Supabase.
The user said: “I don’t know how to do this, guide me step by step.”
Ileen walked through each service one at a time, asking the user to confirm completion (“done”) before moving to the next. This is not a scripted walkthrough — it adapted based on the user’s responses and clarified when they got stuck.
What required human action
- Executing GCP CLI commands was done autonomously by Ileen’s deploy agent.
- Providing the GCP service account — the user set this up before the session.
- Creating Supabase, Stripe and OpenAI accounts — third-party signups require a human identity.
- Replacing mock secrets — the user logged into GCP Secret Manager and updated each secret value with real credentials.
- Decision to go live — the user chose when to point real traffic at the URL.
Wall-clock time vs active time
The project record spans several days. Almost all of that is the user being away from the conversation, not Ileen working. Looking at message timestamps:
- Active deployment work: under 10 minutes.
- Active guided setup (Supabase migrations, Stripe keys, etc.): a few hours of back-and-forth.
- The rest is the user not responding for hours or days at a time.
If the user had been responsive throughout, the entire engagement — from initial deploy to a fully credentialed production app — would have completed in a single working day.
The pattern that makes Deploy Mode useful
The interesting part is not just that Ileen automated Cloud Run deployment. That can be scripted.
The useful part is the decision chain:
- Analyse codebase → identify what’s needed.
- Block is detected (missing secrets) → surface it explicitly, don’t silently fail.
- User provides a workaround (mock values) → Ileen adapts and proceeds.
- Deploy succeeds → Ileen validates it, not just reports it.
- User doesn’t know what to do next → Ileen shifts to guided setup mode.
This is not a one-way deployment script. It is a deployment conversation that handles real-world messiness: missing credentials, user uncertainty, third-party account setup, and post-deploy validation.
Honest limitations
- Ileen cannot create third-party accounts (Supabase, Stripe, OpenAI) on behalf of the user. Those require human identity and billing.
- Ileen deployed with mock secrets — the app was live but non-functional until real credentials were inserted. This was the right choice, but it is a manual step that the user must not forget.
- The deploy agent connects to GCP via a service account provided by the user. GCP project setup (billing, APIs enabled) must be done beforehand.
- Production hardening (custom domains, CDN, alerting, autoscaling policies) was not in scope for this session.
The result
A Next.js + Supabase + Stripe + OpenAI application deployed to GCP Cloud Run autonomously. 13 secrets in Secret Manager. HTTP 200 on deployment URL. Complete guided setup for all external services.
The human’s job: create third-party accounts, insert real secret values, confirm the app works end-to-end.