Best tools to manage Kafka broker configs
ComparisonsThe tools for managing Kafka broker configs fall into four groups: Kafka’s own kafka-configs.sh and Admin API, configuration-as-code tools such as Strimzi and Terraform, Kafka UIs such as AKHQ and Kafbat UI, and management consoles such as Confluent Control Center and Kpow. The CLI is the baseline every cluster has. The others add what it lacks: a record of intent in Git, a readable view of what is actually running, and control over who can change it.
A broker config is the set of properties a broker reads from server.properties at startup, plus the subset Kafka lets you change while the broker runs. For how brokers fit into the cluster as a whole, start with the complete Kafka guide or Kafka brokers in production.
At a glance
Eight options are scored here on this page's six weighted criteria, 100 points in all. The rubric is weighted: Break-glass visibility counts three times, Access control and audit counts three times, and Running config and source, Drift against a baseline, Config as code and Safe change mechanics count once. The five listed first, of eight, each out of 100: Kpow 74, which takes its best score on Running config and source (10 out of 10) and its lowest on Config as code (0 out of 10); Strimzi 63; Terraform 47; Kafbat UI 42, License: Free, self-hosted, Apache 2.0; Confluent Control Center 40.
How Kafka broker configuration works
Every broker property has an update mode, listed in the Apache broker configuration reference. The mode decides whether a tool can change it without a restart, whatever tool you use:
read-only requires a broker restart
per-broker may be updated dynamically for each broker
cluster-wide may be updated dynamically as a cluster-wide defaultWhen the same property is set at more than one level, Kafka applies this order of precedence: a dynamic per-broker value, then a dynamic cluster-wide default, then the static value in server.properties, then Kafka’s own default. Dynamic values are stored in the cluster metadata, not in server.properties, so reading the file on disk does not tell you what a broker is running.
kafka-configs.sh is the reference tool for all of it. These are the commands from the Apache guide to updating broker configs:
Describe the dynamic overrides on broker 0:
kafka-configs.sh --bootstrap-server <broker:9092> --entity-type brokers --entity-name 0 --describeChange a per-broker value, then remove the override so the broker falls back to the static or default value:
kafka-configs.sh --bootstrap-server <broker:9092> --entity-type brokers --entity-name 0 --alter --add-config log.cleaner.threads=2
kafka-configs.sh --bootstrap-server <broker:9092> --entity-type brokers --entity-name 0 --alter --delete-config log.cleaner.threadsSet and describe a cluster-wide default that every broker picks up:
kafka-configs.sh --bootstrap-server <broker:9092> --entity-type brokers --entity-default --alter --add-config log.cleaner.threads=2
kafka-configs.sh --bootstrap-server <broker:9092> --entity-type brokers --entity-default --describe--describe on its own lists dynamic configs only. Adding --all lists every config for the entity, “including static configs if available”, per the option definition in the Kafka source. Use --all when you want to know what a broker is actually running.
Thread pool sizes are a special case worth knowing before you change them. num.io.threads, num.network.threads and num.replica.fetchers can be changed dynamically as a cluster default, but Apache restricts each update to between half and double the current size.
The tools compared
Every row uses the same fields in the same order. The Source column points at the tool’s own documentation.
| Rank | Tool | Running config and source | Drift against a baseline | Config as code | Break-glass visibility | Access control and audit | Scope and fit | Source |
|---|---|---|---|---|---|---|---|---|
| 1 | Kpow | Strong. Every broker’s configuration in one table, filterable by broker, property, source, importance and whether it is read-only, across up to 12 clusters per instance. | Partial. Source filtering shows every non-default value at a glance, but Kpow does not store a declared baseline or diff against one. | None. Kpow is not a config-as-code tool. | Strong. A change made through Kpow is recorded in the audit log, and the source column shows dynamic overrides however they were made. | Strong. Editing needs the BROKER_EDIT permission under RBAC, and every mutation is written to the audit log, which can also go to a webhook. |
Any Kafka cluster Kpow connects to, including managed services. Licensed per cluster, with a free Community Edition for up to three clusters. | Kpow broker docs |
| 2 | Strimzi (spec.kafka.config) |
Partial. The declared config is in the Kafka resource. The running values are still read with the CLI. |
Strong. The operator validates and applies the config during reconciliation. | Strong. Broker config is a Kubernetes resource in Git. | Partial. A manual change made outside the resource is not in Git, so it has to be caught by comparing against the running config. | Kubernetes RBAC on the resource, with Git history as the audit trail. Some properties, including listeners, log directories and authorization, are managed by Strimzi and cannot be set. | Strimzi-managed Kafka on Kubernetes only. | Strimzi documentation |
| 3 | kafka-configs.sh and Admin API | Strong. --describe --all shows every config for a broker. Output is text per broker, one call each. |
Manual. You script the diff against your baseline yourself. | Strong if you build it. Scripts in a repo applied by CI are the common pattern. | None. A change from a laptop leaves no record unless your shell or CI keeps one. | None in the tool. Kafka ACLs control who can alter configs, and there is no change log. | Every Kafka cluster, per-broker and cluster-wide. | Apache Kafka docs |
| 4 | Terraform | Depends on the provider. | Strong where supported, through plan and apply. | Strong where supported. | Shows up as drift on the next plan. | Git and your Terraform workflow. | The open-source Mongey provider manages topics, ACLs, quotas and SCRAM users, not broker configs. Confluent’s provider has a cluster config resource for Confluent Cloud Dedicated clusters only. | terraform-provider-kafka |
| 5 | Confluent Control Center | Strong for Confluent Platform. Shows cluster defaults, with an indicator where a setting was modified from the default. | None built in. | None. Changes apply directly to the cluster. | Partial. Dynamic editing can be disabled organization-wide. | Tied to Confluent Platform RBAC. | Confluent Platform only. | Confluent’s documentation, “Manage Kafka Clusters Using Control Center for Confluent Platform” |
| 6 | Kafbat UI | Partial. Broker config is viewable and editable under the clusterconfig permission. |
None. | None. | Partial. UI changes can be audited when auditing is enabled. | Partial. clusterconfig has view and edit actions, and an opt-in audit log writes operations to a topic or the console. |
Free, self-hosted, Apache 2.0. | Kafbat UI RBAC docs |
| 7 | AKHQ | Partial. Broker config is viewable under the NODE resource. | None. | None. | Partial. Changes through the UI are role-gated. | Partial. RBAC has READ_CONFIG and ALTER_CONFIG on nodes. Its audit events cover topic config changes, and the documented list has no broker config event. |
Free, self-hosted, Apache 2.0. | AKHQ docs |
| 8 | JulieOps | Not covered. | Not covered for brokers. | Strong for topics, ACLs, schemas and connectors, not broker configs. | Not covered. | Git and CI review. | Its maintainer describes the project as in hibernation, with the last push in June 2024. | JulieOps |
Scoring notes. For config as code on vanilla Apache Kafka, the honest winner is a repository of kafka-configs.sh scripts or server.properties templates applied by CI, because the popular GitOps tools stop at topics and ACLs. Strimzi is the strongest option if you already run Kafka on Kubernetes. Kpow is strongest on seeing what is running and who changed it, and it does not replace a declared baseline.
Kpow live demo
See every broker config and its source
Open the Kpow demo's Broker Configuration table and filter by source to find every non-default value on a live cluster.
For operators who need to know what a broker is actually running.
Try the Kpow demoGitOps and configuration as code
What they are. Tools that keep the desired state in Git and apply it through CI, so every change has a review and a history.
Where they win. Review before the change, history after it, and a baseline you can diff against. For broker config, that is exactly what the treat-it-like-code advice above asks for.
Where they fall short. The open-source tools most often recommended for Kafka GitOps manage topics and ACLs, not brokers. kafka-gitops describes itself as managing “Apache Kafka topics and ACLs”, and the two scored below stop in the same place.
What to use instead. For broker config on vanilla Kafka, version server.properties for static values and a script of kafka-configs.sh --alter calls for dynamic ones, apply both from CI, and run --describe --all against every broker on a schedule to catch what changed outside it.
Terraform
47 out of 100 Total
- Type
- Infrastructure as code
- Broker config
- Depends on the provider
- Confluent provider
- Dedicated clusters on Confluent Cloud only
- Running config and source
- 2 out of 10
- Drift against a baseline
- 5 out of 10
- Config as code
- 5 out of 10
- Break-glass visibility ×3 weight, this criterion counts 3 times toward the total
- 5 out of 10
- Access control and audit ×3 weight, this criterion counts 3 times toward the total
- 6 out of 10
- Safe change mechanics
- 2 out of 10
Why these scores for Terraform
- Running config and source 2 out of 10
- What it shows depends on the provider, and the open-source Mongey provider lists topics, ACLs, quotas and SCRAM users as its resources and no broker config, so on most clusters there is no running view to read.
- Drift against a baseline 5 out of 10
- Plan and apply make it strong where supported, and it is scored on the where-supported half because broker config is outside the open-source provider.
- Config as code 5 out of 10
- It is strong where supported, with the same qualification, and strong for what it manages, but for vanilla Kafka broker config it does not manage it.
- Break-glass visibility 5 out of 10
- An out-of-band change shows up as drift on the next plan, so it is visible, but only when someone runs a plan.
- Access control and audit 6 out of 10
- Git and your Terraform workflow give review before the change and history after it, and no record of a change made outside it.
- Safe change mechanics 2 out of 10
- The page describes no update-mode handling, scope control or one-change-at-a-time discipline for Terraform.
What it is. Infrastructure as code for Kafka, through a provider. The Mongey Terraform provider lists kafka_topic, kafka_acl, kafka_quota and kafka_user_scram_credential as its resources.
Where it wins. Where the provider supports the resource, plan and apply give review before the change, history after it, and drift surfaced at the next plan, in the same workflow the rest of your infrastructure already uses.
Where it falls short. Broker config is not among the open-source provider’s resources. Confluent’s Terraform provider does have a confluent_kafka_cluster_config resource, but its own documentation limits it to Dedicated clusters on Confluent Cloud.
Staying patched. The Mongey Terraform Kafka provider is MIT. The repository was last pushed in August 2026 but it has not cut a release in 367 days, since v0.13.1 in September 2025, so anything fixed on its main branch is not in the provider you download.
Rank 8 JulieOps
17 out of 100 Total
- Type
- GitOps tool
- Broker config
- Not covered
- Status
- In hibernation, last push June 2024
- Running config and source
- 0 out of 10
- Drift against a baseline
- 0 out of 10
- Config as code
- 2 out of 10
- Break-glass visibility ×3 weight, this criterion counts 3 times toward the total
- 0 out of 10
- Access control and audit ×3 weight, this criterion counts 3 times toward the total
- 5 out of 10
- Safe change mechanics
- 0 out of 10
Why these scores for JulieOps
- Running config and source 0 out of 10
- It does not cover the running broker config.
- Drift against a baseline 0 out of 10
- Drift is not covered for brokers.
- Config as code 2 out of 10
- It is strong for topics, ACLs, schemas and connectors but not broker configs, which earns credit for the model and none for the subject of this page.
- Break-glass visibility 0 out of 10
- Break-glass visibility is not covered.
- Access control and audit 5 out of 10
- Git and CI review give it the same Git trail the other config-as-code entries carry, and the one column where it scores on this rubric.
- Safe change mechanics 0 out of 10
- Broker config is out of its scope, so there is no update mode for it to respect and no scope for it to make obvious.
What it is. A GitOps tool for Kafka. JulieOps covers topics, access control, schemas, connectors and related metadata, and its maintainer’s note says the project is “mostly on a long winter hibernation”.
Where it wins. Git and CI review for the resources it does manage, which is the same review-before, history-after pattern criterion 3 asks for.
Where it falls short. It does not manage broker configuration, which is what this page compares, and its maintainer describes the project as in hibernation, with the last push in June 2024.
Staying patched. JulieOps is MIT, last released v4.4.1 in October 2022 and last pushed in June 2024, with no CVE filed against its own code. There is no release coming to carry a dependency fix.
Kubernetes-native management
If Kafka already runs on Kubernetes under Strimzi, broker config can be declared in the same resources as everything else in the cluster.
Rank 2 Strimzi
63 out of 100 Total
- Type
- Kubernetes operator
- Declares config in
- spec.kafka.config
- Scope
- Strimzi-managed Kafka on Kubernetes
- Running config and source
- 4 out of 10
- Drift against a baseline
- 9 out of 10
- Config as code
- 10 out of 10
- Break-glass visibility ×3 weight, this criterion counts 3 times toward the total
- 4 out of 10
- Access control and audit ×3 weight, this criterion counts 3 times toward the total
- 7 out of 10
- Safe change mechanics
- 7 out of 10
Why these scores for Strimzi
- Running config and source 4 out of 10
- The declared config is in the
Kafkaresource and the running values are still read with the CLI, so it answers what should be set rather than what is. - Drift against a baseline 9 out of 10
- The operator validates and applies the config during reconciliation, and it is the only option here that gives vanilla Apache Kafka a genuine declared baseline for broker settings.
- Config as code 10 out of 10
- Broker config is a Kubernetes resource in Git, and the page’s own prose names it the strongest option for a team already on Kubernetes, which makes it the best answer on the page to criterion 3.
- Break-glass visibility 4 out of 10
- A manual change made outside the resource is not in Git, so it has to be caught by comparing against the running config.
- Access control and audit 7 out of 10
- Kubernetes RBAC guards the resource and Git history is the audit trail, but there is no per-change record of who altered a running broker outside the resource, which puts it below Kpow.
- Safe change mechanics 7 out of 10
- Its own guidance is to adjust configuration incrementally and monitor the impact, which is criterion 6 word for word, and the operator validates and applies during reconciliation.
What it is. Strimzi defines broker configuration as key-value pairs under spec.kafka.config in the Kafka custom resource, then “validates and applies these properties during reconciliation.”
Where it wins. Broker config becomes a Kubernetes resource like everything else in the cluster, with GitOps history and reconciliation built in. It is the only option here that gives vanilla Apache Kafka a genuine declared baseline for broker settings.
Where it falls short. It only applies to Strimzi-managed clusters, and Strimzi reserves some properties for itself, including node.id, log.dirs, listeners, authentication and authorization, so you cannot set those through config. Its own guidance is to adjust configuration incrementally and monitor the impact using broker and client metrics, which is the same discipline the CLI needs.
Staying patched. Strimzi is community-maintained under the CNCF and it answers the patching question better than most vendors do. Thirty-eight releases in two years, six published CVEs, each with a coordinated-disclosure advisory, and on the last three batches the fixed release shipped the same day the advisory was published: 0.49.1 in December 2025, 0.50.1 in February 2026 and 1.0.1 in June 2026. Open source is not the risk here. The absence of a contract is, and Strimzi shows how little that has cost so far.
Enterprise control planes and UIs
These are the tools people reach for during an incident, when the question is “what is this broker running right now, and can I change it without logging into a box”.
Rank 1 Kpow
74 out of 100 Total
Try Kpow in the live demo No signup needed.
- Type
- Kafka management and monitoring
- Clusters per instance
- Up to 12
- Edit permission
- BROKER_EDIT
- Running config and source
- 10 out of 10
- Drift against a baseline
- 4 out of 10
- Config as code
- 0 out of 10
- Break-glass visibility ×3 weight, this criterion counts 3 times toward the total
- 8 out of 10
- Access control and audit ×3 weight, this criterion counts 3 times toward the total
- 10 out of 10
- Safe change mechanics
- 6 out of 10
Why these scores for Kpow
- Running config and source 10 out of 10
- Every broker’s config is in one table, filterable by source, and the page’s own prose says “Kpow is strongest on seeing what is running”.
- Drift against a baseline 4 out of 10
- Source filtering shows every non-default value, but there is no declared baseline or diff against one.
- Config as code 0 out of 10
- There is none, since “Kpow is not a config-as-code tool”.
- Break-glass visibility 8 out of 10
- A change through Kpow is in the audit log and the source column shows dynamic overrides however they were made.
- Access control and audit 10 out of 10
- The page’s own prose calls it strongest on “who changed it”, with BROKER_EDIT under RBAC, every mutation audited and an optional webhook.
- Safe change mechanics 6 out of 10
- It has a read-only status filter, makes one broker or the whole cluster visible, and changes dynamic values by role, with nothing on one change at a time.
What it is. Factor House’s Kafka management and monitoring product.
Where it wins. The Broker Configuration view lists every property for every broker, with filters for source, importance and read-only status, which makes it fast to find every non-default value on one broker or across the cluster. This is the screen Chad Harris showed in the talk for exactly that job, with guidance on whether each setting is the default, has been changed, or can be changed. Editing a value needs the BROKER_EDIT permission, and the change is recorded in Kpow’s audit log with who made it. One instance covers up to 12 clusters, so staging and production are in the same UI, a trade-off covered in the comparison of multi-cluster Kafka tools. The same product shows the KRaft quorum’s voters and observers.
Where it falls short. Kpow does not keep a declared baseline or diff the running config against one, and it is not a config-as-code tool. Pair it with a Git-managed baseline rather than using it as the source of truth.
Staying patched. Kpow’s release notes name the CVEs each release remediates, and the 96.4 image built on 5 August 2026 bundles 311 dependencies of which one carries a high or critical advisory, none of them published before that release. That is not a claim to patch faster than a community project: Kpow’s own dependency remediation has run from 14 to 128 days, and the current image still ships CVE-2026-75595 in netty, a 9.1 critical public since 19 August 2026, unpatched. What a licence buys here is not a different deployment model, because Kpow is self-hosted too. It is a company contracted to ship the fix. Every dependency figure on this page was read on 24 September 2026 from the published artefacts and from nvd.nist.gov.
Compare Kpow vs AKHQKpow vs Kafbat UIKpow vs Confluent Control Center
Rank 4 Kafbat UI
42 out of 100 Total
- Type
- Kafka UI
- License
- Free, self-hosted, Apache 2.0
- Audit log
- Opt-in, to a topic or the console
- Running config and source
- 5 out of 10
- Drift against a baseline
- 0 out of 10
- Config as code
- 0 out of 10
- Break-glass visibility ×3 weight, this criterion counts 3 times toward the total
- 6 out of 10
- Access control and audit ×3 weight, this criterion counts 3 times toward the total
- 6 out of 10
- Safe change mechanics
- 1 out of 10
Why these scores for Kafbat UI
- Running config and source 5 out of 10
- Broker config is viewable and editable under the clusterconfig permission, with no source shown.
- Drift against a baseline 0 out of 10
- Like every UI here it has no concept of a declared baseline.
- Config as code 0 out of 10
- It has no config-as-code path.
- Break-glass visibility 6 out of 10
- UI changes can be audited when auditing is enabled, which is possible with setup the reader must do.
- Access control and audit 6 out of 10
- It has clusterconfig view and edit actions plus an opt-in audit log, and the page’s own prose names it for broker change audit with auditing enabled, which puts it above AKHQ.
- Safe change mechanics 1 out of 10
- This page describes no update-mode, scope or one-change-at-a-time handling.
What it is. The actively maintained fork of the former Provectus Kafka UI. Its RBAC has a clusterconfig resource with view and edit actions, separate from applicationconfig, which covers the UI’s own settings.
Where it wins. Free and self-hosted, with an audit log that records operations made through the UI to a Kafka topic or the console once you enable it.
Where it falls short. Auditing is off until configured, and like every UI here it has no concept of a declared baseline.
Staying patched. Kafbat UI released v1.5.0 in April 2026 and has not shipped since. In the 157 days since, at least 20 high or critical advisories have been published against libraries that release bundles, including the same netty critical CVE-2026-75595 that the current Kpow image carries. Only 150 of its 266 bundled jars resolved to a Maven coordinate, so that count is a floor and the state of the release itself is unmeasured. Kafbat does publish a security policy, which AKHQ and Kafdrop do not, and the one CVE filed against its own code, CVE-2025-49127, was already fixed in the release that preceded the advisory. Six releases in two years.
Compare Kpow vs Kafbat UIAKHQ vs Kafbat UIConfluent Control Center vs Kafbat UIKafbat UI review
Confluent Control Center
confluent.io
40 out of 100 Total
- Type
- Management UI
- Scope
- Confluent Platform only
- Running config and source
- 8 out of 10
- Drift against a baseline
- 2 out of 10
- Config as code
- 0 out of 10
- Break-glass visibility ×3 weight, this criterion counts 3 times toward the total
- 4 out of 10
- Access control and audit ×3 weight, this criterion counts 3 times toward the total
- 5 out of 10
- Safe change mechanics
- 3 out of 10
Why these scores for Confluent Control Center
- Running config and source 8 out of 10
- It is strong for Confluent Platform, showing cluster defaults with an indicator where a setting was modified from the default.
- Drift against a baseline 2 out of 10
- There is none built in and any Git baseline has to be reconciled separately, so the modified-from-default indicator is the small remnant.
- Config as code 0 out of 10
- Changes apply directly to the cluster, so there is no config-as-code path.
- Break-glass visibility 4 out of 10
- Dynamic editing can be disabled organization-wide, and the page does not say an out-of-band change is attributed.
- Access control and audit 5 out of 10
- Access is tied to Confluent Platform RBAC, and the page names no audit record of broker changes.
- Safe change mechanics 3 out of 10
- It has a dynamic editing feature an organization can disable, and nothing on update modes, scope or one change at a time.
What it is. The management UI for Confluent Platform. Confluent’s documentation describes editing cluster defaults from a Cluster settings view, with an indicator where a setting has been modified from its default and a dynamic editing feature that an organization can disable.
Where it wins. A readable view and edit path for teams on Confluent Platform, integrated with the rest of that platform.
Where it falls short. It only manages Confluent Platform clusters. Changes apply straight to the cluster, so any Git baseline has to be reconciled separately.
Compare Kpow vs Confluent Control CenterAKHQ vs Confluent Control CenterConfluent Control Center vs Kafbat UIConfluent Control Center review
Rank 7 30 out of 100 Total
- Type
- Kafka UI
- License
- Free, self-hosted, Apache 2.0
- Running config and source
- 5 out of 10
- Drift against a baseline
- 0 out of 10
- Config as code
- 0 out of 10
- Break-glass visibility ×3 weight, this criterion counts 3 times toward the total
- 3 out of 10
- Access control and audit ×3 weight, this criterion counts 3 times toward the total
- 5 out of 10
- Safe change mechanics
- 1 out of 10
Why these scores for AKHQ
- Running config and source 5 out of 10
- Broker config is viewable under the NODE resource, with no source shown.
- Drift against a baseline 0 out of 10
- It has no drift check against a baseline.
- Config as code 0 out of 10
- There is no config-as-code path.
- Break-glass visibility 3 out of 10
- UI changes are role-gated, so a broker change can be gated, but the audit topic will not show it.
- Access control and audit 5 out of 10
- Its RBAC has READ_CONFIG and ALTER_CONFIG on nodes, but the documented audit list has no broker config event, so it meets half the criterion.
- Safe change mechanics 1 out of 10
- This page describes no update-mode, scope or one-change-at-a-time handling beyond role gating.
What it is. A free, self-hosted Kafka UI. Its RBAC model has READ_CONFIG and ALTER_CONFIG actions on the NODE resource, which covers broker configuration.
Where it wins. Free, familiar to many teams, and role-gated.
Where it falls short. Its audit configuration emits events for topic creation, topic configuration changes, consumer group offsets, schemas and connectors, and the documented list includes no broker configuration event. A broker change made through AKHQ can be gated, but the audit topic will not show it.
Staying patched. AKHQ has no CVE filed against its own code, and that is the wrong number to plan against. Release 0.28.0, cut on 6 August 2026, bundles 270 libraries and 18 of them carry a high or critical advisory. Sixteen were already public, with fixed versions already on Maven Central, on the day it shipped, and five are netty advisories Kpow had remediated three weeks earlier in 96.2: CVE-2026-44249, CVE-2026-45416, CVE-2026-45674, CVE-2026-47691 and CVE-2026-50010. The oldest has been open 108 days. That is exposure and remediation latency rather than a working attack, and every figure resolves against the published jar and nvd.nist.gov. Four releases in two years, and no security policy at any path GitHub reads.
Compare Kpow vs AKHQAKHQ vs Kafbat UIAKHQ vs Confluent Control CenterAKHQ review
Native CLI alternatives
Every cluster already has one broker config tool, and most of the options above are judged against it.
Rank 6 kafka-configs.sh and the Admin API
32 out of 100 Total
- Type
- Command-line tool
- Ships with
- Apache Kafka
- Complete view
- --describe --all
- Running config and source
- 8 out of 10
- Drift against a baseline
- 5 out of 10
- Config as code
- 8 out of 10
- Break-glass visibility ×3 weight, this criterion counts 3 times toward the total
- 0 out of 10
- Access control and audit ×3 weight, this criterion counts 3 times toward the total
- 2 out of 10
- Safe change mechanics
- 5 out of 10
Why these scores for kafka-configs.sh and the Admin API
- Running config and source 8 out of 10
- It shows every config for a broker with
--describe --all, the most complete answer to what this broker is running, and sits below Kpow only because the output is text, one call per broker. - Drift against a baseline 5 out of 10
- You script the diff against your baseline yourself, which is possible with work the reader does and lands in the middle of the scale.
- Config as code 8 out of 10
- It is strong if you build it, and the page’s own prose calls a repository of these scripts applied by CI the honest winner for vanilla Apache Kafka, because the popular GitOps tools stop at topics and ACLs.
- Break-glass visibility 0 out of 10
- A change from a laptop leaves no record unless your shell or CI keeps one, which is exactly the criterion 4 failure.
- Access control and audit 2 out of 10
- The tool has none of its own, and while Kafka ACLs control who can alter configs there is no change log, so only the permission half remains.
- Safe change mechanics 5 out of 10
- Update modes, per-broker and cluster-wide scope and the half-to-double thread restriction are all explicit in the commands, but nothing stops two people changing the same property from two laptops.
What it is. kafka-configs.sh and the Admin API it wraps, in every Kafka distribution.
Where it wins. It is the only tool guaranteed to be present, it reads the broker directly, and --describe --all is the most complete answer to “what is this broker running”. Scripted, it is also the base of most config-as-code setups for vanilla Kafka.
Where it falls short. One entity per call, text output, no record of who ran it, and nothing stops two people changing the same property from two laptops. The Apache precedence rules also mean a static value you edited in server.properties can be silently overridden by an old dynamic value still stored in the cluster, which is worth checking with --describe before a restart. JVM settings such as heap size sit outside broker config entirely, in the start-up environment, and container memory limits can change how the JVM sizes itself, as the notes on Amazon Corretto 11 memory issues show for a JVM running in Docker.
How Factor House approaches broker config
Factor House built the broker configuration view in Kpow for the moment an incident needs an answer to “what is this broker actually running”. It shows every property with its source and importance, lets someone with the right role change a dynamic value without shell access, and records the change in the audit log. The Kpow broker management documentation covers the filters and edit workflow. The quickest way to test the criteria on this page is the Kpow demo: open the Broker Configuration table on a live cluster, filter by source to list every non-default value, and compare the same property across brokers.
What Factor House recommends alongside it is the same discipline from the talk: keep the baseline in Git, apply changes through CI where you can, make one change at a time, and check the running config after every rollback. If you are also running Flink next to Kafka, Factor Platform brings both under one control plane.
How to choose
One cluster, one team, vanilla Kafka. Version your config in Git, apply it with kafka-configs.sh from CI, and schedule a --describe --all diff.
Kafka on Kubernetes. Strimzi’s spec.kafka.config gives you a declared baseline with reconciliation.
Confluent Platform or Confluent Cloud Dedicated. Control Center or Confluent’s Terraform provider respectively.
Several clusters, several teams, and a need to prove who changed what. Add a console with role-based editing and an audit log that covers broker changes. Check that claim in each tool’s own documentation, since AKHQ’s audit list does not include broker config. Kafka broker monitoring covers the metrics that tell you a config change has gone wrong. For the wider tool landscape, see the broader Kafka management tools comparison.
FAQ
What is the difference between static and dynamic Kafka broker configs?
A static (read-only) config is read from server.properties at startup and needs a broker restart to change. A dynamic config can be changed while the broker runs with kafka-configs.sh --alter or the Admin API, either per broker or as a cluster-wide default. The update mode of each property is listed in the Apache broker configuration reference.
How do I see the current config of a Kafka broker?
Run kafka-configs.sh --bootstrap-server <broker:9092> --entity-type brokers --entity-name <id> --describe --all. Without --all you only see dynamic overrides. A management console such as Kpow shows the same information for every broker in one table, with the source of each value.
Can I manage Kafka broker configs with Terraform?
Only on some platforms. The open-source Mongey provider manages topics, ACLs, quotas and SCRAM users, not broker configs. Confluent’s provider can update cluster configs on Confluent Cloud Dedicated clusters. On Kubernetes, Strimzi’s Kafka resource is the closest equivalent for vanilla Kafka.
How do I audit who changed a Kafka broker config?
Kafka itself does not record it. You need a tool in the change path that does: CI history if changes only go through a pipeline, or a console with an audit log that covers broker changes, such as Kpow or Kafbat UI with auditing enabled.
How these tools were scored
These criteria come from an incident Chad Harris walked through in the Kafka operational issues talk. A team raised replica fetcher and I/O thread counts on a managed cluster, the upgrade failed and rolled back, and the thread counts did not roll back with everything else. Six months later a disk failed, the rebuild saturated disk I/O, and producer timeouts spread across teams. From the talk: “It took someone looking specifically at that broker’s config to notice it didn’t match the vendor’s best practices”. Each criterion below is something that would have caught it sooner.
1. Seeing the running config and its source. You need every property a broker is running, and whether each one is a default, a static value or a dynamic override. In the talk he recommended making a dump of the current broker config part of your runbooks, so you check it matches what you expect rather than assume it does. A tool that only shows server.properties, or only dynamic overrides, answers half the question.
2. Catching drift against a baseline. His advice from the same session: “After any rollback, diff the running config against your baseline, and periodically audit the running config against your documented best practices”. A tool scores well here if it keeps a declared baseline and either reconciles to it or shows you where the cluster differs.
3. Changing config as code. “Treat broker config changes like code where you can: version-controlled and applied through CI.” That gives review before the change and history after it.
4. The break-glass path. Even teams with GitOps keep a way to change config by hand in an incident. From the talk: “some environments keep a break-glass option for emergency config changes that never quite makes it back into GitOps.” A tool scores well if it makes the out-of-band change visible and attributable, so it can be reconciled later.
5. Access control and audit. Who can change a broker property, and whether there is a record of who did it and when. The comparisons of Kafka RBAC tools and Kafka audit logging tools go deeper on each half. In Kpow’s case, as Tom Crowley, Factor House’s founding engineer, has described it, the audit trail is persisted in Kpow’s internal audit log, which is itself backed by a Kafka topic.
6. Safe change mechanics. Whether the tool respects update modes, makes scope obvious (one broker or the whole cluster), and encourages the rule from the same talk: “one change at a time, monitored before the next”.
A rollback isn't done until every change is verified and reverted, and config drift is silent until it isn't.
Chad Harris, Solutions Architect at Factor House
Every option is scored from 0 to 10 on each criterion, from the evidence and sources this page cites, and the reason for each score is on its card. The criteria are weighted: Running config and source counts once, Drift against a baseline counts once, Config as code counts once, Break-glass visibility counts three times, Access control and audit counts three times and Safe change mechanics counts once, for a total out of 100. Access control and audit and Break-glass visibility count three times here, because a broker config change nobody can attribute, and a manual override nobody can see, are how a cluster drifts away from what its owners believe is running. Running config and source, drift against a baseline, config as code and safe change mechanics count once. This page is published by Factor House, which makes Kpow. Every option is scored on the same rubric and the same sources: Kpow's per-criterion scores are set the same way as every other option's and are not adjusted, and the weights apply to every option alike. Kpow ranks first on its total of 74 out of 100. The other options follow by total.