Every platform decision is a bet on the future. When you choose the tools your organisation will run on, you're not just choosing features. You're choosing who controls your upgrade path, who you're dependent on when things break, and how much leverage you have when the contract comes up for renewal.
We build the GoldenPath IDP on CNCF tools: Kubernetes, ArgoCD, Backstage, Kyverno, Prometheus, Grafana, cert-manager, External Secrets Operator. That's not an accident or a cost decision. It's a deliberate platform strategy.
Here's the reasoning.
Strong Communities Mean Stronger Software
The CNCF (Cloud Native Computing Foundation) has a project lifecycle: Sandbox, Incubating, Graduated. Graduation isn't marketing. It's a community confidence vote. A project reaches Graduated status by demonstrating production adoption, a healthy contributor base, a clear governance model, and a track record of security response.
Kubernetes is Graduated. ArgoCD is Graduated. Backstage is Graduated. Prometheus is Graduated.
When you adopt a Graduated CNCF project, you're not making a bet on one company's product roadmap. You're standing on the shoulders of hundreds of contributors at organisations like Google, Red Hat, Spotify, CERN, and Airbnb, all of whom have production-tested this software and have skin in the game to keep it good.
I've seen what happens when that community disappears. Tools built by single vendors get acquired, deprioritised, or abandoned. The community-governed alternative is still there five years later, better than when you first adopted it.
Portability Is Not a Nice-to-Have
Your platform team's output should not be tied to the platform you bought it from.
CNCF tools run on AWS, GCP, Azure, bare metal, and on your laptop. ArgoCD doesn't care which cloud your Kubernetes cluster is on. Kyverno policies work identically across environments. Prometheus scrapes metrics the same way whether you're on EKS or GKE.
When you build your platform on proprietary tooling (even very good proprietary tooling), you create a coupling that compounds quietly. The workflows your team learns are specific to that product. The integrations are specific to that product. The escape hatch, when you need it, is expensive and slow.
We've seen this pattern at scale. At Conde Nast, managing production Kubernetes clusters across eight countries for brands like Vogue and GQ, portability wasn't theoretical. It meant we could move workloads, change cloud providers, and evolve our infrastructure without renegotiating the foundations every time.
Try Before You Commit
Kubernetes is free to run locally. Backstage ships as a Docker image you can have running in twenty minutes. Kyverno policies can be tested against your manifests before they ever touch a cluster. Prometheus scrapes whatever you point it at.
The entire CNCF ecosystem operates on the principle that you can prototype before you commit, validate before you invest, and learn the tool before you pay for support.
This matters enormously for platform decisions. Platform choices are long-lived. You don't rebuild your IDP every year. Getting it right requires experimentation. Experimentation requires the ability to fail cheaply.
With open source CNCF tools, you can build a proof of concept over a weekend that's architecturally identical to what you'd run in production. The only thing that changes at scale is the infrastructure underneath it.
Try doing that with a platform that requires a sales call to get access.
Integration Is by Design, Not by Contract
CNCF projects are designed to compose. ArgoCD, Backstage, Kyverno, External Secrets Operator, cert-manager, Prometheus. They are designed with the same underlying model: Kubernetes resources, declarative configuration, watch-reconcile patterns. They speak the same language.
When ArgoCD deploys a workload, Kyverno validates it on admission. When a new service is deployed, Backstage picks it up from the catalog. When a certificate is requested, cert-manager provisions it. Prometheus scrapes whatever exposes a /metrics endpoint. Each of these integrations is powered by the operator pattern, the mechanism that makes Kubernetes composable.
None of this required negotiating integration contracts between vendors. It works because CNCF projects are designed to be composable in a shared ecosystem.
Proprietary platform tooling offers integrations too, but those integrations are maintained by the vendor, on the vendor's timeline, with the vendor's priorities. In the CNCF ecosystem, if an integration is missing, someone in the community usually builds it. If they don't, you can.
CNCF Has Defined What a Platform Needs
This isn't just a philosophy. CNCF's TAG App Delivery published a Platforms White Paper that defines exactly what a mature internal platform should provide, not as a vendor specification, but as community consensus from the practitioners who build and operate these systems at scale.
The paper defines thirteen capability areas, each one mapping to specific CNCF and CDF projects designed to fill it. This table is the industry's closest thing to an authoritative blueprint for what a platform should do. We've covered what this whitepaper means for engineering teams in depth separately:
What this table makes clear is that the CNCF ecosystem doesn't just provide individual tools. It provides a complete vocabulary for platform engineering. Every capability area an engineering organisation needs is covered by community-governed, production-tested projects.
GoldenPath is built against this framework. Backstage covers the portal and service catalog layer. Kubernetes and Helm handle provisioning APIs. ArgoCD handles delivery and verification. Prometheus and Grafana handle observability. Kyverno handles security policy. Keycloak, External Secrets Operator, and cert-manager handle identity and secrets. GitHub Actions handles build and test automation.
None of those choices are arbitrary. They're the CNCF community's answer to what each capability area requires, and they compose because they were designed to.
Contribution Makes You Part of Something Bigger
This one is underrated.
When your platform is built on open source tools, your engineers can contribute back. A bug fix your team writes can end up in the upstream project, benefitting thousands of organisations. A feature your team needs can become part of the roadmap. A pattern your team develops can become a blog post, a conference talk, or a reference architecture.
That's not charity. It's compound interest. The practitioners who contribute to CNCF projects develop deeper expertise than those who consume proprietary tools. They understand the internals. They know the community. They have credibility that comes from doing, not just using.
At Scaletific, building on CNCF tools means every piece of expertise we develop is portable, shareable, and compounds into the broader ecosystem. It also means the organisations we work with don't end up dependent on Scaletific any more than they'd end up dependent on Kubernetes. We build capability into teams. We don't create lock-in.
The Honest Counter-Argument
Proprietary platform tooling isn't wrong. For some organisations, a managed abstraction that handles the complexity for you is the right call, at least initially. Getting something working fast, with less expertise required, has genuine value.
The question is what happens next.
When you outgrow the abstraction, when your requirements diverge from what the vendor has prioritised, when the pricing no longer makes sense at your scale, or when the vendor gets acquired: what's your exit?
With CNCF tools, your exit is almost always "migrate to a slightly different configuration of the same open source stack." With proprietary tooling, your exit is often "rebuild from scratch."
That asymmetry is worth thinking about before the first platform decision is made, not after the third vendor contract renewal.
What This Looks Like in Practice
The GoldenPath IDP is built entirely on CNCF and open source tools. Not because we had a philosophical commitment to open source, but because after eight years of building and running production platforms, we concluded it's the most defensible architecture.
Every capability in the platform maps to a Graduated or Incubating CNCF project. Every integration is composable. Every tool can be run locally for development. Every policy can be read, understood, and modified by the team that owns it.
That's not idealism. That's what ownership looks like. For a deeper look at how platforms, operators, and AI intelligence work together as a unified model, see Unifying Platforms, AI, and Operators.
Scaletific builds production-grade Internal Developer Platforms on CNCF-native tooling. Talk to us about your platform.