Design Document: Deploy Service Provider as Platform Service

[maximiliantech]

Understand the problem

In our openMCP ecosystem, we have the concepts around Cluster Providers, Service Providers and Platform Services. Each of these providers serve a different use case in our platform ecosystem.

There are several tools, were one could argue that we would need both Service Providers and Platform Services for it.
Examples:

• Flux
• ESO
• metrics-operator
• cert-manager
• Velero
• custom root CA service

We all agree that it would not make sense to build for each tool a Service Provider AND a Platform Service since the only difference would be the deployment of the operator and its CRDs.

Context

We should work on a design document that covers this case. Let's think how we can best include this use case in our ManagedControlPlane offering.

💡 An idea would be to run a Service Provider as Platform Service. We would reuse the Service Provider image but deploy this image as Platform Service.
It could look like this:

apiVersion: openmcp.cloud/v1alpha1
kind: PlatformService
metadata:
  name: eso
spec:
  image: ghcr.io/openmcp-project/images/service-provider-eso:v1.0.0

Through some configuration in the Platform Service or via environment variables, we could configure the provider the way we want to deploy and run the image (CRDs end up in the platform cluster as well as the provider pod).

We should dig a little bit deeper of how this can be achieved since Flux would be right now the only open source tool where we would foresee a chicken-and-egg-problem and where this concept might not be suitable (which is okay as well).

❗ IMPORTANT: This task would be just the first task to document the overall idea of the concept. Naturally, out of this design document more tasks would follow to determine concrete implementation work.

Proposal Acceptance Criteria

• Agree on a concept in the core developer round
• Write down concept as design document in our open source documentation

How much traction does this feature have?

There is an intrinsic motivation from core development team to solve this problem to further strengthen the concepts and the flexibility of our openMCP ecosystem.

[maximiliantech]

After a quick initial discussion in the core developer round, we agreed that this is not the most pressing topic at the moment for Q4/25. Let's get back to this in Q1/26.

Right now most of the tools that our platform cluster needs to operate is part of the bootstrapper tooling:

• Flux
• ESO