How Jikkou Compares

• 1: Jikkou vs Terraform for Apache Kafka
• 2: Jikkou vs Strimzi Topic Operator

1 - Jikkou vs Terraform for Apache Kafka

The state-file problem

Terraform trusts its state file. Kafka clusters do not stay in sync with state files.

A concrete scenario every Kafka team knows: during an incident, an engineer bumps retention.ms on a production topic with a vendor UI or kafka-configs.sh. The incident ends, the change stays. Terraform’s state file still holds the old value, so terraform plan shows no drift unless someone remembers to run a targeted refresh, and even then, resources created outside Terraform are invisible until they are painstakingly imported.

Jikkou is stateless by design. There is no state file to protect, migrate, or unlock. Every jikkou diff compares your Git-versioned YAML against the actual cluster state:

$ jikkou diff --files ./topics/

Out-of-band changes show up immediately as a diff. Reverting them is jikkou apply. Detecting them continuously is a scheduled CI job.

Managing 300 topics

Kafka estates are repetitive: hundreds of topics that differ by a name and one or two values.

In HCL, this becomes a for_each over a variables map: a second, more abstract configuration language on top of the first, and every exception to the pattern makes the map grow warts.

Jikkou treats templating as a first-class concern with Jinja templates and per-environment values files:

apiVersion: "kafka.jikkou.io/v1beta2"
kind: "KafkaTopicList"
items:
{% for domain in values.domains %}
  - metadata:
      name: "{{ domain.name }}-events"
    spec:
      partitions: {{ domain.partitions | default(6) }}
      replicas: 3
      configs:
        min.insync.replicas: 2
{% endfor %}

The same definitions apply to every environment (local Docker, ephemeral CI clusters, staging, production) with different values files. And built-in validations enforce your platform rules (naming conventions, minimum replication factor, partition limits) on every change before it reaches a cluster.

Coverage

One Jikkou model covers on-premises Kafka, Confluent Cloud, Aiven, Amazon MSK, and Redpanda, with the same YAML resources everywhere.

When Terraform is the right choice

Honesty matters here:

• Provisioning infrastructure. Creating the Kafka cluster itself, VPC peering, service accounts, API keys: that is Terraform’s home turf.
• All-in on Confluent. If you run exclusively on Confluent Platform or Confluent Cloud, the confluentinc/confluent provider is mature and usually the natural first choice. Jikkou becomes more interesting when the problem is ongoing governance across clusters and providers.
• Org-wide IaC standardization. If your organization enforces every change through Terraform with policy-as-code tooling around it, adding a second tool has a real cost. Weigh it.
• Everything-in-one-graph needs. If topic creation must be atomically tied to the services that consume them inside one dependency graph, Terraform’s model fits better.

Better together

The pattern we see most often in production:

1. Terraform provisions the platform: clusters, networking, credentials.
2. Jikkou manages what lives inside: topics, ACLs, quotas, schemas, and connectors, owned by the platform team, changed through pull requests, applied by CI, drift-checked on a schedule.

GitOps without handing out cluster credentials

A workflow used in production today: each team keeps its resource definitions (topics, schemas) in its own Git repository. A pull request opens the change; jikkou diff generates a reviewable patch of exactly what would be applied; once merged, a GitHub Action (see setup-jikkou) applies it.

And because Jikkou also ships as a REST API server, your CI never needs direct access to the Kafka cluster: the CLI talks to the Jikkou API (optionally behind your API gateway), and only the server holds cluster credentials. Teams self-serve their resources through pull requests; no central ticket queue, no shared admin credentials.

Migrate in 10 minutes

Jikkou can export your existing cluster state as YAML. No manual imports, no state surgery:

# Export current topics into Git
jikkou get kafka topics -o YAML > topics.yaml

# Export ACLs and quotas too
jikkou get kafka acls -o YAML > acls.yaml
jikkou get kafka client-quotas -o YAML > quotas.yaml

# Review, commit, and from now on: preview every change
jikkou diff --files .

From there, wire jikkou diff into pull requests and jikkou apply into your main-branch pipeline. See the how-to guides.

Next steps

• Install Jikkou
• Jikkou vs Strimzi Topic Operator
• Questions? Join the Slack community

2 - Jikkou vs Strimzi Topic Operator

Two different jobs

The cleanest way to see the difference: Strimzi runs Kafka; Jikkou manages what is inside it.

Strimzi manages the cluster lifecycle itself on Kubernetes: brokers, KRaft/ZooKeeper, listeners and security, users, and companion tooling like Kafka Connect and MirrorMaker. Jikkou never touches the cluster lifecycle. It manages Kafka resources (topics, ACLs, quotas, consumer groups, schemas, connectors) declaratively, regardless of where Kafka runs.

What the Topic Operator does well

Credit where due. Inside a Strimzi-managed cluster, KafkaTopic and KafkaUser custom resources are excellent: Kubernetes-native, reconciled continuously by an operator, GitOps-ready through Argo CD or Flux with zero extra tooling, and backed by a large CNCF community. If topics and users on Strimzi clusters are your entire need, you do not need Jikkou.

Where it stops

Most Kafka estates are bigger than that. The Topic Operator manages exactly two resource kinds, on exactly one class of cluster:

Two structural differences matter beyond the table:

• Kubernetes gravity. The Topic Operator can technically target an external cluster (standalone deployment), but you are still tied to Kubernetes and its reconciliation cycles. Running an operator plus the Kubernetes overhead just to manage resources on a managed service like MSK, Confluent Cloud, or Aiven is complexity most teams prefer to avoid. Jikkou is a stateless CLI: it runs anywhere your CI runs, and applies one model across the whole fleet.
• Policy. CRDs are raw desired state. There is no place to say “every topic must have at least min.insync.replicas: 2 and follow the <domain>-<name> convention”. Jikkou validations enforce platform rules on every resource before it reaches any cluster.

Better together

The pattern that works well for Strimzi shops:

1. Argo CD / Flux + Topic Operator own topics and users on the Strimzi clusters, same as today.
2. Jikkou in CI owns the rest from the same Git repository: Schema Registry subjects, Connect connectors, quotas, and every resource on managed-service clusters (Confluent Cloud, Aiven, MSK).

One repository, one review process, two reconcilers, each on the surface where it is strongest.

When Strimzi alone is enough

If all of the following hold, stay with the Topic Operator and skip Jikkou:

• Every Kafka cluster you manage runs on Kubernetes under Strimzi.
• Topics and users are the entire resource surface: no Schema Registry, no Connect, no quotas.
• Your team is comfortable expressing everything as raw CRDs without templating or policy checks.

That is a real profile, and small K8s-only estates fit it. Most platform teams outgrow it.

Next steps

• Install Jikkou
• Jikkou vs Terraform
• Questions? Join the Slack community