Skip to main content

[Webinar] What it really takes to build an Internal Developer Platform with Backstage

· 37 min read
Lakmal Warusawithana
Lakmal Warusawithana
OpenChoreo Maintainer @ WSO2
Sameera Jayasoma
Sameera Jayasoma
OpenChoreo Maintainer @ WSO2

Key Takeaways​

  • IDPs exist to boost return on engineering investment: catalogs, golden paths, and self-service all serve that one goal, with developers as the primary consumer.

  • Backstage is a portal framework, not a full fix. It standardizes the developer portal (catalog, scaffolder templates, annotation-based integrations) but leaves teams to wire in their own tools and glue code.

  • The "messy middle" problem: as more tools get bolted onto Backstage over time, glue code and org-specific concepts pile up inside it, with no single system owning them making things hard to maintain.

  • The fix: a "platform contract" and control plane. Move Backstage, CLIs, and AI agents to the developer-experience layer, and push orchestration and abstractions into a control plane underneath so Backstage becomes a consumer of the platform, not the platform itself.

  • A control plane works like a cloud provider's: it sits above multiple data/workload/observability planes, can span clusters and providers, and stays stable even as the tools on top change, avoiding a full platform rebuild every time.

  • OpenChoreo is a CNCF Sandbox project built on Kubernetes CRDs/controllers, giving platform engineers ready-made, extensible abstractions and swappable modules, without locking teams into Backstage.

You can view the webinar here.

Transcript​

Introduction and the Role of Backstage 2:37​

Kelsey Hightower: Hey, welcome everybody. We're going to kick things off with the two gentlemen I've known for a little while, almost 10 years if I think back to our first interaction. When containers really got popular, Kubernetes started to get very popular. Everyone was in a rush to build platforms or figure out how to smooth out the rough edges in containerization and Docker. And I think the WSO2 team was one of the first companies to come out as a startup really tackling issues here. And I'm not surprised that over a decade later, they're still here. So I want to welcome Sameera to the stage, and Lakmal, and we're going to do a high-level deep dive, for those who aren't familiar with what Backstage is and how it's being used in real life. Then we'll get into how we think about a control plane sitting in between your IDP (the thing you put on the front end that you ask developers to use) and the backend. In this case, the backend is going to be your Kubernetes, CI/CD we're talking Jenkins, GitHub Actions. Lots of people have been building these self-service portals for a long time, but I think, where we are in 2026, there's a messy middle of functionality that maybe we can clean up. So, with that, Sameera, welcome to the stage, and let's kick off the presentation.

Sameera Jayasoma: Hello everyone. Thank you, Kelsey. I'm Sameera Jayasoma, one of the OpenChoreo maintainers and also a lead architect of the project. Let's start by talking about the highest goal of an IDP. I'm sure you know the value an IDP brings to your organization, I just want to start with this. The highest goal of an IDP is to increase the return on your engineering investment. Everything comes out of this. All the goals or the values of an IDP are part of that.

So at the center of IDPs, there are developers. They are the main consumers. Typically, platform engineers build this kind of platform with a product mindset. Platform teams apply product management principles and talk to their primary consumers, the developers, to understand their requirements. Those requirements can vary significantly from one organization to another.

Kelsey Hightower: I want to break this section down a little bit. Right now, these are very high-level ways of describing the problem. But the truth is, if you're a platform engineer, before that you were probably a DevOps engineer, and before that, maybe a system administrator. If we're being honest, you're often all three when the situation requires it. At a very high level, we've always been trying to solve the same problem: giving people a golden path for using the platforms and services available to them. For example, if you have VMware running and people can provision a VM directly through the VMware console, there are far too many options exposed. People can start creating storage volumes or even adding hosts, things you may not want them doing directly.

I remember some of my early experiences in this world of IDPs. Teams were building Ruby on Rails interfaces on top of their infrastructure. We've been doing this for a very long time. Now we have an official term for it: the internal developer platform, or IDP. I think Backstage is probably one of the most popular implementations of this kind of web portal. But I want people to keep one thing in mind: this isn't necessarily something new. It's something that has now risen to an industry standard, and we finally have a shared vocabulary around it.

