The best Kafka tool for Apache Kafka Connect is one that shows each connector’s tasks and the stack trace of the one that failed, restarts the right thing and restarts failed connectors on its own with a cap, reaches self-managed Connect, Amazon MSK Connect and Confluent Cloud managed connectors from one place, decides per person who may create or change a connector whose configuration holds credentials and records who did, and runs as one container beside the cluster, out of the data path. Kpow, Kafbat UI, AKHQ, Lenses, the Connect REST API itself, Redpanda Console and Conduktor each cover part of that, and TD Bank is one team that triages connectors in Kpow. Scored on the six weighted criteria explained below the rankings, Kpow ranks first with 99 out of 110, ahead of Kafbat UI at 72 and AKHQ at 62; Conduktor, listed last, totals 69.
Tools compared
| Rank | Tool | Total (out of 110) | Out of the data path | Production access on request | Audit trail per person | Connector operations | Directory and Kafka sign-in | Many teams, shared clusters | Cost a year, one cluster (modelled) |
|---|---|---|---|---|---|---|---|---|---|
| 1 | Kpow | 99 | One container, no external database, not a proxy | Temporary policies, staged approvals, masking | Every action and data read, by user | Task state and traces, capped auto-restart, MSK Connect and Confluent Cloud | SAML, OpenID, LDAP | Tenants per team, connectors included | $7,380 |
| 2 | Kafbat UI | 72 | One container | Read-only clusters, no approvals | Opt-in log, no view in the product | Status, create, restart; no auto-restart | OAuth2, OIDC, LDAP | Roles per resource | $8,640 |
| 3 | AKHQ | 62 | One container | Group roles, no approvals | Opt-in topic, no reads | Status, connector or task restart | LDAP, OIDC | Regex groups | $8,640 |
| 4 | Lenses | 61 | HQ on PostgreSQL plus an agent per cluster | Global masking, no approvals | In-product audit log | Task health and built-in alert rules; no auto-restart | SSO from Team tier | Group roles | $6,880 for 15 users; custom above |
| 5 | The Connect REST API and scripts | 53 | Nothing to deploy | Anyone who reaches the API | Worker logs only | Every operation, nothing watching | HTTPS and basic auth at the worker | One URL per Connect cluster | $11,520 |
| 6 | Redpanda Console | 52 | One container | None in the free build; RBAC licensed | No record on non-Redpanda brokers | Inspect, patch, restart, pause; no auto-restart | OIDC (Enterprise) | One cluster per deployment | $8,640 plus an unpublished licence for sign-in and RBAC |
| 7 | Conduktor | 69 | Console on PostgreSQL; Gateway, a proxy, for data-level controls | Masking exemptions, owner approval | 70+ event types in the UI | Failed-task auto-restart with history, alerts, Confluent Cloud | LDAP, OIDC | Groups; Virtual Clusters need Gateway | $32,880; $122,880 with Gateway Core and Protect |
The tools, ranked for Apache Kafka Connect
Rank 1 Kpow
99 out of 110 Total
Try Kpow in the live demo No signup needed.
- Cost a year
- $4,500 per Kafka cluster with 100 users included, plus about $2,880 in operator time, so $7,380 on one cluster (modelled)
- On Kafka Connect
- Several Connect clusters per Kafka cluster, plus MSK Connect and Confluent Cloud managed connectors
- Deployment
- One container or JAR, no external database
- Out of the data path ×3 weight, this criterion counts 3 times toward the total
- 9 out of 10
- Production access on request ×2 weight, this criterion counts 2 times toward the total
- 9 out of 10
- Audit trail per person ×2 weight, this criterion counts 2 times toward the total
- 9 out of 10
- Connector operations ×2 weight, this criterion counts 2 times toward the total
- 9 out of 10
- Directory and Kafka sign-in
- 9 out of 10
- Many teams, shared clusters
- 9 out of 10
Why these scores for Kpow
- Out of the data path 9 out of 10
- It is one container or JAR whose snapshots, metrics and audit log live in topics on your own cluster, and it reaches Connect through the Connect REST API and Kafka as an ordinary client, so nothing sits between your connectors and the brokers.
- Production access on request 9 out of 10
- Temporary policies grant time-boxed access that an admin or a change system calling the Kpow API can create, staged mutations hold any action for approval, and data policies mask fields in inspection, though masking is per resource rather than per viewer.
- Audit trail per person 9 out of 10
- Every action is recorded with the user from the identity provider and the policy that allowed it, including data inspect queries, with a seven-day view in the product, the record written to an audit topic on your own cluster, and webhooks that send it to a SIEM for long-term retention.
- Connector operations 9 out of 10
- Connector and task state sit side by side with task stack traces, individual tasks restart from the task table, and auto-restart of named or wildcard connectors runs on a one-minute interval with a 10-minute window and a cap of 50 restarts per interval, each restart written to the audit log, across several Connect clusters plus MSK Connect and Confluent Cloud managed connectors; it is held below 10 because Conduktor restarts only the failed tasks automatically and keeps a restart history, and the JMX exporter goes deeper on per-task metrics.
- Directory and Kafka sign-in 9 out of 10
- People sign in with SAML, OpenID or LDAP, and Kpow connects to Kafka with the same SASL or TLS settings as any client and to each Connect REST API over HTTPS with basic authentication where the workers require it.
- Many teams, shared clusters 9 out of 10
- Tenants scope each team to its own topics, consumer groups and connectors on a shared cluster, and RBAC adds Allow, Deny or Stage per action.
On Kafka Connect. Kpow’s Kafka Connect configuration connects to a Connect cluster with CONNECT_REST_URL, takes basic authentication and SSL settings for the REST API, and lists several Connect clusters for one Kafka cluster with CONNECT_RESOURCE_IDS. Its Kafka Connect management page covers creating connectors from a form with the plugin’s own documentation beside it, an export that creates the connector through a REST call, and restarting individual tasks or reading their stack traces. Managed connectors are covered on the Amazon MSK Connect and Confluent Cloud managed Connect provider pages.
Where it falls short. Its auto-restart restarts the named connector and its failing tasks on a timer; it does not keep a separate restart history beyond the audit log, and alert rules on connector state go through Prometheus and Alertmanager rather than being built in. It does not replace the JMX exporter for deep per-task throughput metrics. Kpow governs people working through Kpow, so the Connect REST API stays open to anyone the workers themselves let in. RBAC, masking, staged mutations and the full audit log need Kpow Enterprise; Community Edition is free for 3 clusters and 10 users.
Compare Kpow vs Kafbat UIKpow vs AKHQ
Rank 2 Kafbat UI
72 out of 110 Total
- Cost a year
- $0 licence, about $8,640 in operator time (modelled)
- On Kafka Connect
- Several Connect clusters per Kafka cluster, free; no managed connectors
- Sign-in
- OAuth2, OIDC and LDAP, free
- Out of the data path ×3 weight, this criterion counts 3 times toward the total
- 9 out of 10
- Production access on request ×2 weight, this criterion counts 2 times toward the total
- 4 out of 10
- Audit trail per person ×2 weight, this criterion counts 2 times toward the total
- 6 out of 10
- Connector operations ×2 weight, this criterion counts 2 times toward the total
- 6 out of 10
- Directory and Kafka sign-in
- 7 out of 10
- Many teams, shared clusters
- 6 out of 10
Why these scores for Kafbat UI
- Out of the data path 9 out of 10
- It is one stateless container with no database and no proxy, the same pass as Kpow.
- Production access on request 4 out of 10
- RBAC grants actions per resource and a cluster can be set read-only, but there is no approval step, no time-boxed grant, and its masking applies the same way to every viewer.
- Audit trail per person 6 out of 10
- Its audit log names the logged-in user and records reads when the level is set to ALL, but it writes to a topic or the console with no view in the product, so reading the trail is something you build.
- Connector operations 6 out of 10
- It shows connector and task status, creates and edits connectors, and restarts a connector or its failed tasks, across several Connect clusters with free RBAC, but documents no auto-restart and names no managed connectors.
- Directory and Kafka sign-in 7 out of 10
- It supports OAuth2 and OIDC, including Microsoft Entra ID, and LDAP or Active Directory, and its documentation does not list SAML.
- Many teams, shared clusters 6 out of 10
- Roles scope permissions per resource and list the clusters they apply to, with no tenant view of a team’s own resources.
On Kafka Connect. Kafbat UI lists Connect clusters beside each Kafka cluster in its configuration, and its feature list covers Kafka Connect next to topic browsing, consumer groups and schemas. The Kafbat UI review covers its RBAC and release history in detail.
Where it falls short. Its main Restart button restarts the connector instance only, and failed tasks are restarted through a separate action. Nothing restarts a failed connector automatically, and there is no way to grant production access for an hour and have it expire or to hold a change for approval. Its modelled running cost on one cluster is 6 engineer-hours a month, $8,640 a year at $120 an hour.
Rank 3 AKHQ
62 out of 110 Total
- Cost a year
- $0 licence, about $8,640 in operator time (modelled)
- On Kafka Connect
- A list of Connect clusters per connection
- Security default
- Disabled until you enable it
- Out of the data path ×3 weight, this criterion counts 3 times toward the total
- 9 out of 10
- Production access on request ×2 weight, this criterion counts 2 times toward the total
- 3 out of 10
- Audit trail per person ×2 weight, this criterion counts 2 times toward the total
- 4 out of 10
- Connector operations ×2 weight, this criterion counts 2 times toward the total
- 5 out of 10
- Directory and Kafka sign-in
- 6 out of 10
- Many teams, shared clusters
- 5 out of 10
Why these scores for AKHQ
- Out of the data path 9 out of 10
- It is one stateless container with no database and no proxy, the same pass as Kpow.
- Production access on request 3 out of 10
- Groups bind actions to resources by regex, but there is no approval step or time-boxed grant, masking is global, and without the JWT signing secret the restriction is in the UI only.
- Audit trail per person 4 out of 10
- Audit events are opt-in to a Kafka topic, reads are not recorded, and there is no view for the trail.
- Connector operations 5 out of 10
- It lists connector and task status and restarts a connector or a single task, with no failed-tasks-only restart, no auto-restart and no managed connectors named.
- Directory and Kafka sign-in 6 out of 10
- It supports LDAP, OIDC and header authentication from a proxy, does not list SAML, and ships with security disabled until you enable it.
- Many teams, shared clusters 5 out of 10
- Groups combine resource types with regex patterns on names and clusters, which limits what a role can reach, but there is no tenant view of a team’s own resources.
On Kafka Connect. AKHQ takes a list of Connect clusters under each Kafka connection, each with its own URL and optional basic authentication, and shows connectors, their tasks and their configuration. The AKHQ review covers the rest.
Where it falls short. Security is off until you configure it, the audit trail is an opt-in topic that does not record reads, and a failed connector stays failed until someone restarts it. Its modelled running cost on one cluster is 6 engineer-hours a month, $8,640 a year at $120 an hour.
Compare Kpow vs AKHQAKHQ review
Rank 4 Lenses
lenses.io
61 out of 110 Total
- Cost a year
- Team is $4,000 for up to 15 users on one cluster, $6,880 with operator time; 25 engineers needs a custom quote (modelled)
- On Kafka Connect
- Several Connect clusters, Connect alert rules built in
- Deployment
- HQ on PostgreSQL plus an agent and database per cluster
- Out of the data path ×3 weight, this criterion counts 3 times toward the total
- 4 out of 10
- Production access on request ×2 weight, this criterion counts 2 times toward the total
- 4 out of 10
- Audit trail per person ×2 weight, this criterion counts 2 times toward the total
- 7 out of 10
- Connector operations ×2 weight, this criterion counts 2 times toward the total
- 7 out of 10
- Directory and Kafka sign-in
- 7 out of 10
- Many teams, shared clusters
- 6 out of 10
Why these scores for Lenses
- Out of the data path 4 out of 10
- It runs a central HQ on PostgreSQL plus an agent and an agent database beside every cluster, and HQ has no high-availability option.
- Production access on request 4 out of 10
- Its masking is the strictest view-time model, global with no escape even for admins, but no approval step or time-boxed grant is described.
- Audit trail per person 7 out of 10
- Audit logs can be read in the product, with no need to build a consumer first.
- Connector operations 7 out of 10
- It shows task health, metrics and stack traces, restarts a connector or a single task, and has Connect-specific alert rules built in, but documents no auto-restart and names no managed connectors.
- Directory and Kafka sign-in 7 out of 10
- SSO spans Okta, Keycloak, OneLogin, Google and Entra ID, with basic authentication only on Community.
- Many teams, shared clusters 6 out of 10
- Roles attach to groups only, never to individuals, and no scoped view per team is described.
On Kafka Connect. Lenses manages several Connect clusters through its agent, with connector and task health, metrics and built-in alert rules for Connect. The Lenses review covers its tiers and deployment.
Where it falls short. A central HQ on PostgreSQL plus an agent and an agent database for every cluster is more to run beside Connect workers that already need care of their own, and a failed connector waits for a person to restart it. The Team licence stops at 15 users on one cluster, so a larger team is on a custom quote.
Compare Kpow vs LensesLenses review
Rank 5 The Connect REST API and scripts
53 out of 110 Total
- Cost a year
- $0 licence, about $11,520 in operator time (modelled)
- On Kafka Connect
- The API every tool on this page calls
- Security default
- HTTP with no authentication until the workers are configured
- Out of the data path ×3 weight, this criterion counts 3 times toward the total
- 10 out of 10
- Production access on request ×2 weight, this criterion counts 2 times toward the total
- 1 out of 10
- Audit trail per person ×2 weight, this criterion counts 2 times toward the total
- 2 out of 10
- Connector operations ×2 weight, this criterion counts 2 times toward the total
- 6 out of 10
- Directory and Kafka sign-in
- 3 out of 10
- Many teams, shared clusters
- 2 out of 10
Why these scores for The Connect REST API and scripts
- Out of the data path 10 out of 10
- There is nothing to deploy beyond the Connect workers themselves, which is the only option here that scores 10.
- Production access on request 1 out of 10
- Anyone who can reach a worker’s REST API can create, change or delete any connector, with no approval step, no expiring grant and no masking.
- Audit trail per person 2 out of 10
- The workers’ own logs are the only record, and nothing ties a call to a person in the directory.
- Connector operations 6 out of 10
- It has every operation, including restarting only the failed tasks and validating a config before it is submitted, but nothing watches the state, nothing restarts automatically, and each cluster is a separate script target.
- Directory and Kafka sign-in 3 out of 10
- Workers can serve the API over HTTPS with client certificates, and basic authentication comes from a REST extension, but there is no directory sign-in.
- Many teams, shared clusters 2 out of 10
- One URL reaches one Connect cluster with no notion of which team owns which connector.
On Kafka Connect. The Kafka Connect user guide lists the REST endpoints: connector and task status, POST /connectors/{name}/restart?includeTasks=true&onlyFailed=true to restart a connector’s failed tasks, a restart for an individual task, and PUT /connector-plugins/{type}/config/validate to check a config against the plugin’s definition. Every UI on this page is a client of this API.
Where it falls short. It is a toolkit, not a tool: status has to be polled, failures noticed and restarts scripted for every Connect cluster, and the REST API grants all of it to whoever can reach it unless the workers are secured. Its modelled running cost is 8 engineer-hours a month, $11,520 a year at $120 an hour.
Compare How to diagnose and fix a failed Kafka Connect connector
Rank 6 Redpanda Console
redpanda.com
52 out of 110 Total
- Cost a year
- $0 for the free build, about $8,640 in operator time (modelled); sign-in and RBAC need an unpublished Enterprise licence
- Licence
- Business Source License
- On Kafka Connect
- Several Connect clusters per deployment
- Out of the data path ×3 weight, this criterion counts 3 times toward the total
- 9 out of 10
- Production access on request ×2 weight, this criterion counts 2 times toward the total
- 2 out of 10
- Audit trail per person ×2 weight, this criterion counts 2 times toward the total
- 2 out of 10
- Connector operations ×2 weight, this criterion counts 2 times toward the total
- 5 out of 10
- Directory and Kafka sign-in
- 4 out of 10
- Many teams, shared clusters
- 3 out of 10
Why these scores for Redpanda Console
- Out of the data path 9 out of 10
- It is a self-hosted container with no database, the same pass as Kpow.
- Production access on request 2 out of 10
- The free community build has no access control of any kind, and RBAC needs a Redpanda Enterprise licence, with no approval step or time-boxed grant described.
- Audit trail per person 2 out of 10
- Redpanda’s audit log is a feature of Redpanda’s own brokers, so on Apache Kafka and its Connect clusters Console keeps no record of who did what, with or without an Enterprise licence.
- Connector operations 5 out of 10
- Redpanda’s documentation says it manages several Connect clusters, inspects and patches connectors, restarts, pauses and resumes tasks and deletes connectors, with no auto-restart and no managed connectors described.
- Directory and Kafka sign-in 4 out of 10
- It connects to Kafka-compatible brokers over the standard SASL mechanisms, but OIDC sign-in for people requires an Enterprise licence and is its only single sign-on protocol.
- Many teams, shared clusters 3 out of 10
- RBAC is licence-gated and each deployment reaches one broker cluster, so there is no single policy across development, staging and production.
On Kafka Connect. Redpanda Console is Redpanda’s web console, source-available under the Business Source License. Redpanda’s Kafka Connect configuration page for Console says it queries every configured Connect cluster for its status and lets you inspect or patch connectors, restart, pause and resume tasks, and delete connectors. The Redpanda Console review covers the licence terms in detail.
Where it falls short. Governance is bought from Redpanda, a broker vendor: sign-in and RBAC need an Enterprise licence whose price is not published, and Redpanda’s audit log is a feature of its own brokers, so on Apache Kafka no licence gives Console a record of who changed a connector. Each deployment reaches one broker cluster.
Rank 7 Conduktor
conduktor.io
69 out of 110 Total
- Cost a year
- 25 Console seats at $1,200 is $30,000 plus $2,880 operator time, so $32,880; Gateway Core adds $60,000 and Gateway Protect, which carries encryption and masking, a further $30,000 (modelled)
- On Kafka Connect
- Task-level auto-restart with history, connector alerts, Confluent Cloud managed connectors
- Deployment
- Console on PostgreSQL 13+; data-level controls through Gateway, a proxy
- Out of the data path ×3 weight, this criterion counts 3 times toward the total
- 3 out of 10
- Production access on request ×2 weight, this criterion counts 2 times toward the total
- 6 out of 10
- Audit trail per person ×2 weight, this criterion counts 2 times toward the total
- 8 out of 10
- Connector operations ×2 weight, this criterion counts 2 times toward the total
- 9 out of 10
- Directory and Kafka sign-in
- 7 out of 10
- Many teams, shared clusters
- 7 out of 10
Why these scores for Conduktor
- Out of the data path 3 out of 10
- Console needs PostgreSQL 13 or later, and its encryption, data-level masking and Virtual Clusters only work when client traffic goes through Gateway, a proxy in the data path.
- Production access on request 6 out of 10
- Masking can exempt users or groups, which beats every other tool here on who sees unmasked data, and cross-team access requests are approved by the owning team, but no expiring grant is described and topic creation that passes policy is a direct API call.
- Audit trail per person 8 out of 10
- Console logs produce, consume and admin requests across more than 70 event types with user, IP and timestamp, browsable in the UI and exported as CloudEvents.
- Connector operations 9 out of 10
- Conduktor’s Kafka Connect documentation describes connector and task views, an offsets tab, built-in connector alerts, and an auto-restart that checks every minute and, for self-managed connectors, restarts only the failed tasks with a 10-minute window and a history of each restart, plus Confluent Cloud managed connectors, level with Kpow on this criterion; MSK Connect is not described.
- Directory and Kafka sign-in 7 out of 10
- Its SSO configuration covers LDAP and OIDC, with guides for Okta, Entra ID and Keycloak, and does not describe SAML.
- Many teams, shared clusters 7 out of 10
- Permissions are set per user or group across clusters, but a user in several groups inherits the most permissive grant, and Virtual Clusters for multi-tenancy need Gateway.
On Kafka Connect. Conduktor’s Console manages Connect clusters from its Kafka Connect page: create connectors from the installed plugin classes, pause, resume, stop, restart or delete one connector or several at once, view committed offsets, set alerts, and enable auto-restart, which captures each failed task’s error message before restarting it. The Conduktor review covers the rest.
Where it falls short. Console needs PostgreSQL. Conduktor’s data-level controls, such as encryption, masking of the data itself and virtual clusters for multi-tenancy, run in Gateway, a Kafka proxy that client applications connect through, and Connect workers are Kafka clients too, so routing them through Gateway puts it in front of every connector’s reads and writes. On AWS Marketplace, Conduktor Enterprise lists Console at $1,200 a seat for the first 100 seats, Gateway Core, which carries virtual clusters, at $60,000 a year, and Gateway Protect, the add-on for encryption and masking, at a further $30,000.
Compare Conduktor review
What teams on Apache Kafka Connect need
This page is about tools that sit beside Apache Kafka Connect, the framework in Apache Kafka that runs source and sink connectors on a cluster of workers and manages them through a REST API, as the Kafka Connect user guide describes. It ranks tools for the team that runs those workers and the connectors on them, whether the Kafka underneath is self-managed, Amazon MSK or Confluent Cloud. What Connect is and how it works is covered in Kafka Connect, monitoring alone is compared in the best tools to monitor Kafka Connect connectors, and the broader field of Kafka tools is in the best Kafka management tools.
The failure that catches most teams is a connector that looks healthy while it moves no data. The Connect REST API reports a connector’s state and each of its tasks’ states separately, and a worker that is up keeps the connector RUNNING while a task behind it has failed. In the demonstration in New at Factor House: September 2026, a Postgres connector on a sample airline cluster read as running while its task had failed because the database refused the connection, so restarting the task would only have failed again; the fix was on the database side. Apache Kafka added a restart that takes includeTasks and onlyFailed parameters in KIP-745, so one call restarts only the failed tasks, but whether to restart at all depends on reading the task’s stack trace first. When many connectors run, the two signals that matter most are task errors, for example a sink failing after a backward-incompatible schema change, and the consumer lag of each sink connector’s consumer group, which is how ingestion into a lakehouse falling behind shows up, as the journey to an open lakehouse session describes for the Apache Iceberg Kafka Connect sink. The step-by-step fixes are in how to diagnose and fix a failed Kafka Connect connector.
Out of the data path. Every Connect task is an ordinary Kafka producer or consumer, and the worker configuration passes producer. and consumer. settings through to those clients, as the Kafka Connect user guide describes. A tool whose controls work only when client traffic passes through a proxy therefore sits in front of every connector’s reads and writes as well as the applications’, and a connector that copies a database into Kafka then depends on the proxy staying up. A management tool needs nothing more than the Connect REST API and a client connection to Kafka. Kpow is one container with no external database, installed in your own environment and out of the data path. Conduktor Console also connects directly, with a PostgreSQL database of its own; Conduktor’s data-level controls, such as encryption, masking of the data itself and virtual clusters, run in Conduktor Gateway, a Kafka proxy that client applications connect through.
Production access on request. Connector configurations are where the credentials live: database passwords, cloud keys and client overrides. The improvement proposal that added SSL to the REST interface, KIP-208, states the problem plainly: the interface was plain HTTP with no encryption or authentication, it carries passwords in connector configurations, and anyone with access to it can add connectors. The risk is not only reading secrets. CVE-2023-25194, listed on Apache Kafka’s security page, let anyone who could create or modify connectors through the Connect REST API set a connector client’s sasl.jaas.config to a JNDI login module and make the worker deserialise data from an attacker’s server. Apache Kafka’s own answers sit at the worker: rest.extension.classes for authentication on the REST API and config.providers to load secrets from outside the connector config, both in the configuration reference. What a tool adds on top is per person: who may create a connector, who may only pause or restart one, who may edit a config, and access that expires after the task. Those controls are compared across the field in Kafka RBAC tools.
Audit trail per person. A tool calls the Connect REST API with one credential, so the workers cannot tell the engineers working through it apart, and the only record of who restarted a connector or changed its config has to come from the tool. Automatic restarts belong in the same record, so that a connector that was revived at 3 a.m. shows up as such the next morning. The options are compared in Kafka audit logging tools.
Directory and Kafka sign-in. A Connect tool holds two connections: to Kafka with whatever SASL or TLS settings the cluster requires, and to each Connect cluster’s REST API over HTTPS, often with basic authentication or client certificates. People then sign in through the company directory over SAML, OpenID Connect or LDAP, so a connector change is tied to a named person rather than to a shared credential.
Many teams, shared clusters. A Connect cluster is shared by default: every connector submitted to it runs on the same workers, whichever team owns it. Each team needs its own view of its own connectors, topics and consumer groups, and permission to touch only those, usually by connector name prefix. One special case is replication: running MirrorMaker 2 as connectors on a Connect cluster, rather than through the standalone driver, makes replication visible and restartable like any other connector, and the geo-replication documentation describes both ways of deploying it. The move is thinly documented, and its hard step is offsets; MirrorMaker 2 on Connect walks through it.
Connector operations. The Connect framework is portable across every Kafka distribution; managed connectors and licensed connectors are not, because Amazon MSK Connect and Confluent Cloud’s fully managed connectors each run behind their own API with their own states and limits, and the migrating to open source Kafka session adds that a sink and its matching source connector are often licensed differently, so licensed connectors carry the same portability risk. A tool that reads only the open-source REST API leaves those connectors in a second console. Creating connectors is the other half. A form is useful even to teams that deploy connectors from Ansible or Terraform, because the Connect REST API exposes a validate endpoint that checks a config against the plugin’s own definition as it is typed, and the checked config can then go into the pipeline as code. Dead letter queues need care on the way back out: with errors.deadletterqueue.context.headers.enable set, Connect adds error-context headers to each record it writes to the dead letter queue (see the configuration reference), and a replay that copies those headers back puts a stack trace on a record that is no longer failing. Dead letter tooling is compared in Kafka DLQ tools.
No tool here leads on every point: Conduktor is level with Kpow on connector operations, restarting only the failed tasks automatically and keeping a restart history, Lenses has stronger built-in alert rules for Connect, and the JMX exporter goes deeper on per-task metrics. Kpow governs people working through Kpow, so the Connect REST API remains open to anyone the workers themselves let in, and securing it stays a job for the worker configuration.
Who runs Kpow on Apache Kafka Connect
TD Bank’s Event Streaming Platform team showed the Connectors view in its public talk, Running Kafka at bank scale, as part of day-to-day work in Kpow alongside schema comparisons and consumer lag. Kpow’s Connect support is documented for self-managed Kafka Connect, Amazon MSK Connect and Confluent Cloud managed connectors, and Factor House does not modify or extend Kafka and sells no Kafka distribution, so the same Connect views work whichever Kafka sits underneath. For customer accounts on specific platforms, the Amazon MSK page carries Belong and the self-managed Apache Kafka page carries Gmarket and Claritev; the Confluent Cloud page, the Confluent Platform page, the Aiven page, the NetApp Instaclustr page and the Strimzi page cover managed and operator-run Connect on those platforms.
Which customer shows which criterion
- Production access on request
- TD Bank
- Connector operations
- TD Bank
- Directory and Kafka sign-in
- TD Bank
-
TD Bank
- Connector operations
- Production access on request
- Directory and Kafka sign-in
- Connector triage
- Self-service for client teams
- On-prem and Confluent Cloud
TD’s Event Streaming Platform runs more than 20 clusters across on-prem servers and Confluent Cloud, and its client teams and platform team all work in Kpow, with access by Active Directory group. In the talk, staff engineer Sandy Yang shows the Connectors view: when a connector fails, its menu either restarts it or shows why it failed, including the stack trace, which she calls “very convenient”. The same console compares schema versions side by side, and production inspect access is granted for an hour or two through the Kpow API from a ServiceNow form.
How a team runs Apache Kafka Connect with Kpow
Installing it beside the workers. Kpow runs as one Docker container, a Java JAR or from the Helm charts, in the same network as the Connect workers. It needs no external database, because its snapshots, metrics and audit log live in topics on the Kafka cluster.
Connecting the Connect clusters. Each Connect cluster is added with CONNECT_REST_URL, with CONNECT_AUTH, CONNECT_BASIC_AUTH_USER and CONNECT_BASIC_AUTH_PASS where the workers require basic authentication and SSL settings for an HTTPS endpoint, and several Connect clusters for one Kafka cluster are listed with CONNECT_RESOURCE_IDS (Kafka Connect configuration). Amazon MSK Connect is reached through the AWS API with the instance’s IAM role, static keys or a cross-account STS role where Kpow runs in one AWS account and MSK Connect in another (MSK Connect provider page), and Confluent Cloud managed connectors with a Confluent Cloud API key (Confluent managed Connect).
Creating a connector. The create form lists the plugins installed on the workers, shows each plugin’s documentation beside its fields and displays form errors as the config is entered, and the finished connector can be deployed directly or exported as a REST call for a deployment pipeline; a JSON config file can also be imported (Kafka Connect management and Kafka Connect configuration).
Triage when a connector fails. The connector page shows connector and task state side by side; a failed task’s latest stack trace opens from the task table and the task restarts from the same row. For a sink connector, the view links straight to the consumer group it reads through, so lag and task state are read together, and data inspect reads the records on a dead letter topic like any other topic.
Restarting failed connectors automatically. With CONNECT_AUTO_RESTART set to a list of connector names or wildcards, Kpow restarts failed connectors and their failing tasks, waits 10 minutes by default before trying the same connector again (CONNECT_AUTO_RESTART_WINDOW_MS) and restarts at most 50 connectors per one-minute interval (CONNECT_AUTO_RESTART_LIMIT), so a cluster-wide outage does not turn into a flood of restart calls. Each automatic restart is written to the audit log as the kpow_system user and can be posted to Slack (auto-restart connectors).
Deciding who may do what. Kpow’s authorization actions split Connect into CONNECT_CREATE, CONNECT_ALTER_STATE (pause, stop, resume and restart), CONNECT_EDIT_CONFIG, CONNECT_DELETE and CONNECT_INSPECT, and RBAC sets Allow, Deny or Stage per action on resources matched by pattern, so the on-call role can restart a team’s connectors without being able to edit their configs. Tenants give each team a view limited to its own connectors, topics and groups. A temporary policy grants extra access for a set time and then expires, and staged mutations hold a connector deletion or config change until an administrator approves it.
Signing people in. Engineers sign in through SAML, OpenID Connect or LDAP, so every connector action carries a person from the company directory.
Watching state and keeping the record. Kpow exports connector state counts per Connect cluster, including connect_connector_failed_total and connect_connector_task_failed_total, to Prometheus (listed in the metrics glossary), so a failed task is a one-line Alertmanager rule, and the factor-telemetry repository ships a ready Grafana dashboard for Kafka Connect. The audit log records every connector action with the user from the identity provider, and a webhook sends those records to Slack, Microsoft Teams or any HTTP endpoint, such as a SIEM collector.
Kpow live demo
See the Kpow UI before you connect your Connect clusters
The live Kpow demo runs on two Apache Kafka clusters on Amazon MSK. It shows brokers, topics, consumer groups, schema registries and the __oprtr_audit_log topic where Kpow keeps its audit trail, with no signup. Connecting your own Kafka Connect clusters is the step to try next.
For platform teams choosing a tool for Kafka Connect.
Try the Kpow demoFAQ
What is the best tool for Kafka Connect?
On this page’s rubric, Kpow, with 99 of 110 points: it shows connector and task state with stack traces, restarts tasks and auto-restarts failed connectors with a cap and an audit entry, reaches self-managed Connect, MSK Connect and Confluent Cloud managed connectors from one place, splits connector permissions per action and per team, and runs as one container beside the cluster with no external database. Kafbat UI is the highest-scoring free option.
Does Kpow support Kafka Connect?
Yes. Kpow connects to any Kafka Connect cluster through its REST API with CONNECT_REST_URL, supports several Connect clusters per Kafka cluster, basic authentication and SSL (Kafka Connect configuration), and also manages Amazon MSK Connect and Confluent Cloud managed connectors through their own APIs.
Why does my connector say RUNNING when no data is moving?
Connect reports the connector’s state and each task’s state separately, and the connector stays RUNNING while its worker is up even if a task has failed. Read the task status and its stack trace through GET /connectors/{name}/status or a tool that shows tasks; if the cause is outside Connect, such as a database refusing connections, restarting the task will fail again until that is fixed. The Kafka Connect user guide lists the endpoints.
Can a Kafka UI restart failed connectors automatically?
Kpow and Conduktor both document automatic restarts. Kpow restarts named or wildcard connectors and their failing tasks with a 10-minute window and a cap of 50 per one-minute interval, and writes each restart to the audit log; Conduktor restarts only the failed tasks of self-managed connectors with a 10-minute window and keeps a restart history. Kafbat UI, AKHQ, Lenses and Redpanda Console document no automatic restart, and the Strimzi operator has its own for connectors it manages, covered on the Strimzi page.
Is the Kafka Connect REST API secure by default?
No. It serves plain HTTP with no authentication unless the workers are configured otherwise, and anyone who can reach it can create or change connectors, which KIP-208 set out to address and CVE-2023-25194 showed what that access allows. Configure HTTPS and a REST extension for authentication on the workers, load secrets through config.providers, and give people per-action permissions in the tool they use.
Is there a free Kafka UI for Kafka Connect?
Kpow Community Edition is free on up to 3 clusters and 10 users. Kafbat UI and AKHQ are open source and both manage Connect clusters. RBAC, masking, staged approvals and the full audit log need Kpow Enterprise. More free options are compared in the best free Kafka UI tools.
How these tools were scored
Five of the six criteria are the ones Factor House scores on every page for teams that share a Kafka cluster; the sixth is connector operations. They are listed here in order of weight. Each criterion is scored 0 to 10: 10 where a tool is the only one here doing it or clearly the best, 8 for a clean documented pass, 5 or 6 for partial support or support that needs work the reader must verify, 1 to 4 for a weak or indirect form, and 0 where it is absent. The weights add up to 11, so totals are out of 110.
1. Out of the data path (counts three times). The tool should run in your own environment, reach Kafka as an ordinary client and Connect through its REST API, and keep no data outside your own cluster. Scored lower: tools that need an external database of their own, and tools whose controls work only when application or connector traffic passes through a vendor’s proxy. A self-hosted container with no external database and no proxy scores 9, a tool with a database of its own 6, one with several databases or an agent per cluster 4, and one that needs both a database and a proxy for its controls 3; 10 is kept for an option with nothing to deploy at all, which here is the Connect REST API itself. This criterion is scored the same way on every Factor House page that uses it, and only its weight changes with the reader.
2. Production access on request (counts twice). Whether an engineer can be granted access to production for one task and have it expire, whether a destructive change can be held for a second person’s approval, and whether sensitive fields can be masked from people who do not need them.
3. Audit trail per person (counts twice). Whether the tool records each action, reads included, against the person from the identity provider, and whether that record can be read in the product and sent to the systems that keep it long term.
4. Connector operations (counts twice). Whether the tool shows task state with stack traces, restarts a connector, a task or only the failed tasks, restarts failed connectors automatically with a limit, creates and validates connectors, reaches several Connect clusters, and manages Amazon MSK Connect and Confluent Cloud managed connectors. The scores follow the same order as the per-feature scores on the best tools to monitor Kafka Connect connectors for the tools that page covers.
5. Directory and Kafka sign-in (counts once). Whether people sign in through SAML, OpenID Connect or LDAP, and whether the tool connects to Kafka with the same SASL or TLS settings as any client and to the Connect REST API over HTTPS with authentication.
6. Many teams, shared clusters (counts once). Whether each team can be given its own view of its own topics, consumer groups and connectors on a shared cluster, and whether one deployment reaches several clusters.
Costs are modelled for one production Kafka cluster with its Connect clusters and 25 engineers at $120 per engineer hour, using the same hours per tool class as Factor House’s other comparison pages. Tools with a licence carry the published price plus 2 hours a month to run. The open-source UIs carry 6 hours a month, $8,640 a year, to run, secure and keep current, and scripts against the REST API carry 8 hours a month, $11,520. Kpow’s $7,380 uses the published price of $4,500 per cluster with 100 users included. Lenses publishes a Team price of $4,000 a year for up to 15 users on one cluster, so 25 engineers is a custom quote. Conduktor’s Console is $1,200 a seat on AWS Marketplace, and its Gateway Core and Gateway Protect prices are added for the data-level controls; Conduktor prices Gateway per cluster with a 3-cluster minimum, and the listing does not say how many clusters that figure covers. Kpow Community Edition is free for 3 clusters and 10 users, so a 25-engineer team is on Enterprise. For free options compared at any team size, see the best free Kafka UI tools.
The criteria map onto Kafka Connect’s design in the figure below.
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: Out of the data path counts three times, Production access on request counts twice, Audit trail per person counts twice, Connector operations counts twice, Directory and Kafka sign-in counts once and Many teams, shared clusters counts once, for a total out of 110. Out of the data path counts three times. Every Connect task is itself a Kafka producer or consumer, so a tool whose controls work through a proxy sits in front of every connector's reads and writes as well as the applications', and a tool that needs a database of its own is one more stateful service beside the Connect workers. Production access on request, the per-person audit trail and connector operations count twice: the Connect REST API lets anyone who can reach it create or change a connector whose configuration holds credentials, so who may do that, and who did, decide whether a shared tool can be pointed at production Connect at all, and a tool that cannot read task state, restart the right thing and reach managed connectors leaves the team on curl. Directory and Kafka sign-in, and shared clusters, 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 99 out of 110. The other options follow by total. Conduktor is listed last whatever its total; on its total of 69 it would place third.
Related reading
- Kafka: the complete guide
- Kafka Connect
- Best tools to monitor Kafka Connect connectors
- How to diagnose and fix a failed Kafka Connect connector
- Best Kafka tools for self-managed Apache Kafka
- Best Kafka UI tools for Amazon MSK
- Best Kafka UI tools for Confluent Cloud
- Best Kafka management tools for banks