This article is based on reporting originally published by SDXCentral in June 2018, covering GitLab’s 11.0 release and related commentary from CEO Sid Sijbrandij.
GitLab 11.0 Ships Kubernetes-Native Auto DevOps
In June 2018, GitLab released version 11.0 of its platform, centering the update on a Kubernetes-backed feature called Auto DevOps. The goal was straightforward: a developer pushes code, and the platform handles every subsequent step automatically — no manual plugin configuration, no endpoint wiring.
According to GitLab CEO and co-founder Sid Sijbrandij, the 11.0 pipeline covers the following stages automatically when Auto DevOps is enabled:
- Build – containerising the application automatically
- Test – running the project’s test suite
- Code quality scanning – static analysis of source code
- Security scanning – vulnerability detection in dependencies and code
- License scanning – identifying open-source license obligations
- Packaging – producing a deployable artefact
- Performance testing – load and response-time checks
- Deployment – releasing to a target Kubernetes cluster
- Application monitoring – runtime metrics and alerting
“These things are normally a time sink in that there are plugins that need to be added and endpoints need to be set,” Sijbrandij explained. “Now with this update those things just happen.”
Why Kubernetes Is Central to Auto DevOps
Sijbrandij was explicit that the feature’s automation would not have been achievable without Kubernetes as the underlying orchestration layer. “Auto DevOps would not be possible without Kubernetes,” he said. “The ability to spin up new processes is the real superpower and is what we get from the integration.”
Kubernetes provides several capabilities that Auto DevOps depends on:
- On-demand pod scheduling – each pipeline stage can spin up an isolated container, run its job, and terminate, keeping resource usage proportional to actual work.
- Declarative deployments – rolling updates and rollbacks are managed by the cluster, not by custom shell scripts.
- Namespace isolation – review apps and staging environments can be created per branch without interfering with production.
- Secrets management – Kubernetes secrets can be injected into pipeline jobs and running pods without hardcoding credentials.
Native Google Kubernetes Engine Integration
In April 2018 — two months before the 11.0 release — GitLab announced a partnership with Google to support automated container cluster deployments. The deal added native Google Kubernetes Engine (GKE) integration, letting users connect an existing managed Google container account directly to GitLab.
Once connected, GitLab can automatically create Kubernetes clusters that are fully managed by Google and run on Google Cloud Platform (GCP). This removed a significant barrier to adoption: teams that had no existing Kubernetes expertise could still take advantage of Auto DevOps by letting GKE handle cluster lifecycle management.
“It’s been everything we had hoped for,” Sijbrandij said of the Kubernetes integration at the time of the 11.0 announcement.
Container Idling: Serverless-Style Efficiency on Kubernetes
At the time of the 11.0 release, GitLab was also exploring an idling feature that would take non-running containers offline automatically, preventing them from consuming compute or cloud spend when idle. Sijbrandij drew a direct comparison to the economics of serverless platforms, which only consume resources when actively handling requests.
This kind of idle-container management on Kubernetes mirrors patterns later popularised by projects such as KEDA (Kubernetes Event-Driven Autoscaling) and Knative’s scale-to-zero capability, though GitLab’s 2018 implementation details were not publicly specified at the time.
GitLab’s Serverless Ambitions
Sijbrandij also signalled that GitLab was increasing its investment in the serverless space, including work with an unnamed partner on a platform that could integrate with open-source serverless frameworks such as OpenFaaS and Kubeless.
He acknowledged two persistent pain points developers faced with serverless at the time:
- Lack of observability – limited visibility into function execution, latency, and failure rates compared to traditional long-running services.
- Revision control – difficulty tracking and rolling back individual function deployments in the same way as versioned application releases.
“There is not really a clear leader yet in open source serverless, but we think with a partner we can make something that is useful,” Sijbrandij said, while declining to name the partner or provide a release timeline.
The GitHub Effect: 100,000 Repository Imports
The 11.0 announcement came against the backdrop of Microsoft’s planned $7.5 billion acquisition of GitHub, which generated significant concern within parts of the open-source community. GitLab reported that in the days immediately following the Microsoft announcement it had:
- Imported more than 100,000 repositories
- Seen a 7× increase in orders
GitLab moved quickly to capitalise on the moment by offering discounts on its top-tier plans.
However, Sijbrandij was candid about the long-term picture. “There are users that were concerned with the Microsoft deal and moved to GitLab, but I think that will be temporary,” he said. His more considered argument for sustained GitLab adoption rested on platform differentiation rather than Microsoft anxiety: “Many were satisfied with GitHub, but see that they can do more with GitLab. This will create more opportunities and open some doors for us.”
Financial Context: Series C and Market Valuation
At the time of the 11.0 release, GitLab had closed a $20 million Series C funding round from Google Ventures (now GV). Sijbrandij described the company as “well financed” and noted that Microsoft’s $7.5 billion valuation of GitHub “puts a valuation out there, and it was high” — implying that the acquisition price set a favourable reference point for how the market values developer platform businesses.
Key Takeaways for DevOps Teams
The 11.0 release illustrated several principles that remain relevant to platform engineering teams today:
- Kubernetes as a CI/CD substrate — using the cluster as the execution environment for pipelines (not just as a deployment target) unlocks per-job isolation, resource limits, and horizontal scaling of build workloads.
- Convention over configuration — Auto DevOps demonstrated that sensible defaults can dramatically reduce the time-to-first-working-pipeline for new projects.
- Integrated security scanning — embedding SAST, dependency scanning, and license checks into the standard pipeline — rather than bolt-on tools — makes security a routine step rather than a gate at release time.
- Managed Kubernetes lowers the barrier — pairing a CI/CD platform with a managed Kubernetes offering removes the need for teams to maintain cluster infrastructure before they can benefit from container-native pipelines.
This article reflects the state of GitLab and the broader ecosystem as of June 2018. Some features described were roadmap items at the time and may have shipped, changed scope, or been superseded in subsequent releases.