When we look at these four things, those are the questions you would ask when you're on call: Is this thing broken? If you have 50 services, there's no way you're going to know how all of them work or how they're deployed. So you start asking questions like: How do I find these things? I need a catalog. How do I troubleshoot them while leaning on the previous experience of others? That's the kind of information we can bring into an IDP.

And I think it's safe to say Sameera that Backstage has kind of become like the golden standard over the last 10 years or so, where people have stopped building custom Ruby on Rail apps and now they're starting to use something similar. I think that's why Backstage and IDPs have become a big part of the lexicon of people managing infrastructure these days.

Backstage as a Developer Portal 8:11​

Sameera Jayasoma: Exactly. So, this is a sample Backstage screenshot. I'm sure you're familiar with Backstage, if you've used it, you've seen this. Pretty standard. So here you're seeing the catalog in Backstage. You're seeing all your services, who owns them, and what stage they're in. You can go into one of those to get more details. So this is sort of the day-one, or first, phase of a portal that you offer to your developers. As developers ourselves, we need more. So they come back with more requests. I went to Backstage Con Amsterdam this year, and there was a nice talk by booking.com where they explained their story. They gave the first version of the portal, and they named it something like "Backstage booking.com". Then there were more requests from their developers, so they did version two and named it "the engineering platform," to include everything that's part of engineering in their organization. That's a nice story if you want to look it up.

So what do you do? All these requests are asking you to do things on their own. In Backstage, you have the "scaffolder" concept: you can create templates and encapsulate your workflow orchestrations in them. Here's another screenshot of a simple version of this: it creates a repository and provisions a service entity in Backstage. Likewise, you can encode your organization's golden paths in Backstage.

Kelsey Hightower: Let me jump in here. There's a question I think is really timely for exactly where you are in the presentation: "If you already have a portal provided by the enterprise application, why would you need an additional portal? Isn't that going to add complexity?"

I think the idea here is that most people aren't starting from zero, we just talked about people either buying portals like this from a third party or building one themselves. Why would someone want to bring in something like Backstage? Isn't that just going to make it a bigger mess? I think you're starting to hint at that now, with the point that there are things a default portal won't do, like custom workflows and some of the things you're talking about adding via templates.

Sameera Jayasoma: Exactly. Backstage is designed as an internal developer portal framework, with the right abstractions and building blocks to design that portal. You can come up with these templates, and once you use one, it creates a web component or web app in the catalog.

So what you get, as a developer, is: I can see there's a web app and I'm now looking at one of those components in Backstage. You see the Overview tab, CI tab, and Kubernetes tab. In the Overview tab you might see basic elements like the GitHub repository and its state. In the CI tab you'll see all your CI runs, whether they succeeded or failed. In Kubernetes, you'll see the associated Kubernetes resources in the cluster tied to that web app. Likewise, you can integrate your platform tools into Backstage, that's nothing new. This is the standard Kubernetes plugin for Backstage; you can integrate it the way you integrate anything else in Backstage. Each entity in Backstage has a YAML representation, so this looks like a Kubernetes resource, but it isn't.

The only way to map all these integrations is via annotations in Backstage. I just want to explain this quickly so everyone's on the same page: you use annotations to connect your backend tools to entities in Backstage. The first is the GitHub CI/GitHub Actions annotation, when you add it, Backstage will call the GitHub Actions API and pull all the runs specific to that component. Similarly, there's a Kubernetes annotation: Backstage will use the Kubernetes API to find all the resources related to that component. You can bring in similar annotations for other tools if you want to integrate some third-party tool, you install that Backstage plugin, connect it, and it works. That's what Backstage is designed for. I've seen people maintain these files alongside the source repository, in the GitHub repo, or generate them on the fly from metadata in the organization. At that point, life is good.

Now, when you zoom out and look at what you've done over time, building up one integration request at a time, you end up seeing something like this: the overall system architecture with Backstage. As Kelsey said, you already have some platform tools configured, with certain workflows and orchestrations already running. When you bring in Backstage, you integrate all your tools into it to give a proper developer experience. And not only developer experience, now you also need to think about agent experience, and you can build a CLI on top of Backstage as well. There were two other talks at Backstage Con Amsterdam on this: one about agents talking to the Backstage API, and another about building CLI experiences on top of Backstage.

