Best Kafka UI tools for OCI Streaming with Apache Kafka
ComparisonsThe best Kafka UI tool for OCI Streaming with Apache Kafka, Oracle Cloud’s managed Kafka service, fills the gap Oracle documents: the service has no native UI for cluster administration. It connects over SCRAM-SHA-512 or mutual TLS, manages topics, Kafka ACLs and the team’s own Kafka Connect clusters and schema registries, and adds per-person roles, time-boxed production access, masking and an audit trail on top of a super user credential. It runs as one container in the team’s own VCN, out of the data path, and can also manage clusters outside Oracle Cloud. Kpow, Kafbat UI, AKHQ, Lenses, Redpanda Console, the OCI Console with OCI Monitoring and Conduktor each cover part of that. Scored on the six weighted criteria explained below the rankings, Kpow ranks first with 86 out of 100, ahead of Kafbat UI at 69 and AKHQ at 65; Conduktor, listed last, totals 67.
Tools compared
| Rank | Tool | Total (out of 100) | Governance beyond Kafka ACLs | Out of the data path | Connect and registries you run | SCRAM and mTLS sign-in | On-prem and cloud together | Inspecting topic data | Cost a year, one cluster (modelled) |
|---|---|---|---|---|---|---|---|---|---|
| 1 | Kpow | 86 | RBAC, staged approvals, temporary access, masking, tenants, audit | One container, no external database, not a proxy | Several Connect clusters and registries | SCRAM and mTLS documented for OCI; standard image | One deployment across environments | kJQ search, data inspect, replay | $7,380 |
| 2 | Kafbat UI | 69 | RBAC, global masking, opt-in audit | One container | Free; one registry address per cluster | Generic SCRAM guide; named by Oracle | Many clusters, per-cluster settings | Message browsing | $8,640 |
| 3 | AKHQ | 65 | Group roles, no masking | One container | Free; Protobuf on the read side only | Generic client properties; named by Oracle | Many clusters from one file | Message browsing | $8,640 |
| 4 | Lenses | 64 | SSO and RBAC from Team tier, audit | HQ on PostgreSQL plus an agent per cluster | Strong connector monitoring | Generic client settings; no OCI guide | One HQ, agent per cluster | SQL over topics | $2,880 plus a quoted licence |
| 5 | Redpanda Console | 62 | Behind a paid Enterprise licence | One container | Several Connect clusters, one registry | Generic settings; no OCI guide | One cluster per deployment | Message browsing | $8,640 plus an unpublished licence for RBAC |
| 6 | OCI Console and OCI Monitoring | 40 | IAM policies for the cluster resource, OCI Audit | Nothing to deploy | No managed Connect or registry | Attaches the Vault secret and CA bundle | OCI clusters only | No topics or records | $11,520 |
| 7 | Conduktor | 67 | Strong; data-level controls through Gateway | Console on PostgreSQL; Gateway, a proxy, for data-level controls | Connect and ksqlDB in Console | Generic client settings; no OCI guide | Many providers and on-prem | Message browsing | $32,880; $122,880 with Gateway Core and Protect |
The tools, ranked for OCI Streaming with Apache Kafka
Rank 1 Kpow
86 out of 100 Total
Try Kpow in the live demo No signup needed.
- Cost a year
- $4,500 per cluster with 100 users included, plus about $2,880 in operator time, so $7,380 on one cluster (modelled)
- OCI sign-in
- SASL/SCRAM-SHA-512 with the OCI Vault credentials, or mTLS
- Deployment
- One container on OKE or OCI Compute, no external database; the standard image, no OCI-specific build
- Governance beyond Kafka ACLs ×3 weight, this criterion counts 3 times toward the total
- 9 out of 10
- Out of the data path ×2 weight, this criterion counts 2 times toward the total
- 9 out of 10
- Connect and registries you run ×2 weight, this criterion counts 2 times toward the total
- 8 out of 10
- SCRAM and mTLS sign-in
- 8 out of 10
- On-prem and cloud together
- 8 out of 10
- Inspecting topic data
- 9 out of 10
Why these scores for Kpow
- Governance beyond Kafka ACLs 9 out of 10
- RBAC per action and resource, staged approvals, time-boxed temporary policies, masking in data inspect, tenants for shared clusters, sign-in through SAML, OIDC or LDAP, and an audit log that names the person are all documented as Enterprise features.
- Out of the data path 9 out of 10
- It runs as one container or JAR and keeps its snapshots, metrics and audit log in topics on your own cluster, with no dependency beyond Kafka, and connects to the OCI cluster like any Kafka client, so it sits beside the cluster rather than in front of it; only the OCI Console, with nothing to deploy, scores higher.
- Connect and registries you run 8 out of 10
- It manages several Kafka Connect clusters and Confluent-compatible schema registries per Kafka cluster through their REST APIs, which is what a team on OCI runs because Oracle offers neither as a managed service; it takes the same score as for Connect and registries on the self-managed Kafka page.
- SCRAM and mTLS sign-in 8 out of 10
- Kpow’s OCI provider documentation gives SASL/SCRAM-SHA-512 settings with the username and password from the OCI Vault secret and mTLS settings with PKCS12 keystores, in the standard image, a clean documented pass for both methods Oracle supports.
- On-prem and cloud together 8 out of 10
- Kpow’s provider documentation covers OCI Streaming with Apache Kafka beside self-managed Kafka, Amazon MSK, Confluent, Google Cloud and others, and one instance manages up to 12 clusters with the same roles, masking and audit log; OCI needs no separate build.
- Inspecting topic data 9 out of 10
- Data inspect with kJQ filtering, decoding of Avro, JSON Schema and Protobuf records against the team’s registry, and replay are core Kpow features.
On Oracle Cloud. Kpow’s OCI Streaming provider documentation covers both of Oracle’s services. For OCI Streaming with Apache Kafka it gives SASL_SSL with SCRAM-SHA-512 and the username and password stored in the OCI Vault secret, or SSL with PKCS12 keystore and truststore settings for mutual TLS, and notes that Kafka ACLs, which control topics and consumer groups, are fully supported in Kpow. Both carry the Community badge. The quickstart in Integrate Kpow with OCI Streaming for Kafka runs the standard Docker image with five environment variables, and adds the team’s own Kafka Connect and schema registry with CONNECT_REST_URL and SCHEMA_REGISTRY_URL.
Where it falls short. Kpow governs people working through Kpow; applications still connect with their own SCRAM credentials or certificates, and Kafka ACLs remain the control for them. Kpow reads the SCRAM credential from its own configuration, so rotating the Vault secret means updating Kpow’s configuration as well as every other client. RBAC, masking, staged mutations and the audit log need Kpow Enterprise; Community Edition is free for 3 clusters and 10 users. On Oracle’s serverless OCI Streaming service, as distinct from OCI Streaming with Apache Kafka, Kpow runs with restricted capability because that service does not implement the complete Kafka API.
Compare Kpow vs Kafbat UIKpow vs AKHQ
Rank 2 Kafbat UI
69 out of 100 Total
- Cost a year
- $0 licence, about $8,640 in operator time (modelled)
- OCI sign-in
- SCRAM-SHA-512 and SSL through its generic Kafka settings; named in Oracle's FAQ
- Connect and registry
- Free; one schema registry address per cluster
- Governance beyond Kafka ACLs ×3 weight, this criterion counts 3 times toward the total
- 6 out of 10
- Out of the data path ×2 weight, this criterion counts 2 times toward the total
- 9 out of 10
- Connect and registries you run ×2 weight, this criterion counts 2 times toward the total
- 6 out of 10
- SCRAM and mTLS sign-in
- 7 out of 10
- On-prem and cloud together
- 6 out of 10
- Inspecting topic data
- 8 out of 10
Why these scores for Kafbat UI
- Governance beyond Kafka ACLs 6 out of 10
- It offers LDAP and OIDC sign-in, resource-level RBAC, global masking and an opt-in audit topic, which is one grade below the commercial tools.
- Out of the data path 9 out of 10
- It is a self-hosted container with no database, the same pass as Kpow and the other open-source UIs.
- Connect and registries you run 6 out of 10
- Schema Registry and Kafka Connect are free, though its cluster configuration takes a single schema registry address and its review records serde auto-selection broken across minor releases.
- SCRAM and mTLS sign-in 7 out of 10
- Its SASL_SCRAM guide gives SCRAM-SHA-512 settings over SASL_SSL, and Oracle’s FAQ names Kafbat among the third-party tools a team can deploy in OCI, but neither project nor Oracle publishes an OCI-specific setup.
- On-prem and cloud together 6 out of 10
- It covers self-managed Kafka, MSK, Google Cloud and other managed services from one instance, but Confluent Cloud connectivity broke in v1.4.x and v1.5.0.
- Inspecting topic data 8 out of 10
- Message browsing and inspection are core features of the open-source UI.
On Oracle Cloud. Kafbat UI’s SASL_SCRAM guide sets SASL_SSL and SCRAM-SHA-512 with a JAAS line in its cluster properties, which is the setting OCI’s SCRAM listener expects. Oracle’s FAQ for the service names Kafbat and AKHQ as tools a team can deploy within OCI to manage and monitor its clusters. The Kafbat UI review covers its RBAC and release history.
Where it falls short. No vendor stands behind it, and roles, masking and the audit topic sit a grade below the commercial tools, with no tenant view of a team’s own resources. Its modelled running cost on one cluster is 6 engineer-hours a month, $8,640 a year at $120 an hour.
Rank 3 AKHQ
65 out of 100 Total
- Cost a year
- $0 licence, about $8,640 in operator time (modelled)
- OCI sign-in
- Ordinary Kafka client properties per connection; named in Oracle's FAQ
- Connect and registry
- Free
- Governance beyond Kafka ACLs ×3 weight, this criterion counts 3 times toward the total
- 5 out of 10
- Out of the data path ×2 weight, this criterion counts 2 times toward the total
- 9 out of 10
- Connect and registries you run ×2 weight, this criterion counts 2 times toward the total
- 5 out of 10
- SCRAM and mTLS sign-in
- 7 out of 10
- On-prem and cloud together
- 7 out of 10
- Inspecting topic data
- 8 out of 10
Why these scores for AKHQ
- Governance beyond Kafka ACLs 5 out of 10
- It has LDAP, OIDC and basic sign-in with group-based roles, and groups can limit a role to resources matching a regex, with no masking or audit comparable to the commercial tools.
- Out of the data path 9 out of 10
- It is a self-hosted container with no database.
- Connect and registries you run 5 out of 10
- Schema Registry and Kafka Connect come free, though its review records Protobuf support limited to the deserialiser side.
- SCRAM and mTLS sign-in 7 out of 10
- AKHQ takes ordinary Kafka client properties per connection, so SCRAM-SHA-512 and SSL client certificates work, and Oracle’s FAQ names it among the tools a team can deploy in OCI; neither publishes an OCI-specific setup.
- On-prem and cloud together 7 out of 10
- Each cluster is a named connection in one configuration file, on any distribution.
- Inspecting topic data 8 out of 10
- Topic data browsing is a core AKHQ feature.
On Oracle Cloud. AKHQ connects to an OCI cluster with the same security.protocol, sasl.mechanism and sasl.jaas.config properties Oracle documents for any Kafka client, or with SSL keystore properties for mutual TLS. Oracle’s FAQ names it, with Kafbat, as a tool a team can run in OCI. The AKHQ review covers the rest.
Where it falls short. It ships with security disabled until you enable it, has no masking, no approval step and no audit trail comparable to the commercial tools, and no tenant view of a team’s own resources.
Compare Kpow vs AKHQAKHQ review
Rank 4 Lenses
lenses.io
64 out of 100 Total
- Cost a year
- $2,880 operator time, plus a licence quoted above 15 users (modelled)
- OCI sign-in
- Ordinary Kafka client settings; no OCI guide
- Deployment
- HQ on PostgreSQL plus an agent and database per cluster
- Governance beyond Kafka ACLs ×3 weight, this criterion counts 3 times toward the total
- 7 out of 10
- Out of the data path ×2 weight, this criterion counts 2 times toward the total
- 4 out of 10
- Connect and registries you run ×2 weight, this criterion counts 2 times toward the total
- 6 out of 10
- SCRAM and mTLS sign-in
- 6 out of 10
- On-prem and cloud together
- 7 out of 10
- Inspecting topic data
- 10 out of 10
Why these scores for Lenses
- Governance beyond Kafka ACLs 7 out of 10
- SSO, SAML and RBAC come from the Team tier and audit logs are in the product, one grade below the tools with approvals and time-boxed access.
- Out of the data path 4 out of 10
- It is self-hosted, but a central HQ on PostgreSQL plus an agent and an agent database for every cluster is the heaviest footprint here apart from Conduktor with Gateway.
- Connect and registries you run 6 out of 10
- Connector task state and alerting are its strongest areas in the Connect monitoring tools comparison and schema registries are supported.
- SCRAM and mTLS sign-in 6 out of 10
- Lenses connects as a Kafka client to any provider exposing a Kafka-compatible API, so SCRAM and mTLS work through ordinary client settings, with no OCI guide from either vendor.
- On-prem and cloud together 7 out of 10
- It connects to any provider exposing a Kafka-compatible API, one agent per cluster.
- Inspecting topic data 10 out of 10
- SQL over topics is the centre of the product and the strongest query model on this page, ahead of Kpow’s kJQ.
On Oracle Cloud. Lenses describes its agent as a Kafka client that can connect to any provider exposing a Kafka-compatible API, and its provider documentation has no Oracle page, so an OCI cluster is set up with generic SCRAM or SSL settings.
Where it falls short. The Team licence stops at 15 users on one cluster, and every cluster needs its own agent and agent database in the VCN. The Lenses review covers the rest.
Compare Kpow vs LensesLenses review
Rank 5 Redpanda Console
redpanda.com
62 out of 100 Total
- Cost a year
- $0 for the free build, about $8,640 in operator time (modelled); RBAC and SSO need an unpublished Enterprise licence
- OCI sign-in
- SCRAM-SHA-512 and TLS through generic settings; no OCI guide
- Connect and registry
- Several Connect clusters and a registry
- Governance beyond Kafka ACLs ×3 weight, this criterion counts 3 times toward the total
- 6 out of 10
- Out of the data path ×2 weight, this criterion counts 2 times toward the total
- 9 out of 10
- Connect and registries you run ×2 weight, this criterion counts 2 times toward the total
- 5 out of 10
- SCRAM and mTLS sign-in
- 6 out of 10
- On-prem and cloud together
- 2 out of 10
- Inspecting topic data
- 8 out of 10
Why these scores for Redpanda Console
- Governance beyond Kafka ACLs 6 out of 10
- RBAC, OIDC sign-in and masking exist but need a paid Redpanda Enterprise licence, and Console shuts down if that licence expires.
- Out of the data path 9 out of 10
- It is a self-hosted container with no database.
- Connect and registries you run 5 out of 10
- One instance queries several Kafka Connect clusters and a schema registry, and its review records a schema registry display bug filed in April 2026.
- SCRAM and mTLS sign-in 6 out of 10
- Its Kafka connection settings cover SCRAM-SHA-512 and TLS client certificates, with no OCI guidance from Redpanda or Oracle.
- On-prem and cloud together 2 out of 10
- It is configured with a single broker list, so one install never spans distributions, and ten clusters means ten consoles.
- Inspecting topic data 8 out of 10
- Message browsing is the core of the product.
On Oracle Cloud. Redpanda’s Console documentation describes SASL mechanisms including SCRAM-SHA-512 and TLS with client certificates, and does not mention OCI Streaming with Apache Kafka. The Redpanda Console review covers the rest.
Where it falls short. A team on Oracle Cloud buys a Redpanda licence to get RBAC, SSO or masking, and that price is not published. One deployment reaches one broker cluster.
Rank 6 OCI Console and OCI Monitoring
40 out of 100 Total
- Cost a year
- $0 licence and nothing to run; topics, ACLs and records fall to the Kafka CLI, modelled at 8 hours a month, $11,520 (modelled)
- OCI sign-in
- Your OCI identity and IAM policies, for the cluster resource only
- Deployment
- Nothing to deploy
- Governance beyond Kafka ACLs ×3 weight, this criterion counts 3 times toward the total
- 3 out of 10
- Out of the data path ×2 weight, this criterion counts 2 times toward the total
- 10 out of 10
- Connect and registries you run ×2 weight, this criterion counts 2 times toward the total
- 1 out of 10
- SCRAM and mTLS sign-in
- 7 out of 10
- On-prem and cloud together
- 1 out of 10
- Inspecting topic data
- 1 out of 10
Why these scores for OCI Console and OCI Monitoring
- Governance beyond Kafka ACLs 3 out of 10
- IAM policies decide who may create, update and delete clusters and cluster configurations, and OCI Audit records those API calls, but Kafka ACLs are managed with the Kafka CLI, and the console adds no masking, no approval step and no per-person record of what an engineer read or changed inside the cluster.
- Out of the data path 10 out of 10
- There is nothing to deploy and nothing between clients and brokers, since this is Oracle’s own control plane, which makes it the best on this criterion.
- Connect and registries you run 1 out of 10
- Oracle offers no managed Kafka Connect or schema registry yet, and the console has nothing for the ones a team runs itself.
- SCRAM and mTLS sign-in 7 out of 10
- The console is where the OCI Vault secret for SASL/SCRAM and the CA bundle for mutual TLS are attached to a cluster, although it covers the one super user credential and is not itself a Kafka client.
- On-prem and cloud together 1 out of 10
- It shows OCI clusters only, so clusters on-prem or on other clouds need another tool.
- Inspecting topic data 1 out of 10
- Oracle’s FAQ says the service has no native UI for cluster administration and that topic configuration is managed with the Kafka CLI, SDKs or Kafka APIs, so the console shows no topics or records.
What it covers. The console creates and resizes clusters, chooses the broker shape, OCPUs and storage, applies cluster configurations, and shows the cluster details: bootstrap URLs for mTLS and SASL/SCRAM, configuration properties and network resources. Broker metrics such as CPU, disk space, under-replicated and offline partitions are charted and alarmed in OCI Monitoring under the oci_kafka namespace.
Where it falls short. Oracle’s FAQ says there is no native UI for cluster administration and points teams to third-party tools such as Kafbat and AKHQ. Topics, ACLs, consumer groups and records are handled with the Kafka CLI. Providers often do a great job running and monitoring the cluster itself, and Oracle is no exception; the gap is the application side, which is your code, and the per-person controls a shared cluster needs.
Rank 7 Conduktor
conduktor.io
67 out of 100 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)
- OCI sign-in
- Ordinary Kafka client settings; no OCI guide
- Deployment
- Console on PostgreSQL 13+; data-level controls through Gateway, a proxy
- Governance beyond Kafka ACLs ×3 weight, this criterion counts 3 times toward the total
- 9 out of 10
- Out of the data path ×2 weight, this criterion counts 2 times toward the total
- 3 out of 10
- Connect and registries you run ×2 weight, this criterion counts 2 times toward the total
- 6 out of 10
- SCRAM and mTLS sign-in
- 6 out of 10
- On-prem and cloud together
- 8 out of 10
- Inspecting topic data
- 8 out of 10
Why these scores for Conduktor
- Governance beyond Kafka ACLs 9 out of 10
- RBAC, SSO by OIDC or LDAP, an audit log and masking are strong, but encryption, field-level masking of the data itself and multi-tenancy run through Gateway.
- Out of the data path 3 out of 10
- Console needs PostgreSQL 13 or later, and the data-level controls counted in its governance score run in Gateway, a proxy that clients connect through, so using them puts Conduktor in the data path.
- Connect and registries you run 6 out of 10
- Kafka Connect and ksqlDB management are in Console and Confluent-compatible and AWS Glue registries are supported.
- SCRAM and mTLS sign-in 6 out of 10
- Its cluster configuration takes ordinary Kafka client security settings, which cover SCRAM and mTLS, with no OCI guide from either vendor.
- On-prem and cloud together 8 out of 10
- Its cluster configuration covers Confluent Cloud, Aiven, Amazon MSK, Google Cloud and Cloudera, and Console works across clusters.
- Inspecting topic data 8 out of 10
- Console browses and filters topic data.
On Oracle Cloud. Conduktor’s cluster configuration documentation has provider guides for Confluent Cloud, Aiven, Amazon MSK, Google Cloud and Cloudera, and none for OCI, so an OCI cluster is added with generic SCRAM-SHA-512 or SSL settings. Conduktor’s Gateway documentation describes Gateway as a Kafka proxy between client applications and brokers, which is where its encryption, masking of the data itself and virtual clusters for multi-tenancy are enforced.
Where it falls short. Console connects directly and 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, which puts Gateway in the data path for those clients. On AWS Marketplace, Conduktor Enterprise lists Gateway Core at $60,000 a year, Gateway Protect, the add-on for encryption and masking, at a further $30,000, and Console at $1,200 a seat for the first 100 seats. The Conduktor review covers the rest.
Compare Conduktor review
What teams on OCI Streaming with Apache Kafka (Oracle Cloud) need
This page is about OCI Streaming with Apache Kafka, the managed service in which Oracle runs dedicated Apache Kafka clusters inside a customer’s OCI tenancy. Oracle also runs an older serverless service called OCI Streaming that accepts most Kafka APIs; it is covered in the FAQ below. Everything on this page is about what a tool adds on top of the managed service, not about replacing it.
OCI Streaming with Apache Kafka provisions, patches and recovers the brokers, on starter clusters of 1 to 30 brokers or high availability clusters of at least 3 brokers across availability or fault domains. What it leaves to the team is everything inside the cluster. Oracle’s FAQ for the service says that it does not provide a native UI for cluster administration, that topic configuration, partitions and replication are managed with the Kafka CLI, SDKs or Kafka APIs because the OCI Console does not manage them, and that teams can deploy third-party tools such as Kafbat and AKHQ within OCI to manage and monitor their clusters. A Kafka tool on OCI is therefore the only window most engineers have onto topics, consumer groups, ACLs and records, rather than an addition to a provider console that already shows them.
The service is reached over standard Kafka protocols, SASL/SCRAM-SHA-512 with credentials held in OCI Vault, or mutual TLS, with no plugin or sidecar. Any tool built on the Apache Kafka Java client can connect with the settings Oracle documents for its own Kafka client setup, which is why sign-in counts for less here than on clouds such as Google Cloud, where a tool needs the provider’s own authentication library. Kpow’s support is defined against Apache Kafka behaviour rather than against a provider’s extensions, and on OCI it uses its standard image.
Governance beyond Kafka ACLs. The SASL/SCRAM route Oracle documents creates one credential. A team creates a secret in OCI Vault and applies it to the cluster with the enable-superuser command, as Oracle’s SASL/SCRAM guide sets out, and Oracle’s service overview describes OCI Vault as where the super user credentials are stored. A super user is the principal Apache Kafka’s authorizer lets through where ACLs would otherwise restrict access, so a shared tool configured with that credential can read, alter and delete everything on the cluster, and a tool with no roles of its own passes that reach to each person who opens it. Per-person roles, production access granted on request and masking therefore have to come from the tool. For the tool’s own connection, a mutual TLS certificate whose principal is limited by Kafka ACLs is the route that keeps it below super user, and Kpow documents the minimum ACLs it needs.
Both default cluster configurations in Oracle’s service concepts set allow.everyone.if.no.acl.found=true, so any authenticated principal can use a topic or consumer group that has no ACL of its own. Oracle’s ACL guide shows how to change that to deny by default, and its add-ons page asks teams to create ACLs and set the property to false before installing the public connectivity add-on. After that change every application principal needs explicit ACLs, written with the Kafka CLI unless a tool manages them, and an ACL change made through a shared tool is recorded only if the tool records it.
The brokers also know nothing of a company directory. Oracle’s FAQ says the service supports SASL/SCRAM and mutual TLS, that LDAP and Kerberos are not supported, and that OCI Identity and Access Management for Kafka clients is planned; its feature limits list OAuth as not supported. OCI IAM policies decide who may create, update or delete a cluster, and the OCI Audit service records calls to OCI’s public APIs, while Oracle’s logging page for the service offers audit logs and states that broker logs are not available. A topic read, an offset reset or a message produced over the Kafka protocol is therefore recorded nowhere in OCI under the engineer’s name. Directory sign-in to the tool, roles taken from directory groups and an audit log in the tool are where people are named. A UI with no audit log leaves no record of who reset an offset or produced a message, which falls short of the change-management and audit controls in frameworks such as NIST SP 800-53, however good the UI is.
The credential has an operational property too. Oracle’s SASL/SCRAM guide says the cluster cannot detect a rotated Vault secret, so after a manual rotation the team runs Update SASL SCRAM on the cluster, or clients keep failing against the old secret. Every client configured with that credential, a shared tool included, is updated in the same change, which is one more reason to keep people off the super user credential and give each engineer an identity in the tool.
Out of the data path. One requirement cuts across all of these: where the tool runs. A tool that runs as a container in your own VCN, next to the cluster, and connects the way any Kafka client does, adds nothing to the path your producers and consumers take. A tool whose controls are enforced by a proxy that every client connects through becomes part of that path, and it has to be sized, kept available and kept in step with every client upgrade. 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.
On OCI a proxy would also be the one component in the path that Oracle does not run. The service detects a failed broker and replaces it, reusing its storage where it can, and Oracle’s overview says producers and consumers then continue with the same broker endpoints as before. That recovery covers the brokers only. A proxy placed in front of them is deployed, sized and kept available by the customer, so a proxy failure is an outage for every producer and consumer behind it that Oracle’s broker recovery does not touch.
Where a tool can run is settled largely by Oracle’s networking. Clusters are created with private connectivity, reachable from the VCN and subnet chosen at creation, with VCN peering for other VCNs, according to Oracle’s getting started guide and concepts page. The subnet has to allow port 9092 for SASL/SCRAM or 9093 for mutual TLS. A self-hosted tool on OKE or an OCI Compute instance in that subnet reaches the brokers at the same bootstrap address as the applications.
Connect and registries you run. Oracle’s FAQ says the service does not include a managed Kafka Connect service or a managed schema registry yet, with both planned for future releases. Change data capture with Debezium or Oracle GoldenGate runs on VMs a team manages, Oracle’s overview says, and the feature limits list custom connectors as not supported in the managed service. On OCI today, then, every Kafka Connect cluster and every schema registry is one the team deploys on OCI Compute or OKE, and a Kafka tool is the only console those components get. The alternative to one tool is several open source projects assembled by the team, such as Burrow or kafka-lag-exporter for lag beside a registry UI and a Connect UI, each to deploy, secure and upgrade. Schema-aware production matters as much as reading: producing test messages through a tool that fetches the registered schema and serialises against it keeps malformed data off a topic, which the NORD/LB case study credits with reducing incidents caused by bad schemas.
SCRAM and mTLS sign-in. Oracle documents SCRAM-SHA-512 and mutual TLS, and every tool on this page can use them through ordinary Kafka client settings. Broker certificates are signed by the public DigiCert Global Root G2 by default, which Oracle’s mTLS guide notes most JDK truststores already include. The scores differ by what each vendor documents for OCI: Kpow has an OCI provider page for both methods, Kafbat UI and AKHQ are named by Oracle and connect through their generic settings, and the rest publish nothing for OCI.
On-prem and cloud together. A team on OCI usually has more than one cluster before another provider is counted. Oracle’s FAQ points to MirrorMaker 2 for active/active or active/standby replication across clusters and regions, and the service limits on the concepts page allow 5 clusters per tenancy. Apache Kafka’s multi-tenancy documentation describes the controls that make sharing one cluster between teams work. Clusters on-prem are reached over OCI FastConnect or a VPN, and the public connectivity add-on lets clients outside OCI authenticate over SCRAM or mutual TLS from allowed CIDR ranges. A tool that covers OCI, on-prem and other clouds from one deployment keeps one set of roles and one audit trail across all of them.
Inspecting topic data. With no record view in the OCI Console, the route Oracle’s client guide documents for reading data is an OCI Compute instance, an SSH session to it and the Kafka command-line tools with a client.properties file holding the Vault username and password. Everyone who uses that session acts as the super user, and nothing records which topics they read. Replaying a dead-lettered record is a further job for a tool rather than the CLI. Writing it back onto the main topic makes every consumer of that topic process it again, so the replay belongs on a retry topic for the one consumer that failed, and role-based access can pin both ends of it: only records from a consumer’s own dead letter topic may be copied, and only into that consumer’s retry topic, as Clone to topic for DLQs in Apache Kafka sets out. The replay then becomes a recorded action rather than a command typed on a shared host.
Lag is the other blind spot. The oci_kafka metrics in OCI Monitoring are per broker, such as CPU, available disk space, under-replicated and offline partitions, and failed fetch and produce requests, and include no consumer group lag. Oracle recommends monitoring client metrics on the team’s own dashboards, and its FAQ says topic and partition metrics are to come. Disk deserves its own alarm: by default a broker at 97 percent disk capacity rate-limits producers and at 98 percent blocks them while consumers carry on, so a disk-full broker looks to an application team like a producer fault. A tool that computes lag for every consumer group from the Kafka API and exports it to Prometheus fills the gap beside OCI Monitoring.
No tool here leads on every criterion. Kpow does not replace OCI Monitoring for broker CPU, disk and memory, which Oracle collects and alarms on; it governs people working through Kpow, so applications keep their own SCRAM credentials or certificates and Kafka ACLs stay the control for them. Lenses has the stronger query model with SQL over topics, and the OCI Console needs nothing deployed at all. Kpow’s governance features need its Enterprise licence.
Who runs Kpow on OCI Streaming with Apache Kafka (Oracle Cloud)
No Kpow customer has yet described in public how it runs Kpow on OCI Streaming with Apache Kafka, so the public record for the service is Factor House’s own: the OCI provider documentation, which covers both of Oracle’s Kafka-compatible services, and the step-by-step guide Integrate Kpow with OCI Streaming for Kafka. At the September 2026 product session, an attendee whose organisation uses OCI Streaming asked whether the new agent skills would work for it, and the answer was that they work wherever Kpow is connected and its API is enabled.
The nearest public customer evidence is on Oracle Cloud infrastructure rather than on the managed service. Claritev runs its own Kafka and is moving it to Oracle Kubernetes Engine, with Kpow beside it; its card below is tagged with the rubric criteria its evidence speaks to. Teams that run Kpow on other managed Kafka services and have said so in public are on the Amazon MSK page, where Belong describes masking and replay on MSK, and on the banking page, where TD Bank describes production access granted for an hour or two through the Kpow API and a Kpow tenant for each onboarded team.
Which customer shows which criterion
- Governance beyond Kafka ACLs
- Claritev
- Inspecting topic data
- Claritev
-
Claritev
- Governance beyond Kafka ACLs
- Inspecting topic data
- Kafka on Oracle Kubernetes Engine
- Broker out of sync
- Four production clusters
Claritev’s middleware team runs its own Kafka for claims processing at millions of messages a day, with Kpow across four production clusters and two pre-production, and is moving that self-managed Kafka from Rancher Kubernetes to Oracle Kubernetes Engine (OKE), with Factor House providing the setup instructions for running Kpow on OKE. Its brokers are its own rather than OCI Streaming with Apache Kafka, so this is evidence of Kpow on Oracle Cloud infrastructure, not on the managed service. Kpow’s role-based access separates elevated, auditable admin access for the middleware team from read-only access for developers in production. In one incident Kubernetes reported every pod healthy and Prometheus raised no alert while a cluster was degraded: “We went into Kpow and could see the brokers were out of sync. It showed us exactly which broker wasn’t running.”
Source: Claritev case study
How a team runs OCI Streaming with Apache Kafka (Oracle Cloud) with Kpow
Installing it in the tenancy. A team installs Kpow on OKE with the Helm charts, runs the Docker image on an OCI Compute instance, or runs the JAR directly, using the standard Kpow image in each case. The instance or OKE cluster sits in a subnet that can reach the brokers on port 9092 or 9093. The Helm charts are open source and listed on Artifact Hub, which publishes a security report for each chart version. Kpow is priced per cluster rather than per broker, which suits a service where a cluster grows from 1 to 30 brokers as the team adds them.
Signing in to the cluster. For SASL/SCRAM, Kpow connects with SASL_SSL, SCRAM-SHA-512 and a SASL_JAAS_CONFIG holding the username and password from the OCI Vault secret, which are distinct from anyone’s Oracle Cloud console login. For mutual TLS it connects with SSL and PKCS12 keystore and truststore settings. Both are in Kpow’s OCI provider documentation. A team that wants Kpow’s own connection held below super user uses mutual TLS with a certificate whose principal has Kpow’s minimum ACLs.
Signing people in. Engineers sign in to Kpow through any standard OpenID Connect provider, Okta, GitHub, SAML or LDAP, so access follows the company directory rather than everyone sharing the Vault credential.
Managing topics and ACLs. Kpow creates and configures topics from its UI, the job the OCI Console leaves to the Kafka CLI. It creates, clones and deletes Kafka ACLs by principal, topic or consumer group, and records each ACL action in its audit log, so moving a cluster to allow.everyone.if.no.acl.found=false before the public connectivity add-on is done from one screen. Cloning one application principal’s ACLs is the quick way to set up the next.
Connecting the team’s own Connect and registry. Kafka Connect clusters and schema registries run on OCI Compute or OKE are added with CONNECT_REST_URL and SCHEMA_REGISTRY_URL. Kpow then shows connector and task state beside the topics they read and write, restarts tasks, and manages registry subjects, versions and compatibility settings.
Reading records. Data inspect shows Avro, JSON Schema and Protobuf records decoded against the team’s registry, and engineers filter them across topics with kJQ, in place of an SSH session to a Compute instance.
Watching lag beside OCI Monitoring. Kpow shows each consumer group down to partition level and resets, clears or skips offsets from the same view. It computes group lag from the Kafka API and exports it with its other computed metrics to Prometheus, the consumer view OCI Monitoring does not carry, while broker CPU, memory and disk alarms stay in OCI Monitoring.
Giving teams their own view of a shared cluster. Tenants limit which topics, groups and connectors each role can see, RBAC sets what each person may do, staged mutations hold an offset reset or topic deletion for approval, temporary policies grant production access that expires at a set time, and data policies mask sensitive fields in data inspect results on the server.
Keeping the record. The audit log records each action with the user from the identity provider, and a webhook sends those records to Slack, Microsoft Teams or any HTTP endpoint. The audit log is a topic on the team’s own OCI cluster. OCI Audit shows who changed the cluster resource; Kpow’s audit log shows which engineer did what inside it.
The public Kpow demo runs on two Amazon MSK clusters, not on Oracle Cloud, and needs no signup. It shows the same brokers, topics, consumer groups, ACLs, data inspect, Kafka Connect and schema registry views; OCI sign-in, masking and temporary policies are the things to test in your own tenancy. The audit log is the __oprtr_audit_log topic on MSK Secondary, the cluster the demo opens on.
Kpow live demo
See the Kpow views an Oracle Cloud team works in
The live Kpow demo runs on two Amazon MSK clusters rather than on Oracle Cloud, and needs no signup. It shows the same views a team gets on an OCI cluster: brokers, topics, consumer groups, ACLs, data inspect with kJQ, Kafka Connect, schema registries and the audit log topic.
For platform teams choosing a Kafka tool for OCI Streaming with Apache Kafka.
Try the Kpow demoFAQ
What is the best Kafka UI for OCI Streaming with Apache Kafka?
On this page’s rubric, Kpow, with 86 of 100 points: it connects over SCRAM-SHA-512 or mutual TLS in its standard image, manages topics, ACLs and the team’s own Kafka Connect clusters and schema registries, adds per-person roles, masking, approvals and an audit trail on top of the super user credential, and runs as one container in your VCN outside the data path. Kafbat UI is the highest-scoring open-source option, at 69, and AKHQ scores 65.
Does Kpow support OCI Streaming with Apache Kafka?
Yes. Kpow’s OCI provider documentation gives SASL/SCRAM-SHA-512 settings with the credentials from OCI Vault and mutual TLS settings, both marked available in Community Edition, and Kafka ACLs are fully supported. The guide Integrate Kpow with OCI Streaming for Kafka runs the standard Docker image.
Does OCI Streaming with Apache Kafka have a UI for topics and messages?
No. Oracle’s FAQ says the service does not provide a native UI for cluster administration, that topic configuration is managed with the Kafka CLI, SDKs or Kafka APIs, and that teams can deploy third-party tools such as Kafbat and AKHQ within OCI. The OCI Console manages the cluster resource: brokers, shapes, storage, configuration and authentication.
Is OCI Streaming the same as OCI Streaming with Apache Kafka?
No. OCI Streaming is Oracle’s serverless streaming service, which accepts most Kafka APIs through a compatibility layer and authenticates Kafka clients with SASL/PLAIN, using a username built from the tenancy, user and stream pool and an OCI auth token as the password. OCI Streaming with Apache Kafka runs dedicated Apache Kafka clusters in your tenancy. Kpow supports both, and on the serverless service it runs with restricted capability and persistence mode set to none, because that service does not implement the complete Kafka API.
Which credentials does a Kafka UI use on OCI Streaming with Apache Kafka?
For SASL/SCRAM, the username and password in the OCI Vault secret applied to the cluster, which Oracle describes as the super user credentials and which are separate from Oracle Cloud console logins. For mutual TLS, a client certificate signed by a CA the cluster trusts, whose principal is authorised by Kafka ACLs. The certificate route is the one that lets a tool’s own connection be limited by ACLs.
Does OCI Audit show which engineer read a Kafka topic?
No. The OCI Audit service records calls to OCI’s public APIs, such as creating or updating a cluster, and Oracle’s logging page for the service states that broker logs are not available. Reads, offset resets and produced messages over the Kafka protocol are recorded only by the tool they are made through. Kpow’s audit log captures the actions users take in Kpow, with the user from the identity provider.
Does OCI Streaming with Apache Kafka support LDAP or OAuth for Kafka clients?
Not today. Oracle’s FAQ says the service supports SASL/SCRAM and mutual TLS, that LDAP and Kerberos are not supported, and that OCI Identity and Access Management for clients is planned; the feature limits list OAuth as not supported. Engineers sign in to a tool such as Kpow with SAML, OpenID Connect or LDAP, and the tool connects to the brokers with SCRAM or a certificate.
Is there a managed Kafka Connect or schema registry on OCI?
Not yet. Oracle’s FAQ says a managed Kafka Connect service and a fully managed schema registry are planned, and that teams run Kafka Connect on OCI Compute and integrate open-source registries meanwhile. Kpow manages those self-run Kafka Connect clusters and schema registries. The Connect monitoring options are compared in Kafka Connect monitoring tools.
How do teams monitor consumer lag on OCI Streaming with Apache Kafka?
With a client-side tool. The oci_kafka metrics in OCI Monitoring are per broker and include no consumer lag, and Oracle recommends monitoring client metrics on your own dashboards. Kpow shows each consumer group down to partition level and exports group lag to Prometheus. Other options are compared in Kafka consumer lag monitoring tools.
Is there a free Kafka UI for OCI Streaming with Apache Kafka?
Kafbat UI and AKHQ are open source, and Oracle’s FAQ names both. Kpow’s OCI documentation carries the Community badge, and Kpow Community Edition is free on up to 3 clusters and 10 users; RBAC, masking, staged approvals and the audit log need Kpow Enterprise. More free options are compared in the best free Kafka UI tools.
Does a Kafka UI need to sit in the data path to govern access on OCI?
No. Kpow runs as one container in your VCN, connects like any Kafka client and applies roles, masking, approvals and the audit trail to the people working through it, so producers and consumers keep connecting straight to the brokers. Conduktor Console also connects directly, while Conduktor’s data-level controls run in Gateway, a Kafka proxy that client applications connect through.
Can an AI agent work with OCI Streaming with Apache Kafka through Kpow?
Yes, through the Kpow API. Factor House’s fh CLI, in beta, calls the same REST API as the Kpow web UI and signs in the way the Kpow deployment does, and its Agent Skills let a coding agent answer questions such as which consumers are behind through Kpow, under the same roles as the person using it. Nothing about them is specific to a provider, so they work on OCI wherever Kpow is connected and its API is enabled. The options are compared in the best Kafka MCP servers.
How these tools were scored
Three of the six criteria start from Oracle’s documentation for OCI Streaming with Apache Kafka; the other three are where the tool runs, whether it manages clusters elsewhere too, and reading records. 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.
1. Governance beyond Kafka ACLs (counts three times). Kafka ACLs decide what a principal may do and OCI IAM policies decide who may manage the cluster resource, but the documented SASL/SCRAM credential is the cluster’s super user, the brokers accept no directory identity, and nothing in OCI records which engineer read which message. This criterion scores per-person roles, production access granted on request and expiring, masking, directory sign-in, tenants for teams sharing a cluster, and an audit trail that names the person. Third-party tools keep their scores from the Amazon MSK page, because the evidence is each tool’s own feature set rather than the cloud. The OCI Console scores 3, as the Amazon MSK console and the Instaclustr console do, because it governs the cluster resource through IAM policies and OCI Audit and adds nothing inside the cluster. The requirements for regulated teams are covered in Kafka governance tools for financial services, and the masking options are compared in Kafka data masking tools.
2. Out of the data path (counts twice). The tool should run inside your OCI tenancy and VCN, reach the brokers over the same private network your applications use as an ordinary Kafka client, 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 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 a component on the brokers 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, here the OCI Console. This criterion is scored the same way on every Factor House page that uses it, and only its weight changes with the reader.
3. Connect and registries you run (counts twice). Oracle offers no managed Kafka Connect or schema registry yet, so a team on OCI runs open-source ones, and the tool is their console. Scores match the Connect and registry evidence on the self-managed Apache Kafka page, where the same components are run by the team; the OCI Console scores 1 because it has nothing for either.
4. SCRAM and mTLS sign-in (counts once). Oracle documents SASL/SCRAM-SHA-512 with credentials in OCI Vault and mutual TLS. A tool scores 8 when its vendor documents OCI settings for both, 7 when SCRAM-SHA-512 and SSL work through documented generic settings and Oracle names the tool among those a team can deploy in OCI, and 6 when the settings are generic and neither the vendor nor Oracle says anything about OCI. The OCI Console scores 7: it is where the Vault secret and the CA bundle are attached, although it covers the one super user credential and is not a Kafka client.
5. On-prem and cloud together (counts once). Many teams on OCI also run Kafka on-prem or on another cloud, reached over FastConnect, a VPN or the public connectivity add-on. This scores whether one deployment manages all of those clusters with the same controls. Scores match the banking page, with Redpanda Console’s taken from the multi-cluster comparison; the OCI Console shows OCI clusters only.
6. Inspecting topic data (counts once). The OCI Console shows no topics or records. Reading a message, searching a topic for one key or replaying a record after an incident is the day-to-day job engineers need a tool for. Scores match the Amazon MSK page.
Costs are modelled for one production cluster 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. The OCI Console has no licence and nothing to run, and the Kafka command-line tools it leaves topics, ACLs and record reading to are modelled like the other tools with no access control of their own, at 8 hours a month, $11,520 a year. Kpow’s $7,380 uses its price of $4,500 per cluster a year with 100 users included. Kpow Community Edition is free for 3 clusters and 10 users, so a 25-engineer team is on Enterprise. The service’s own charges, the infrastructure plus Oracle’s service fee per OCPU hour listed on its price list, are the same whichever tool a team chooses, so they are left out.
The criteria map onto the OCI features 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: Governance beyond Kafka ACLs counts three times, Out of the data path counts twice, Connect and registries you run counts twice, SCRAM and mTLS sign-in counts once, On-prem and cloud together counts once and Inspecting topic data counts once, for a total out of 100. Governance beyond Kafka ACLs counts three times because on OCI the documented SASL/SCRAM credential is the cluster's super user and the brokers know nothing of a company directory, so for work done through a shared tool, per-person roles, production access granted on request, masking, directory sign-in, tenants for shared clusters and a per-person audit trail in the tool are the only record of which engineer did what. Out of the data path and Connect and registries you run count twice: a tool that clients connect through becomes part of the path every producer and consumer depends on, and because Oracle offers no managed Kafka Connect or schema registry yet, the team's own Connect clusters and registries have no other console. SCRAM and mTLS sign-in, on-prem and cloud together, and inspecting topic data 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 86 out of 100. The other options follow by total. Conduktor is listed last whatever its total; on its total of 67 it would place third.
Related reading
- Kafka: the complete guide
- Kafka-compatible cloud brokers
- Integrate Kpow with OCI Streaming for Kafka
- Best Kafka UI tools for Amazon MSK
- Best Kafka UI tools for Google Cloud Managed Service for Apache Kafka
- Best Kafka UI tools for Confluent Cloud
- Best Kafka tools for Aiven for Apache Kafka
- Best Kafka tools for NetApp Instaclustr managed Kafka
- Best Kafka tools for self-managed Apache Kafka
- Best Kafka UI tools for Strimzi
- Best Kafka UI tools for Redpanda
- Best Kafka UI tools for WarpStream
- Best Kafka UI tools for StreamNative Cloud
- Best Kafka UI tools for Bufstream
- Best Kafka management tools for Confluent Platform
- Best Kafka management tools for banks
- Best Kafka governance tools for financial services
- Kafka multi-cluster management tools
- Best Kafka management tools