AI
Why Cloud Run Worked, Then Stopped Working
Runway’s first version ran on Cloud Run because speed to market was the only priority. Engineers handed the platform a container image, and Runway pushed it through staging and into production automatically. That worked well for gitlab.com. It failed for self-managed customers. Some of them face data residency rules that make handing data to a third-party cloud provider simply not an option, not a preference or a cost concern. Locking the platform to Cloud Run made that GitLab’s problem, then the customer’s problem.
Kubernetes and Helm as the Portable Common Ground
Kubernetes won as the common runtime for two reasons. It is an open standard, so no single vendor controls the API. GitLab’s vision covers GKE, EKS, a home lab, and local development environments like K3s. Helm became the packaging format because the team judged it the de facto standard and already familiar to customers. The Kubernetes-based platform generates a Helm chart for each satellite service first, then deploys that chart to GitLab-owned clusters. The extra step was not required for the Cloud Run migration but was built in to prepare for self-managed support.
One Helm Chart for SaaS and Self-Managed Customers
GitLab’s internal clusters deploy the same Helm chart that self-managed customers will eventually use. This is not accidental. It was engineered so that problems surface on gitlab.com before they reach a customer’s cluster. The developer experience stayed largely intact: a CI pipeline builds a container image and the image gets pushed automatically to the Kubernetes cluster for gitlab.com. Self-managed customers handle their own deployments. Satellite services like the Duo coding agent already follow this model, with roughly a dozen services currently in production.
Breaking Long Release Cycles for Satellite Services
GitLab’s monolith ships on monthly release cycles with major versions every 12 months. Teams building satellite services through Runway are no longer bound by that cadence. Forster compared the result to a Linux distribution: a tested, supported bundle of satellite service versions exists for customers who want it, but individual teams can move faster and release independently. The monolith itself is showing scalability friction. Components that want to release or scale independently are currently coupled together, and Runway is the planned path out.
LabKit and a Shared CI Template: Extending the Platform Into the Application
Runway handles deployment, but the platform also reaches into the application through a library called LabKit. Using LabKit wires up traces, metrics, and logs automatically, all sent to the correct internal endpoints in the standard field format needed for cross-source correlation. Alongside LabKit, GitLab maintains two to three dozen shared CI jobs covering Go unit tests, semantic releases, and dependency updates via Renovate. A copier template ties all of it together. A new repository using the template is fully configured and able to push to production within 15 to 20 minutes.
Q&A
Will the omnibus package disappear as GitLab moves to Kubernetes? Omnibus is not going away. New services like the Duo coding agent will target Kubernetes as add-ons, while core functionality continues shipping via omnibus alongside an adjacent Kubernetes cluster for optional services. ▶ 21:45
How should teams handle backwards compatibility across independently versioned satellite services? Enforce strict API backwards compatibility, add static checks for renamed or removed fields, and treat internal service communication with the same discipline as public APIs. ▶ 24:06
What are the future plans for splitting the GitLab Helm umbrella chart? The delivery team owns that work. Individual modules should be independently deployable, but the unified chart will stay in some form because customers rely on it. How much gets generated versus hand-written is still an open internal discussion. ▶ 19:24
Notable Quotes
it is showing kind of signs of weaknesses uh signs of scalability friction Florian Forster · ▶ 02:06
cloud run is not an option. It’s not a preference. It’s not the the cost. It’s simply not an option for them to use cloud run because it’s not an option to kind of hand the data over to another cloud provider multinational like that. Florian Forster · ▶ 06:50
this isn’t happening by accident. This was like engineered in Florian Forster · ▶ 16:29
within 15 minutes, 20 minutes, uh you’re all set up and you can potentially push to production. All you need to do is kind of write your business logic at that point. Florian Forster · ▶ 29:03
we need to provide a migration path that doesn’t leave our customers in the dust because we’re already struggling motivating our customers to upgrade to the newest version. Florian Forster · ▶ 23:03
Key Takeaways
- Vendor platforms accelerate early work but create lock-in that can block self-managed customers with data residency requirements.
- Generating Helm charts for every satellite service, even before self-managed support ships, prevents configuration drift between SaaS and customer deployments.
- A copier template combining LabKit, shared CI jobs, and Runway gets a new service to production-ready in under 20 minutes.
About the Speaker(s)
Florian Forster is a Site Reliability Engineer at GitLab and tech lead for the Runway platform. He specializes in building scalable platforms at the intersection of software and infrastructure. Before GitLab, he built a platform for third-party software at Google.