Kelsey Hightower: If you're looking at this diagram, this probably ties into a question I think is really key, the kind of responsible engineering question you should be asking. Don't just use Backstage because everyone else is using Backstage; that's probably not even true anyway. You have to make sure it works for you. The question is: "Why would embedded devs need it if there's no cloud deployment, no Kubernetes, just real hardware?"

I'll attempt to answer this one. When you look at Backstage sitting in the middle of this diagram, to the left side is like a CLI pointing at Backstage's API. You can imagine that being either real people or AI agents, it doesn't really matter. You can think of Backstage as this surface, this API that you expose. On the right-hand side of the diagram, you can consider all of these mostly cloud platforms, or maybe open-source platforms, that have their own API. But let's get to Denny's question: what if you just have bare-metal hardware? Say you bought a bunch of servers and PXE-boot them, and the only API you can really think of is, say, the operating system, let's say there's only Linux and SSH.

What value would Backstage provide in that scenario? I think the right way to think about it is: number one, you probably don't go around giving every developer, and maybe even every ops person, SSH access. If you did that, SSH becomes the API of your environment, and your developer IDP would be SSH and everything SSH could do; the entire shell space, every command, every system call. Then you'd have to figure out a way to lock down security. You could do it the way we used to: give everyone a Linux user, give them permissions on which files they can touch and which commands they can run but then that's your API, and your API is going to be huge. You could add more command-line tools if you want more functionality, little bash scripts or Python commands people can run. So that would be your interface.

Now say you get a call at 3 a.m. and you need to figure out how many apps this company has. Now we're moving away from just bare metal. This isn't really about real hardware versus virtual machines versus Kubernetes, you have to ask yourself, what is the software catalog? Do you want someone to run SSH and a for-loop and look through all the process tables? If you were to bring Backstage into that environment, still no Kubernetes, still no Docker, just bare-metal hardware, I could imagine you creating a plugin that catalogs all the processes running on your bare-metal servers and presents them as apps inside Backstage. Now you're giving one layer of abstraction above SSH.

And I think that's important for the rest of the talk today: Backstage is meant to be a flexible software-platform framework that lets you decide what your workflow is, what an "app" is, and articulate those things in a way that's easier to visualize and interact with than dropping down to SSH on the command line, the same way it prevents someone using Kubernetes from having to learn kubectl to interact with the platform. That's a key thing to remember: these tools let you, as a software or platform engineer, represent your engineering practice with just enough abstraction to make it easy to use.

When Backstage Becomes the Platform 18:50​

Sameera Jayasoma: As we discussed, Backstage is at the center of the platform in this architecture. It sort of becomes the single source of truth, and that's okay for some organizations, this is perfectly valid; there's nothing wrong with it. But when you analyze it, you see that you already have all your platform tooling, and then you bring in Backstage on top so it grows organically.

It may not have been designed that way from the start, but it grew: you add Backstage, add all the integrations, and it works. Whenever you have more integrations, you add more glue code into Backstage, that's the approach. For some organizations, this is a perfectly valid architecture; there's nothing wrong with that. But as you get more requests, there are costs associated with it. Let's talk about those briefly. First, this concept works great for the happy path, but whenever there's access to your developers for example, you may give kubectl access to your dev environment to figure out what's going wrong, same for the tools. Now, this is a challenge we've seen in the industry with portals like this.

The other point: it's true that Backstage is at the center, owning your components, systems, domains, and things like that. But a Backstage entity model may not be enough to represent all your organization's concepts and abstractions, and you may have some of those in your GitHub repo, some in other configuration files. This becomes unmanageable because there are multiple places to fix things if something goes wrong since no single system owns the concepts. That's the key part: Backstage is the front end, and it's a perfectly valid front end. But the challenge is whether you put everything in the front end and that's the question to ask.

Kelsey Hightower: There's a question around this area. I'd like to hear a different perspective. Do you see Backstage eventually becoming primarily a developer-experience layer over multiple autonomous platform capabilities, rather than being the platform itself? If so, what should companies avoid putting into Backstage?

