At the end of September 2025 I had two GitOps days in a row. On Monday 29 September the Dutch Cloud Native Community Group met at ASML in Veldhoven, with a platform-team talk on admission policies and a talk on running Argo CD at enterprise scale. The next morning, Tuesday 30 September, Octopus Deploy hosted a breakfast session in Hoofddorp called â2025 State of GitOps and what it means for youâ, which walked through its survey data.
This post is written from the slides I photographed, plus short phone clips of the meetupâs opening and of the ASML talk.
Following the signs to the meetup at ASML in Veldhoven.
The opening: nine years of meetups
The evening ran in a large auditorium. The welcome slide showed the groupâs name, the Meetup logo and cloudnative.amsterdam. The host said the community had been meeting for nine years, almost ten, starting about a year after Kubernetes launched, and that it follows the Berlin Code of Conduct. He offered the stage for five-minute talks about open source projects, with no sales pitches.
The rest of the opening covered what was coming next:
- KCD Amsterdam in May 2026, this time over two days, with priority for end-user speakers over vendors and AI and sustainability as themes.
- Another meetup on 23 October in Amsterdam at JetBrains.
- TalosCon coming to Amsterdam in October. I wrote that one up separately in my TalosCon 2025 recap.
ASML: adding guardrails without interrupting existing workloads
The first talk was âAdding guardrails: Without interrupting existing workloadsâ by Niels Heetesonne and Nick Heinemans of ASMLâs Container Platform Services team. Their team runs the Kubernetes clusters that other ASML teams deploy to.
The ASML title slide: âAdding guardrailsâ, by the Container Platform Services team.
The âBackgroundâ slide was titled âNo guardrailsâ. It quoted âWith great power comes great responsibilityâ and said users took that responsibility but needed support from the platform team. The number of users was growing and so was the variety of workloads. The upside of that freedom was also on the slide: learning Kubernetes, innovation and sharing knowledge.
The next slide, âWhere do we start?â, showed the standard Kubernetes architecture diagram with the API server circled and a box reading âAdd Admission Control hereâ. Admission control is the obvious place for guardrails, because every create or update request to the cluster passes through it.
Why Kubewarden
The admission controller they chose was Kubewarden. Their slide gave four reasons:
- Open source, part of the CNCF
- Flexible
- Scalable
- Integration with Rancher
The Kubewarden slide: CNCF, flexible, scalable, and it works with Rancher.
Some context from the project itself: the Kubewarden site describes it as a CNCF Sandbox project, originally developed by Rancher by SUSE. Its documentation explains that policies are WebAssembly modules, so you can write them in any language that compiles to Wasm (the docs have tutorials for Rust, Go, Rego, C#, TypeScript and Swift). Policies are distributed through OCI registries, and an audit scanner keeps checking resources that already exist in the cluster.
One policy, two modes
The core of the talk was how they rolled policies out without breaking existing workloads. A slide titled âOur journey: Fine grained controlâ showed the setup:
- Helm charts generate all the objects they need.
- Each policy is generated in two variants: Monitor (used only for exceptions) and Protect.
- 7 internal policies and 12 public policies go through Helm templating into a single policy collection.
- Per-cluster values decide which variant applies where, for example âPolicy 1 â monitorâ, âPolicy 2 â protect project 1â and âPolicy 3 â protect all except namespace 2â.
In the clip I recorded, one of the speakers said they wrote some of the internal policies themselves, in Rego, because the public ones didnât cover everything they wanted to limit. Because the collection is a Helm chart, they can version it, test it automatically and apply different policy sets per cluster. He was also honest about the cost: a lot of Helm templating, which âgave us some nightmaresâ.
What worked best, according to the talk, was publishing the policy violations on dashboards. That raised awareness and increased ownership. The exceptions are documented and can always be challenged, because the dashboards, the policies and the exceptions are all visible.
Where ASMLâs platform stood at the time of the talk.
The âPromote and improveâ slide gave the scale:
- Running 120k pods per day
- 500+ Rancher projects in 26 clusters
- 1300+ namespaces
- Values for some clusters exceed 1000 lines of YAML
It ended with two lessons: âSome exceptions are here to stayâ and âImproved security awareness and ownershipâ.
My take: the monitor-first rollout is the part to copy. Turning on enforcement in an existing cluster on day one is how policy projects get cancelled. Run the same rule in audit mode, publish the violations, agree on exceptions in the open, then switch namespace by namespace. It works the same way with Kyvernoâs audit and enforce actions (see Kyverno graduating in the CNCF) or with Pod Security Admissionâs warn and audit modes. The 1000-line values files are the warning sign: per-cluster exceptions in Helm values grow until nobody wants to read them, so it is worth moving them into policy exception resources or a generated layer early.
Octopus Deploy: scaling up Argo CD for the enterprise
After the break, Kostis Kapelonis of Octopus Deploy presented âScaling up Argo CD for the Enterpriseâ. The title slide was made for this tour: âDutch Cloud Native Community, SeptemberâOctober 2025â.
Kostis Kapelonis opening âScaling up Argo CD for the Enterpriseâ.
He started with a show of hands, âWho is using Helm?â, and plenty of hands went up. My photos only catch a few of his slides, so here are the two that stuck with me.
Left: âAbusing CI as CDâ versus doing it âWith Argo CDâ. Right: what happens when someone asks for a new cluster.
âAbusing CI as CDâ compared three flows. In the first, the CI pipeline builds the image, pushes it to the registry and then applies it straight to the cluster. In the last, CI stops at the registry. A pull request updates the manifest in Git with the new image version, and the GitOps tool syncs Git with the cluster.
âNew cluster?â showed a fleet of clusters, each tagged by environment (non-prod or prod), cloud (AWS or GCP) and region: QA, Staging, Load Testing, US-East, US-West and EU. Then a âBrand new clusterâ with question marks in place of its tags, and an âAPPROVEDâ stamp. The question it raises: when the new cluster arrives, how does it get the right set of applications without someone copying YAML by hand?
My take: this is where Argo CD ApplicationSets with a cluster generator earn their place. If clusters carry labels for environment, cloud and region, a new cluster with the right labels picks up its applications automatically. I go through the building blocks in my Argo CD GitOps guide and in GitOps at scale with Flux and Argo CD.
The next morning: 2025 State of GitOps
On Tuesday morning I went to Octopus Deployâs breakfast session on the 2025 State of GitOps report, in a meeting room at Frame Offices in Hoofddorp. It was a small group around one table, which made it more of a discussion than a talk. Octopus published the full State of GitOps report in June 2025.
The survey base: 660 responses from 22 industries.
Who answered, and how GitOps was scored
The survey had 660 responses from 22 industries, worldwide and with a spread of experience levels. The session started from the four OpenGitOps principles (v1.0.0): declarative, versioned and immutable, pulled automatically and continuously reconciled.
How the report turns GitOps practices into a score.
The âScoring GitOpsâ slide explained the method. A GitOps score is built from six practices: declarative desired state, human-readable format, responsive code review, version control, automatic pull and continuous reconciliation. The report then tests the question handwritten on the slide: âDo these GitOps things make a difference to these DevOps things?â, meaning software delivery performance, reliability and wellbeing, which feed into organisational performance.
Tools and use cases
The âTools usedâ slide had two charts. For open source GitOps tools, Argo CD was at 50% and Flux at 11%. To the question âHow do you create infrastructure?â, answers were Terraform 67%, manual 37%, Crossplane 7%, Pulumi 7%, Bicep 3% and other 8%. More than a third still create some infrastructure by hand.
âWhat GitOps is used forâ asked which parts of an applicationâs configuration are stored in version-controlled files:
| Use | Share |
|---|---|
| Application or service deployments | 79% |
| Application configuration | 73% |
| Infrastructure | 57% |
| Environments | 49% |
| Runtimes | 40% |
| Database schemas | 38% |
| Cluster bootstrapping configuration | 35% |
| Secrets | 23% |
| Repository access rules | 18% |
| Management agents | 15% |
An âAdoptionâ chart showed the share of production systems using GitOps by organisation size, from 1â49 employees up to 10,000 or more. Each band had a wide range, and the averages didnât go up steadily with company size.
Benefits and DORA
Left: the benefits respondents reported. Right: GitOps scores against DORA software delivery performance.
The âGitOps benefitsâ slide listed:
- 81%: GitOps is more auditable
- 78%: GitOps prevents configuration drift
- 68%: compliance and audits are easier
- 66%: fewer people need elevated access
- 63%: GitOps increases security
The last slide I photographed was âGitOps and DORAâs 4 keysâ: âGitOps scores and DORA scores increase together.â The DORA score combines four metrics that represent throughput and stability, and the chart labelled the effect as rated âlargeâ. Octopusâs announcement of the report adds that 93% of organisations plan to continue or increase their GitOps adoption.
My take: the numbers Iâd bring to a steering committee are the 37% âmanualâ for infrastructure and the 23% for secrets. Most teams already deploy applications through Git. The gap is everything around the applications: infrastructure, secrets, access rules and the agents that run the platform. That is also how I lay out the levels in my GitOps maturity model. For secrets, start with the patterns in my Sealed Secrets and SOPS guide.
Two days, one theme
The two days fitted together well. ASML showed the policy side of a large platform: guardrails introduced gradually, with exceptions made visible. Octopus showed the delivery side, with Git as the source of truth for what runs where. The survey then put numbers on the claim both talks make, that teams following GitOps practices more closely deliver more reliably.
