diff --git a/adrs/2026-01-05-flux.md b/adrs/2026-01-05-flux.md
new file mode 100644
index 0000000..00e3063
--- /dev/null
+++ b/adrs/2026-01-05-flux.md
@@ -0,0 +1,86 @@
+---
+authors:
+  - ReneSchuenemann
+---
+
+# Flux Service Provider
+
+For the OpenMCP architecture there is a need for a Service Provider `Flux`.
+Flux is a popular GitOps tool for Kubernetes, which can be used to manage the deployment of applications and infrastructure in a declarative way.
+Flux will be used by OpenMCP users on their Managed Control Plane clusters to deploy and manage their workloads.
+It is also desirable by other Service Providers to have Flux available on the Managed Control Plane clusters to manage their own workloads.
+
+## Context and Problem Statement
+
+Service Providers that want to deploy their workload on the Managed Control Plane clusters need a way to do so in a consistent and manageable way. Especially when using Helm charts, Flux can provide a powerful solution for managing the deployment and lifecycle of these workloads.
+Instead of managing the lifecycle of their workloads manually, Service Providers can leverage Flux to automate the deployment and management of their workloads. They would only need to deploy a `HelmRelease` resource to the Managed Control Plane cluster, and Flux would take care of the rest.
+However, relying on Flux by a Service Provider to manage their workloads introduces an implicit dependency on the Flux Service Provider being available and functioning correctly.
+
+We have currently identified 3 options for Service Providers to manage their workloads on the Managed Control Plane clusters:
+
+* Option 1: Each Service Provider deploys Helm charts without using Flux.
+* Option 2: Implicit dependency on Flux: Service Providers use Flux to manage their workloads, assuming that the Flux Service Provider is always available.
+* Option 3: Flux as a Platform Service
+* Option 4: Using the "central" Flux instance running on the Platform Cluster to manage workloads on Managed Control Plane clusters.
+
+## Option 1: Each Service Provider deploys Helm charts without using Flux.
+
+Service Providers manage the deployment of their workloads on the Managed Control Plane clusters manually, without relying on Flux.
+Either by using a golang Helm client library or by applying manifest files directly to the Managed Control Plane cluster.
+
+Advantages:
+
+* No dependency on Flux Service Provider.
+* Service Providers have full control over their deployments.
+
+Disadvantages:
+
+* Service Providers need to manage the lifecycle of their workloads manually.
+* Inconsistent deployment methods across different Service Providers.
+* Increased operational overhead for Service Providers.
+
+## Option 2: Implicit dependency on Flux: Service Providers use Flux to manage their workloads, assuming that the Flux Service Provider is always available.
+
+Users will need to manually enable the Flux Service Provider on their Managed Control Plane cluster before other Service Providers can use Flux to manage their workloads.
+This means that the Flux Service Provider must be deployed and running on the Managed Control Plane cluster for other Service Providers to use Flux without enforcing the dependency explicitly.
+
+Advantages:
+
+* Service Providers can leverage Flux for managing their workloads.
+* Reduced operational overhead for Service Providers.
+
+Disadvantages:
+
+* Implicit dependency on Flux Service Provider being available and functioning correctly.
+* If Flux Service Provider is unavailable, Service Providers can't manage their workloads.
+
+## Option 3: Flux as a Platform Service
+
+In this option, Flux is provided as a Platform Service. This means that the platform service `Flux` watches for any `Cluster` with the purpose `MCP` existing on the platform cluster. For each such `Cluster`, the Flux service provisions a dedicated Flux instance on the Managed Control Plane cluster. This dedicated Flux instance is then used by Service Providers to manage their workloads on that specific Managed Control Plane cluster.
+
+Advantages:
+
+* Dedicated Flux instance for each Managed Control Plane cluster, ensuring isolation and independence.
+* Service Providers can use Flux to manage their workloads without worrying about the availability of a shared Flux instance.
+* Consistent deployment method across different Service Providers.
+* Reduced operational overhead for Service Providers.
+
+Disadvantages:
+
+* Users have no control over the version of Flux used on their Managed Control Plane cluster.
+
+## Option 4: Using the "central" Flux instance running on the Platform Cluster to manage workloads on Managed Control Plane clusters.
+
+In this option, the Flux instance running on the Platform Cluster is used to manage workloads on all Managed Control Plane clusters. Service Providers would deploy their `HelmRelease` resources to the Platform Cluster's Flux instance, which would then synchronize the workloads to the respective Managed Control Plane clusters.
+
+Advantages:
+
+* Centralized management of workloads across all Managed Control Plane clusters.
+* Reduced resource consumption, as only one Flux instance is needed.
+
+Disadvantages:
+
+* Potential performance bottlenecks, as the central Flux instance needs to manage workloads across multiple clusters.
+* Increased complexity in managing and troubleshooting deployments, as issues may arise from the central Flux instance affecting multiple Managed Control Plane clusters.
+* Lack of isolation between Managed Control Plane clusters, which may lead to security and stability concerns.
+* Users have no control over the version of Flux used on their Managed Control Plane cluster.