The Messy Middle and the Platform Contract 21:38​

Sameera Jayasoma: I think that question is really valid. You end up bringing more and more glue code into Backstage, that's the third point. I call this architecture "the messy middle." You have all your underlying systems on one side and a Backstage portal on the other, with a lot of glue code in the middle, it might be TypeScript code in Backstage, or it might live in configuration files. So how can we improve this? Is there a way to address it? If you take one or two steps back, now that we're aware of the costs, what if we redesigned the platform and took a fresh look at this concept?

The fundamental idea here is exactly that: we can move Backstage to the developer-experience layer, and bring something new into the middle as part of the platform. Let's call it a "platform contract." Now Backstage moves from being the center of the platform to being a consumer of the platform, which I believe is the right architecture. Your agents, your CLI, and everything else now become consumers of the platform contract too. So the idea is: developer intent comes in from Backstage, an agent, or the CLI, and all the complex orchestration workflows are encoded in the contract layer, which integrates all these tools. It's not just glue code that lives in the platform contract, it's also the high-level concepts and abstractions.

Control Plane Abstractions and GitOps 24:12​

Kelsey Hightower: Now you're covering some of the more advanced questions, which I think are important here, I think we've laid some good groundwork. The next question is: "We're currently using Backstage for service provisioning. It worked flawlessly for about 95% of use cases following our golden path, but managing the exceptions requires significant manual effort. Any recommendations on how to get the abstraction right to better handle these edge cases?"

Before you jump into the answer and I think this matters for the transition into why you all built something like OpenChoreo and the concept you've introduced in this diagram, when we look at the platform contract, or even the idea of GitOps, there's a challenge: the idea that you can do GitOps for everything is tricky, mainly because some things are imperative rather than declarative, things like "start this run" or "restart this app." Those don't lend themselves well to a GitOps model, and you end up stepping outside of GitOps for command-and-control actions. If you try to force all of those interactions into a single UI like Backstage, it can get messy quickly. Should that be a standalone field, or part of the Backstage portal? Or do you want something that can act as command-and-control outside of Backstage, without that interaction being invisible to Backstage? I think that's the critical part, the concept of a control plane in this diagram.

Since Backstage became your "everything place," it starts getting messy when you try to do things Backstage isn't good at. So now Sameera is talking about this control plane, a simple concept: it's the place where we put the control loops and expose APIs that can then be driven by other tools, including an AI agent, a command-line tool, or Backstage itself. Maybe talk through the recommendations on getting the abstraction right, versus forcing everything into Backstage.

Sameera Jayasoma: As you said, Kelsey, the platform contract contains the glue code and the higher-level abstractions. At a high level, you have CRDs and controllers that act on those CRDs. The challenge is how you design the abstraction, how do you really abstract platform complexity away from developers? That takes time; it's what we've experienced at WSO2, which I think Lakmal will talk about in a few slides. With the platform contract, you analyze how developers in your organization think: are they using the concept of "application" and "microservices"? Are they using the concept of "projects" and "components"? Can a component have dependencies?

For example, think of a service as a simple microservice that can expose ports. It could be a web service, whether an HTTP port or a REST API. In this model, we represent them as endpoints, and components can expose endpoints. Endpoints can have visibility: public, organization-wide, or project-only.

Then you can declare dependencies between components, which gives you an understanding of the application architecture. You take the project and deploy it into an environment like dev, staging, production so there's a pipeline associated with it. These are the kinds of concepts you can extract from your organization's vocabulary. Once you have those concepts, you can build them as CRDs, write or generate controllers, and then let them use GitOps. That's the job of the control plane.

Kelsey Hightower: Let's skip forward so we make sure we get to the demo with ample time, I think we're getting exactly what we wanted to see, and people seem to get it. I think there are enough people with experience running Backstage in production to understand it's an amazing tool, especially if you've never had a good developer portal to expose your platform's capabilities. If you've gotten that far, congratulations, now we're talking about where to go from here. Thomas brings up a good point, so let's skip a couple of slides.

