Internal Deployment Platform on Cloud Run
Overview
At a large enterprise, shipping a small internal app usually meant going through the standard GKE path: CI/CD wiring, Helm charts, Backstage provisioning, and coordination with the platform org. My team and I built a simpler Cloud Run path for teams that needed a live, authenticated URL without owning Kubernetes.
Technical write-up
Read the architecture notes on Cloud Build, Cloud Run, routing, tenancy, and logs.
The Problem
The default path was too heavy for brochure sites, prototypes, and internal tools. Teams could build a proof of concept in days, then spend weeks getting a production-like URL with the right access controls.
That delay showed up in demos, hack weeks, and cross-functional pilots. The blocker was rarely the app code. It was the deployment path around it.
The betIf teams could push a repo and get an authenticated internal URL, Cloud Run could cover the work that did not need GKE.
What I Built
- A UI for connecting a repository and deploying an internal app from a branch push
- A managed build path that used a
Dockerfilewhen present and buildpacks otherwise - Secret Manager integration for build-time and runtime credentials
- Cloud Run services behind shared HTTPS routing and identity-aware access
- A merged build and runtime log stream so developers could debug from one console
Deploy path
< 5 minutes
From repository push to authenticated internal URL
Audience
150+
Internal users in the first month of launch
Before → after
Weeks → minutes
Time to first deploy for typical internal apps and pilots
The Tradeoff
Cloud Run gave us the right default for small internal apps: container semantics, scale to zero, and no cluster operations. It did not remove platform work entirely. Friendly URLs, tenant isolation, and unified logs still needed control-plane design around Google Cloud primitives.
The useful boundary was clear: this platform was not a replacement for every Kubernetes workload. It was a golden path for teams whose apps were too important to live on a laptop and too small to justify the full GKE route.
Where It Went
The platform reduced time to first deploy from days or weeks to minutes for typical internal apps. It also gave non-platform teams a clearer way to ship authenticated demos and pilots without learning the whole production infrastructure stack.
The deeper architecture details live in the paired technical post.
technical notesI moved the URL-map, tenancy, and log-streaming details into the article so this portfolio page stays focused on the product shape and outcome.
- GCP
- Cloud Run
- Platform engineering
- Internal tools
