---
title: "monedula-gitops"
repo: https://github.com/monedula-dev/monedula-gitops
language: Go
license: AGPL-3.0
status: active
maintainers: ["grzegorz", "michal"]
---> **Companion post:** [Monedula GitOps: Declarative Kafka Management for CLI and Kubernetes](/blog/monedula-gitops/) introduces the `v0.1.0` release, the resource model, and the basic workflow.

## Why

Kafka configuration rarely lives in one place. Topics come from one script,
ACLs from another, schemas from application pipelines, quotas from an
administrator, and Confluent RBAC role bindings from yet another tool. Over
time the live cluster becomes the only reliable description of the system —
but not an intentional or reviewable one.

`monedula-gitops` makes that description explicit: describe the desired Kafka
state in Git, review it like code, compare it with the live cluster, and
converge the cluster toward it.

Kafka is not only about topics, so the model covers the resources that
usually belong together — access rules, consumer groups, quotas, schemas,
credentials, and, on Confluent Platform, RBAC role bindings.

## One model, two runtimes

The CLI and the Kubernetes operator use the same resource model and the same
reconciliation engine.

- **CLI** — validate, diff, apply, and verify manifests from a developer
  machine or a CI/CD pipeline. `verify` returns a non-zero exit code when
  drift is found, so it works as a CI gate.
- **Operator** — install the same Kubernetes-style resources as CRDs and
  reconcile them continuously inside a cluster.

Credentials are supplied differently in each runtime — environment or file
references for the CLI, Kubernetes Secrets for the operator — but the desired
state, drift rules, and execution semantics stay consistent. A team can start
with pipeline-driven changes and adopt the operator later without designing a
second configuration model.

## What it manages

`KafkaCluster` (connection, authentication, defaults, Schema Registry,
optional Confluent MDS), `KafkaTopic` (lifecycle, partitions, configuration,
topic-local access, schemas), `KafkaAccessPolicy` (advanced and shared ACL
rules), `KafkaQuota` (user, client-id, and IP quotas), `KafkaUser` (SCRAM
credentials), and `KafkaRoleBinding` (Confluent MDS/RBAC).

The common case stays small — a topic and the applications allowed to use it
fit in one manifest, and the matching topic and consumer-group ACLs are
generated from it:

```yaml
apiVersion: gitops.monedula.dev/v1alpha1
kind: KafkaTopic
metadata:
  name: orders
spec:
  clusterRef:
    name: prod
  topicName: orders
  partitions: 6
  access:
    producers:
      - principal: User:svc-checkout
    consumers:
      - principal: User:svc-fraud
        group: fraud-orders
```

## Install

```bash
brew install monedula-dev/tap/monedula-gitops
```

Also available via `go install`, as prebuilt binaries from the GitHub
releases, and as a container image at `ghcr.io/monedula-dev/monedula-gitops`.
The operator installs with Helm from
`oci://ghcr.io/monedula-dev/charts/monedula-gitops`.

## Start from an existing cluster

Real environments are rarely empty, so `import cluster` reads the current
Kafka state and generates manifests from it — topics, access rules, quotas,
schemas, SCRAM users, and Confluent RBAC role bindings where supported. The
round trip is the point: verifying the imported directory against the same
cluster should report no drift.

Risky operations are guarded, and deletion and pruning require explicit
opt-in. Two runnable quickstarts (a Docker Compose CLI playground and an
operator playground on local Kubernetes) and a catalog of 25 self-contained
scenarios live in the repo.