Thomas asks: "What do you think about the trade-offs between using Backstage's pre-built capabilities versus integrating Backstage with custom solutions? One thing I've found is that orgs prefer to implement their own database as the source of truth and source the catalog from that, for example. Another example would be backing Backstage software templates with a custom GitOps API to release applications, instead of using the software templates directly."

I think this speaks to the transition, so, Lakmal, let's bring you in and talk through that.

Implementing the Control Plane 30:22​

Sameera Jayasoma: Perfect. This basic diagram shows that it's not just a one-way compilation from intent to orchestration, we also need to tie platform observability back to the abstractions.

The second point is about the platform contract, and how the API layer manages the underlying complexity. Is there any structure we can bring into your platform tooling? The idea came from these "plane" concepts you've seen in the platform-engineering reference architecture. One thing you can consider is bringing structure: you can organize your tools into multiple planes: workload-related things in one plane, say a data plane, an observability plane, a workflow plane and then deploy each plane in a single cluster. You can mix and match.

The advantage of this is that it's now multi-cluster and multi-provider aware. You can have staging in one data plane and production in another data plane in another region, with one observability layer for production while staging has a lightweight observability layer. That's what this enables along with different lifecycles for each plane.

The next point is exactly what we talked about earlier: this control plane becomes an orchestrator, and it has the data model, a database in it, which drives the Backstage entity model, which relates to Thomas's question. The control plane knows the topology and can route the relevant information. We've talked about the architectural insight; now, how do you implement it? There are multiple approaches.

You can implement this yourself by writing your own CRDs and your own controllers. There are advantages and disadvantages to that; people can read the slides to understand more. The other option is to use a framework, like Crossplane. Crossplane is a wonderful project, and we're also using it under the hood: with it, you can design your vocabulary and implement it using XRDs and compositions, and it'll generate the mini controllers so you don't have to write code for most cases. The second option is to use an existing framework like OpenChoreo. There are many other frameworks that do this, and OpenChoreo is one example, which is the topic of today's webinar. OpenChoreo comes with its own set of abstractions, the platform contract is there, it's extensible, the controllers are there, and the return path, observability and everything is mapped back into the abstractions. I think Lakmal's demo will make that concrete. There are disadvantages to using a platform too, of course. On OpenChoreo: it's a CNCF project, Apache-licensed. We joined CNCF in January this year. With that, I'll hand off to Lakmal.

Kelsey Hightower: While Lakmal gets set up for his demo and shares his screen, Thomas, I think we've answered your question over the last five or six slides. The question really is: Backstage does a lot out of the box, and it's pretty good at what it does. We'll get into the other question that came up about ROI; how do you know this is even working, whether it's improving developer productivity, after the demo.

But on Thomas's question: I think the balance comes from knowing that a control plane in the middle lets you do anything you want, without the constraints of the framework getting in the way. Backstage became a little heavy in terms of what it does. If you can do everything in Backstage, great it's like using Heroku for deployments, and if that works for you, that's great. But if you need more functionality, you're probably going to need something a bit lower-level than fully opinionated. And with the control plane, again, you don't want to start from scratch. So, from those earlier slides: some people write everything as custom code and build their own control loops. Others like Kubernetes and tools like Crossplane, using it as a flexible API layer and implementing control loops the way they want. But then think about what's left if you go from that Crossplane approach to building out something with the nuance required for, say, multi-cluster orchestration. Maybe that's where Lakmal can shed some light, since the WSO2 team has gone through this transition over the last six or seven years. Lakmal, maybe start there.

How OpenChoreo Evolved 35:25​

Lakmal Warusawithana: Thanks, Kelsey. Like many of you, we've gone through this entire journey. Around 2022, we started by implementing our own IDP from scratch, we built our own portal. Backstage wasn't mainstream for us at that time, so we wrote our own.

Then, as more requests came in, we transitioned to a control-plane/data-plane separation, which let us run multiple data planes attached to a single control plane. Fast-forward to 2026: we realized that, without reinventing the wheel, we could use existing frameworks like Crossplane and CRDs. So we adopted the Kubernetes controller-loop and CRD approach, and we also use Crossplane for some use cases. We turned platform intent into declarative definitions, and Kubernetes control loops make sure the actual state converges to the desired state. While doing this, we thought: why not open-source it? That's how it became OpenChoreo.

