GitOps at 500 Microservices: How Deutsche Telekom Uses Argo CD and Kargo to Run GitOps at Scale
Heba Eid
In a recent GitOps Monthly episode, Taylor Thomas, Staff Software Engineer at Akuity, sat down with Johannes Sonner, Technical Product Manager at Deutsche Telekom, to discuss how one of Europe's largest telcos scaled GitOps across a complex enterprise environment.
This article covers the key takeaways from that conversation:
The scale challenges Deutsche Telekom faced and what drove the need for change
Why they moved away from traditional CI/CD pipelines
How they run GitOps at enterprise scale today using Argo CD and Kargo
You'll also find live demo walkthroughs of both ephemeral and stable promotion workflows, as Johannes demonstrated during the webinar.
What is Kargo?
Akuity is the creator and core maintainer of Kargo.
Before diving into Deutsche Telekom's setup, a quick primer on Kargo for those less familiar.
Kargo is a multi-stage GitOps promotion tool. It takes artifacts — container images, config, manifests — and moves them through a series of stages. Stages aren't simply environment aliases; they can represent geographic regions, deployment waves, or any logical grouping that maps to your release process. A typical setup might include dev, staging, and production stages, giving you a single, consolidated view of what's deployed where at any point in time.
Why should Platform teams use Kargo?
If you've been running GitOps without a dedicated promotion tool, you've almost certainly accumulated a collection of bespoke scripts — scattered across Jenkins jobs, GitHub Actions workflows, or worse — with no authoritative view of deployment state. Kargo replaces that patchwork with a purpose-built promotion layer that sits on top of Argo CD.
Everything gets packaged into what we call freight: a bundle of a specific image version, config, and manifest that moves through each stage together. Each promotion comes with built-in guardrails, testing, validation, and end-to-end visibility.
Deutsche Telekom Need for Scale & Challenges
Deutsche Telekom operates in over 50 countries. Across the group, Telekom serves around 260 million customers, spanning mobile networks, fixed line, TV, and various digital services.
Johannes's team runs a platform supporting primarily B2C services in Germany, serving about 20 million users per day. The platform is also expanding to host other internal workloads across the company.
Johannes’ team runs around 500 different microservice repositories, with roughly 40 development teams of 8–12 developers each using the platform.
The pressure to modernize is significant. Many of Telekom's business systems are 20–30 years old, and there's a strong need to migrate to microservices quickly while maintaining reliability, making a solid internal development platform essential.
Why They Moved Away from Pipelines
Traditional CI/CD pipelines have a fundamental visibility problem: they tell you what ran, not what's actually deployed.
During the demo, Johannes pulled up a snapshot of Telekom's previous pipelines, jobs from 7 days prior, with no clear answer about what was currently running in production. Jobs may have executed multiple times, rollbacks may have happened, but the pipeline offers no authoritative view of the final state.
There were two core issues that the Platform engineering teams encountered: Two core issues
No reconciliation. If someone runs
kubectl editat 2 am to fix a production issue, that change lives on the cluster forever until it is overwritten. There's no automatic drift correction.No cleanup. Dynamic environments created for developer testing don't get torn down automatically unless you build separate cleanup logic. These accumulate, consuming resources and adding noise to an already complex system.
Using Argo CD & Kargo to Scale GitOps
Below are the main reasons Johannes’s team is using Argo CD and Kargo as the foundation of their platforms.
Auditability: Everything lives in Git — who changed what, and when. Because Kargo promotions flow through merge requests, your existing branch protection rules and approval policies apply automatically. Deutsche Telekom didn't need to rebuild access controls when they adopted Kargo. Required approvers, merge restrictions, and approval counts all carried over from GitLab.
UI accessibility: Developers range from fresh graduates to 20-year veterans. The Argo CD UI provides a unified layer for everyone. You can pass links around, save them for RCAs, and get clear status at a glance — without building custom tooling for it.
GitOps-friendly configuration: Everything — including infrastructure resources managed by tools like Crossplane or Pulumi — can flow through Argo CD. About 70% of infrastructure resources are synced by Argo CD.
Hybrid YAML manifests (Kargo): With Kargo's rendered manifest pattern, the manifest in Git is exactly what gets applied to the cluster. There's no abstraction layer or runtime-only chart rendering. What you see in Git is what you get on the cluster.
Extensibility and self-service: Because Git is the API, anything that can write a file can integrate with this system. You don't have to build custom integrations for every workflow — Argo CD reconciles, Kargo detects new artifacts, and the rest follows automatically.
Platform Architecture Overview
Argo CD and Kargo sit in the integration plane — alongside the image repository, code repositories, and other orchestrators — bridging the self-service portal (Backstage + Git) with the actual resource plane (workload clusters).
Figure: Deutsche Telekom Platform Architecture
Argo CD and Kargo operate in the Integration Plane, bridging the development and resource planes (see above Figure).
The architecture uses a management cluster where these tools run, offering users a unified control plane. There's one Argo CD instance for non-prod and one for prod, as required by security guidelines. From there, these tools manage all services across all clusters.
The platform team can decide where a service runs by defining the appropriate Argo CD ApplicationSet. Developers don't need to know which workload cluster they're on. Shifting a service between clusters is just a matter of updating the ApplicationSet definition.
"This manifest in this end folder is the ultimate truth of what will be deployed to the cluster. And this makes something abstract like 'I'm just gonna push the version of my Helm chart dependency' to something very very clear and very absolute — because I can actually see each and every line of my code that will change." — Johannes, Deutsche Telekom
Live Demos: Ephemeral and Stable Promotion Workflows
The second half of the webinar was hands-on. Johannes walked through two live demos directly inside the platform — no slides, no mocked-up screenshots. If you want to see the full walkthroughs, the recording is embedded below.
Demo 1: Ephemeral Environment Promotion
A developer pushes a feature branch, and the platform automatically spins up an ephemeral environment scoped to that branch. Argo CD handles the lifecycle entirely — no Kargo is involved at this stage, by design. Once the environment is no longer needed, it's torn down automatically. No cleanup scripts, no lingering resources.
Demo 2: Stable Promotion with Kargo
Once changes are merged to the develop branch and a version is ready to move toward production, Kargo takes over. It renders the manifests for production, pushes them, waits for approval, and then triggers a sync in Argo CD.
Up Next: GitOps Monthly — March 17
The next session covers how to simplify and automate promotions at scale — including a unified Kargo and Argo CD interface, promotions across Kubernetes, Terraform, VMs, and cloud services, and eliminating the custom scripts holding your pipelines together. [Register here.]
Watch the Full Webinar
You can watch the full recording — including both live demos — here:
