Get more teams building on IBM Confluent
Conduktor adds a developer UI, self-service with policies the platform team sets, and encryption in a Kafka proxy to IBM Confluent and IBM Event Streams.
Trusted by platform teams at
Streaming spreads when every team can build on it.
IBM Confluent gives you a solid streaming platform. What decides how far it spreads across your IBM Kafka estate, IBM Confluent or Event Streams, is how quickly a new team gets productive. With Conduktor, the first team's templates, policies, and topic catalog are already in place for the second, and every team after that starts further ahead.
How Conduktor fits with IBM Kafka
Your teams work through Console. Your applications reach IBM Confluent through Gateway. No broker plugins on your IBM clusters.
What faster adoption looks like
Results from Conduktor customers across Kafka platforms.
Down from three weeks: a Fortune 500 retailer now puts a new team on Kafka in an hour.
CDC Informatique went from 40 to 160 Kafka applications in three years, with a five-person platform team.
Swiss Post grew Kafka usage fivefold, with 800+ users under RBAC.
Browse, produce, and replay messages, and check consumer lag, within each developer's permissions.
Teams create topics and request access through templates and policies you define.
Field-level and full-payload encryption, masking, and data quality rules, applied in the Kafka proxy.
Read-only access to clusters, topics, and consumer groups, limited to each user's permissions.
Per-subject read and write permissions in front of IBM Confluent Schema Registry.
Switch the backing cluster in Gateway instead of changing every client's bootstrap servers.
Isolated namespaces for teams or partners on one physical cluster, with no extra Kafka cluster to run.
Developers get productive on Kafka fastest when they can see what's happening. Conduktor Console gives them that view:
- Browse, filter, and live-tail messages, with Avro, Protobuf, and JSON decoded
- Produce test messages without deploying anything
- Check consumer lag, inspect consumer groups, and reset offsets
- Reprocess messages when something went wrong downstream
- Restart, pause, or rewind the connectors that feed Kafka, such as the ones bridging IBM MQ
- Get lag alerts in Slack or Teams, and Insights scoped to the topics their team owns
- Browse schemas and their versions
Each developer sees what their role allows, and sensitive fields can stay masked in the UI.
Topic templates pre-fill the settings you've approved, policies reject anything outside them, and approvals can go through a pull request when a second pair of eyes is required.
- Application and topic catalogs that map every resource to an accountable team
- Granular RBAC: compose permissions per resource and operation, scoped by name, prefix, or wildcard, for team groups synced from your IdP
- Delegation: each team manages its own members and approves access requests to the topics it owns
- On IBM Confluent, access is granted as Confluent RBAC role bindings, so it lands in the security model you already run
- Lineage that shows who produces and consumes every topic, with every change in the audit log
- Chargeback that attributes Kafka costs to each team, from the rates you set
- The same rules in Git, through the Terraform provider, CLI, or API
Regulated data often stays off Kafka because no one can prove who reads what. Conduktor Gateway is a Kafka proxy between your applications and your brokers:
- Full-payload encryption for structured and unstructured records
- Field-level encryption on Avro, Protobuf, and JSON
- Master keys stay in your KMS (AWS, Azure, GCP, HashiCorp Vault, or Fortanix); Gateway caches data keys in memory
- Per-reader decryption: one team reads the field, another sees it masked
- Data quality rules that reject or flag records breaking the contract, before consumers read them
- No changes to producer or consumer code
Gateway enforces what passes through it. The guarantee holds when your network only lets clients reach the brokers through Gateway. See Kafka encryption for the full model.
Console hosts an MCP server, in preview. An assistant connects with a personal access token and gets read-only access to clusters, topics, consumer groups, schemas, and Insights, limited to what that user is allowed to see.
It's a remote MCP server with token authentication, the kind IBM Bob and watsonx Orchestrate both connect to. For agents that do the work, open-source Conduktor Skills teach them to drive the CLI and write self-service YAML that passes your policies.
Schemas are the contract between teams, and most registries let anyone with access change any subject. The Schema Registry Proxy, in early access, sits in front of a Confluent-compatible registry such as IBM Confluent Schema Registry:
- Per-subject read and write permissions, from Console or your existing Kafka ACLs
- An audit log of every schema change
- No client code changes
Talk to us to validate your registry and deployment.
IBM has deprecated Event Streams and delivers new streaming work through IBM Confluent. Moving across usually means changing bootstrap.servers in every application and coordinating every team.
With Gateway in front:
- Applications keep one bootstrap address while the backing cluster changes
- Switch the backing cluster at the proxy, and switch back if needed
Gateway routes traffic; it doesn't copy data. Replication between clusters stays with Cluster Linking or MirrorMaker. See Kafka migration.
Each virtual cluster gets its own service accounts, ACLs, topics, and consumer groups. Teams see only their own namespace. Partners get a scoped endpoint without seeing your internal topics.
New use cases land on the clusters you already run, with isolation the security team can check.
What IBM Confluent covers, and what Conduktor adds
IBM Confluent runs the platform. Conduktor covers what teams would otherwise build or do by hand around it.
| IBM Confluent gives you | Conduktor adds | |
|---|---|---|
| Access | RBAC with predefined roles, and Control Center for operators | Granular RBAC you compose: pick the operations per resource, scope them by name, prefix, or wildcard, and assign them to team groups from your IdP. Teams manage their own members and approve access to what they own, and Conduktor provisions the matching DeveloperRead and DeveloperWrite role bindings |
| Encryption | Client-side field encryption, configured through Schema Registry data contracts in each client | Encryption at the proxy, with or without a schema, and no client library changes |
| Cluster moves | Cluster Linking to replicate data between clusters | Cluster switching at the proxy, so applications don't redeploy when the cluster changes |
restricted-v2 security context, and both work without internet access. For the full comparison, see Confluent + Conduktor. Read more customer stories
How does Conduktor speed up IBM Confluent adoption?
Developers browse, test, and debug in Console without help from the platform team. Self-service gives them topics and access as soon as a request fits your policies. Gateway encrypts and masks on the Kafka protocol, so data that security kept off the platform can move onto it.
What is IBM Confluent?
IBM Confluent is the Confluent data streaming platform, built on Apache Kafka, which IBM acquired in March 2026. It is sold as IBM Confluent Cloud and IBM Confluent Platform, and IBM now delivers its new streaming work through it rather than Event Streams.
Does Conduktor work with IBM Confluent?
Yes. IBM Confluent Cloud and IBM Confluent Platform are Confluent Cloud and Confluent Platform. Conduktor connects over the standard Kafka protocol, works with Confluent Schema Registry, and can manage access as Confluent RBAC role bindings.
Can we run Kafka tooling on Red Hat OpenShift?
Yes. Console and Gateway deploy with Helm and run under OpenShift's default restricted-v2 security context constraint, without a custom SCC. Both run without internet access: the license is checked locally and images can come from your private registry.
We're early with streaming on IBM. Is Conduktor too soon?
Developers get value from the first topic: seeing and debugging data is where new teams lose the most time. Setting ownership and naming rules before the tenth team arrives also costs less than cleaning up after the fiftieth. The free Community Edition covers 50 users and 3 clusters.
Can our developers use AI assistants with Kafka?
Yes, with governance. Console's MCP server, in preview, gives assistants read-only access limited to each user's permissions. Any MCP client that supports remote servers with token authentication can connect, including IBM Bob and watsonx Orchestrate.
Can Conduktor manage IBM MQ connectors?
Yes. Console manages Kafka Connect connectors whatever their type, including IBM MQ source and sink connectors: check status, restart, pause, and manage offsets. These permissions can be delegated to the team that owns each connector.
Does Conduktor work with IBM Event Streams?
Event Streams exposes the Kafka APIs, so Console and Gateway connect to it as a Kafka cluster. On IBM Cloud, clients authenticate with SASL over TLS using an IBM Cloud API key, and must send SNI. On the self-managed edition, SCRAM-SHA-512, mutual TLS, and OAuth are available. We validate your edition, authentication, networking, and the features you need during the evaluation; schema registry compatibility is checked separately.
Can Conduktor help migrate from Event Streams to IBM Confluent?
Yes. Console inventories topics and consumer groups on both clusters, and Insights flags what is better retired than migrated. Gateway lets applications keep one bootstrap address, then switches the backing cluster at the proxy, with a way back. Data replication itself runs on MirrorMaker or Cluster Linking.
Does Gateway add a component to operate?
Yes. Gateway sits in the data path, so you run it with the same care as your brokers: at least three stateless instances behind your load balancing. In exchange you get one place to enforce encryption, policies, and routing, instead of logic spread across every application.
Which key management systems does Gateway encryption support?
AWS KMS, Azure Key Vault, Google Cloud KMS, HashiCorp Vault, and Fortanix. Master keys never leave your KMS.
Can we control access to schemas too?
Yes. The Schema Registry Proxy, in early access, adds per-subject read and write permissions in front of a Confluent-compatible registry such as IBM Confluent Schema Registry, with an audit log of every schema change.
How does Conduktor relate to IBM Event Endpoint Management?
Event Endpoint Management publishes Kafka topics in a catalog and controls access to them through its Event Gateway. Conduktor covers the developer experience and self-service in Console, and field-level encryption, virtual clusters, and failover in Gateway, across every Kafka platform you connect.
Do I need to change my IBM Confluent setup?
No broker plugins. Conduktor needs credentials and permissions on each cluster, Gateway provisions its own internal topics, and applications are pointed at Gateway when you want enforcement.
Running Kafka on IBM?
Tell us how many teams you want on IBM Confluent next year. We'll show you what onboarding them looks like with Conduktor.