OpenChoreo was donated to the CNCF in January this year. As of this webinar, we're on the 1.2 release. This is the current OpenChoreo architecture: there's a control plane exposing APIs to the experience layer, and Backstage is one consumer of that. We also expose MCP servers, since many people are looking at agentic experiences, the same capabilities are exposed to agents, but because of this abstraction layer, agents follow the same golden path rather than getting direct access to the infrastructure layer. We also have data planes, an observability plane, and workload planes. Within these planes, you can bring in different capabilities using different tooling.

We faced a situation many of you may face too: we didn't want to tie the platform to a single vendor or tool. So we introduced a module concept. For example, observability can be provided by different modules: OpenSearch, another observability backend, or even a cloud provider's observability stack. The experience layer isn't tied to one specific implementation. This is what you get when you install OpenChoreo.

A Stable Control Plane for Changing Interfaces 38:57​

Kelsey Hightower: This is a good chance to remind people where we are in this evolution. We talked about being a system administrator writing shell scripts; if you were in DevOps, maybe using configuration management - Chef, Puppet, or Ansible to expose capabilities; and then in platform engineering, getting your feet wet with things like Docker, Kubernetes, and Backstage as a portal. What's been missing from that equation is probably what the big cloud providers have been doing for the last 10 years, which is the control plane.

If you think about what a cloud provider does, it's mostly a control plane backed by different compute and data planes under the hood. So if you were using Terraform, you're hitting the cloud provider's control plane. If you were using Crossplane, you're hitting the cloud provider's control plane.

Now that people are starting to run clusters with the same type of services whether an open-source equivalent, or just a proxy to configure the cloud provider, you're sitting on your own data plane. That could be Postgres, Redis, Kubernetes, or Prometheus. Either way, you now find yourself with a bunch of these workflow engines, each with their own APIs, and we've been trying to glue those directly into things like Kubernetes or Backstage.

I think what we're advocating for right now is that there should be a control plane to really round out this maturity curve. Meaning, when you build these control loops, one thing we haven't even talked about today is things like billing and permissions across all these stacks. That's hard to do if you were to bolt all of this into, say, Backstage. But here's the inevitable truth: one day someone's going to build something that disrupts or replaces Backstage, and you'll find yourself rebuilding all of this again for the 50th time realizing that a control plane can stay stable regardless of the surface people use to interact with it.

Today that surface could be Terraform. On the experience-plane side, you can see GitHub Copilot, Gemini, Claude Code, Cursor, and of course things like Backstage too, that's never going to stop. So, to make sure our work survives these transitions: if we invest in a control plane and decouple ourselves from both the left and right sides of this equation, the middle can evolve at its own pace. As trends change, you don't have to go back and rewrite everything. I think that's the only way we're going to be able to do this, not just at the scale of lots of people using our platform, but at the scale of learning new things without having to throw everything out and start over just because a new tool showed up. I hope that's a big takeaway on why you might want to start thinking about a control plane, rather than chasing the latest and greatest new tool or platform**.**

OpenChoreo Demo and Application Model 41:43​

Lakmal Warusawithana: Exactly. Now that we've looked at the architecture diagrams, let's look at the actual implementation. For this demo, I have OpenChoreo set up in a single AWS Kubernetes cluster. In the OpenChoreo control plane, you can see Backstage, the cluster gateway, controllers, and different control modules running, plus a data plane with APIs.

Likewise, the environment has the relevant agents and controllers within the different planes. If you're interested in the CRDs, this is how the OpenChoreo APIs are defined, you can find more detail there. Now let me show how Backstage becomes more powerful when connected to the OpenChoreo control plane. Before that, I'd like to walk through a sample application. This sample is a Google Docs-style app: you can create a new document, type something, and share it with other people. Here's the Git repository, there's a frontend, a document service, a collaboration service, and a persistence layer. That's the architecture we want to build. As a developer, if you want to deploy this application, one option is to give OpenChoreo a declarative YAML. You can also use the UI portal or an agent-based experience. At the project level, OpenChoreo has a Project abstraction for grouping multiple components. The project can also reference a build pipeline for example, the default pipeline.

If I go into one of the services, you'll see I'm again using an OpenChoreo abstraction. Platform engineers can define different shapes of components and expose them to developers. Here I'm using a component type called "Service" and a build workflow called "Docker Builder," because I'm passing a Dockerfile, it can also work from source code. This is where you give the source repository, and this section wires up dependencies: the service can depend on another resource. As Sameera mentioned, it also exposes endpoints; port, protocol type, and visibility. I'll explain the visibility mapping when I show Backstage.

Custom Component Types and Backstage Integration 45:49​

Kelsey Hightower: So there are a lot of objects that come out of the box in the OpenChoreo namespace. We don't need to go through all of these configs, but it's nice to see how much comes out of the box. There are probably two questions this raises for people seeing it for the first time. One: some people say, "I don't want a PaaS, I don't want a Heroku situation where I have to deploy things a certain way." We saw questions earlier in the chat along the lines of: "I don't want to be locked into your templates versus being able to create custom stuff, I don't want to get stuck again the way I got stuck in Backstage or another tool." So the first question is: can I make my own types, my own workflows, that I can bundle into something like OpenChoreo and expose through Backstage?

Lakmal Warusawithana: Exactly, that's one of the design goals of OpenChoreo. Let me jump into Backstage and show how a platform engineer can create custom component types. Backstage in this model isn't only for developers; platform engineers can use it too. They can define their own YAML, or use the OpenChoreo UI, to create the shape of a component or abstraction. We want to give platform engineers that flexibility.

Another thing: Backstage becomes more powerful when connected to OpenChoreo. You can use the OpenChoreo Backstage setup, which is compatible with upstream Backstage, or use your own Backstage instance and integrate the OpenChoreo modules either way works.

For example, take the same application: if I provide the YAMLs to create it, this is the project you get in the Backstage portal. You can see the services and resources and how they interact Backstage shows the relationships between the components. OpenChoreo also provides this visualization, and it's not hardcoded; it's generated from the YAMLs you provided. It shows how the components connect and communicate, and the cell isn't just a visualization, it has runtime meaning. When you deploy the project into an OpenChoreo data plane, it creates a separate namespace in Kubernetes and applies network policies around that namespace, so arbitrary services can't talk to these services, they have to come through a gateway defined by the application model. This is where endpoint visibility matters: depending on whether visibility is external, organization-wide, or project-level, the platform controls how the endpoint is exposed.

For one of the components, a developer can see its definition from the GitHub repository and all its builds. The workflow is defined by the platform engineer, if they want to add container scanning, they can add it. If a developer wants to promote the service to an upper environment, there's a self-service capability: they can promote it and apply environment overrides, such as different variables. If they want to debug it, they can see logs within the portal itself, everything's aggregated there. Even Kubernetes events are filtered and shown only when they relate to that particular service, without exposing the entire Kubernetes cluster. Some enterprises don't want to give developers direct Kubernetes or kubectl access.

From OpenChoreo CRDs to Kubernetes Primitives 50:52​

Kelsey Hightower: This is a good place to jump in with a question. I think you've already answered part of it, but I'll read the whole thing and cover anything we missed in the demo: "The OpenChoreo controller would be able to deploy the app on the cluster through its own logic, converting these custom CRD objects into Kubernetes primitive objects" that's question one, and I think you've shown that. When you create these CRDs, they translate downstream into the appropriate platform primitives. If it's Kubernetes, you'd get Deployments, Services, and NetworkPolicies; if it were something like Argo CD, whatever's necessary for that, is that exactly how it works, even for custom ones I create myself?

Lakmal Warusawithana: Exactly. As a developer, we provide the component YAML, and OpenChoreo converts it into Kubernetes primitives. For this frontend, you can see ConfigMaps, a Deployment, an HTTPRoute, a Service, and network policies, we use Cilium. The mapping is defined by the platform engineer when they define the component type, they decide which underlying resources get created when a developer uses that type. We're also not trying to hide Kubernetes completely: if a developer needs more advanced troubleshooting, the platform engineer can allow controlled access to lower-level information, or a terminal. Again, we're not giving unrestricted kubectl access, we're giving a terminal through the platform. You can also do more advanced network troubleshooting and inspect traffic to and from a particular service, without exposing the entire cluster network.

Actionable Portals and Multi-Environment Deployments 53:25​

Lakmal Warusawithana: The idea is that it's not just a portal anymore, it becomes an actionable portal. Developers and platform engineers can perform various actions within the portal itself.

Kelsey Hightower: All right, given that we have six minutes left, I think you've covered a lot and answered a lot of these questions through the demo, so we'll skip ahead a bit, but stick with this one more. The second part of that question: I'm curious about multi-environment deployments, should we maintain multiple resources for dev, QA, and prod? I think this gets at the reason we want the control plane to be moved out-of-band: we want something that doesn't live in one cluster, doesn't live in the UI, but sits in the middle so it can orchestrate. So my guess is the answer is: whether you use multiple resources or not, whether you use something like Argo CD to manage the promotion process or not, whether you move this across multiple independent clusters, regions, zones, or even cloud providers, all of that becomes possible because the control plane sits in the middle and doesn't prioritize any one cluster over another. Is that the right way to think about it?

Lakmal Warusawithana: Exactly. That's how the topology is defined, you can have production in one Kubernetes environment and non-production in another. OpenChoreo can orchestrate across multiple clusters. From the platform engineer's view, you can see how the resources are wired together. In this example, I only have one data plane, which is one Kubernetes cluster; if you have multiple clusters, they appear as additional clusters. You can create different environments inside those clusters and wire up your pipeline. It can be a single Kubernetes cluster or a multi-cluster setup, because the abstraction and orchestration logic live in the control plane.

Bring Your Own Portal and Swap Backends 55:43​

Kelsey Hightower: All right, given we have four minutes left, we're going to speed up, I think you'll need to do a follow-up session. It's clear you can wire all these components together and create custom pipelines, so let's do just a couple more questions before we hand it off to the platform-engineering team. The call to action here: if you like what you see, this project has been donated to the CNCF, scan that QR code, or get the URL from what we've shown today.

A couple more questions to round us out. One: "Can you just skip Backstage entirely?" Yes, you can, you can bring your own portal.

The other big question, I think, has an obvious answer: "Do you have the ability to swap out any tools you like Flux CD, Argo CD, and so on?" I'll preface this: for everyone who thinks all of this is hot-swappable, if we've learned anything from the configuration-management world, there's no such thing as a VM that works exactly the same way across all cloud providers. Maybe you get 10 out of a thousand fields to match. The idea that Argo CD is going to work exactly like GitHub Actions isn't the right way to think about it. But there's a world where "deployment" backed by GitHub Actions can mean something different from "deployment" backed by Argo CD. That matters because most platforms evolve over time, you usually don't hot-swap anything wholesale. If you're adopting GitHub Actions alongside Jenkins, you're probably running both at the same time, giving people the ability to choose the deployment backend, rather than a wholesale swap-and-replace, since they'll never have one-to-one functionality unless you write a bunch of custom code to bridge the difference between the two. Do either of you want to add anything?

Standards and Abstractions 57:59​

Lakmal Warusawithana: Yes. We have an ecosystem page with different modules and agents. The API layer abstracts the capabilities for something like observability, you can swap backends without changing the experience layer, because the experience layer talks to the API abstraction.

Kelsey Hightower: What a great world we live in, where we have standards like S3, letting you swap out storage layers as long as they support the S3 protocol. Similarly, with things like OpenTelemetry or logging standards, you can swap backends because a lot of these tools share industry-standard APIs. I think we're getting close to the end here, this was amazing, and you can tell there's a bit of excitement, plus the fact that there were so many questions in real time is exactly what you want from a webinar. It means people get it. I think you did a good job explaining this, and hopefully people will want to dig into the details further. Again, go check out OpenChoreo on the website.

Get Started with OpenChoreo​

OpenChoreo is open source and free to use. The best next step is to try it yourself.