Conduktor Gateway vs Confluent Private Cloud Gateway
Confluent's gateway moves clients between clusters. Conduktor Gateway governs traffic on any Kafka: isolation, encryption, data quality, and registry access, configured at runtime without a restart. Same position in the architecture, different reasons to deploy it.
What Confluent built, and why
Confluent Private Cloud Gateway is a routing proxy for migration, disaster recovery, and blue-green upgrades. Switching clusters means editing a route and restarting the gateway, and Confluent's own docs say the switch breaks message ordering. It ships with a Confluent Private Cloud license.
Release 1.3.0 added gateway-side encryption and schema validation, in Early Access and Docker-only, with configuration Confluent says may change before GA. It's a signal of direction; the GA version will be the one to evaluate.
Since IBM closed the Confluent acquisition in March 2026, platform teams are also asking how much of their control layer should depend on one vendor's roadmap. Gateway fronts Confluent alongside every other Kafka you run, with one policy model.
Competitor details last checked against Confluent Private Cloud Gateway documentation and release notes, September 2026.
Where Conduktor Gateway and Confluent Gateway diverge
Four questions that decide the evaluation.
Tenants, not just routes
Virtual clusters with their own namespaces, credentials, quotas, and policies on shared brokers. Confluent isolates by custom domain and quota; no virtual clusters.
Enforcement that's shipping
Field-level encryption, masking, tokenization, and data quality rules, GA and in production. Confluent's gateway encryption is Early Access, Docker-only.
The registry, governed too
Schema Registry Proxy adds OIDC authentication and per-subject authorization to any registry. Confluent's gateway doesn't proxy the registry; subject-level RBAC there is a Confluent Platform enterprise plugin.
Any Kafka, one policy set
Confluent, MSK, Redpanda, Aiven, Apache Kafka. Confluent's gateway is licensed through Confluent Private Cloud.
Conduktor Gateway vs Confluent Private Cloud Gateway: feature comparison
Conduktor Gateway is licensed per cluster on the Enterprise plan; the free Community Edition covers cross-network reachability only.
| Capability | Conduktor Gateway | Confluent Private Cloud Gateway |
|---|---|---|
| License & cost | ⚠Commercial, per cluster with a 3-cluster minimum; free Community Edition for network reachability only. See pricing → | ⚠Trial mode by default; Enterprise mode requires a Confluent Private Cloud license |
| Kafka providers | ✓Any Kafka 2.7+: Confluent Platform and Cloud, MSK, Redpanda, Aiven, Apache Kafka | ⚠Kafka protocol 3.x and 4.x upstream clusters; sold and supported as part of Confluent Private Cloud |
| Maturity | ✓GA, released alongside Console; in production at regulated enterprises such as CDC Informatique | ⚠1.0 shipped 2025; 1.3.0 is current |
| Cluster switching | ✓One API call, no restart, no client changes; chaos-testing interceptors to rehearse | ⚠Edit the route configuration and restart the gateway; clients reconnect. Confluent notes the switch breaks ordering and consistency |
| Replication | ✗Routes, doesn't replicate; pair with MirrorMaker 2, Replicator, or Cluster Linking | ✗Same; pairs with Cluster Linking or Replicator |
| Automatic failover | ⚠Triggered by API call, not health check; all-or-nothing today | ⚠Triggered by a configuration change and restart; consumer groups rebalance if it exceeds 45 seconds |
| Migration to Confluent Cloud | ⚠Supported as a cluster switch like any other, no restart | ✓Purpose-built path with credential swapping and Confluent tooling; each switch is a gateway restart |
| Multi-tenancy | ✓Virtual clusters with isolated namespaces, ACLs, quotas, and policies; topic concentration | ⚠Custom domains and client quotas; no virtual clusters |
| Encryption | ✓Field-level and full-payload encryption with KMS integration, plus masking and tokenization, GA | ⚠Field-level and full-payload encryption in Early Access (1.3.0), Docker-only; CSFLE for Confluent Cloud is client-side |
| Data quality | ✓Schema enforcement plus CEL business rules on the wire; violations blocked or logged per policy | ⚠Schema ID enforcement and deep validation in Early Access; Stream Governance rules are client-side |
| Schema Registry governance | ✓Schema Registry Proxy: OIDC authentication, per-subject authorization, audit, for any registry | ⚠Not proxied by the gateway; Confluent Platform's security plugin provides subject-level RBAC and ACLs for Confluent Schema Registry |
| Best-practice guardrails | ✓Topic policies, producer and consumer safeguards, rate limits, large-message handling, per virtual cluster | ⚠Authentication swapping, fencing filter, routing; quotas via Kafka |
| Partner data sharing | ✓Partner Zones: isolated virtual clusters with per-partner masking, credentials, and rate limits | ⚠Dedicated partner endpoints with authentication; no per-partner masking |
| Authentication | ✓mTLS, SASL, OIDC/OAuth; centralized service accounts and audit | ✓mTLS, SASL/PLAIN, SCRAM, OAuth, OIDC; credential swapping with Vault, AWS, Azure secret stores |
| Configuration & change | ✓REST API, CLI, Terraform provider; management UI in Console | ⚠YAML and Confluent for Kubernetes operator; changes, including route switches, apply on restart |
| Observability | ✓Prometheus metrics, audit log, Console UI | ✓Prometheus metrics through the admin endpoint |
IncludedPartial or gated behind a higher tierNot available
Multi-tenancy
Teams share brokers without sharing a blast radius
Virtual clusters give each team its own namespace, credentials, ACLs, quotas, and interceptors on shared infrastructure; topic concentration folds low-volume topics into fewer partitions. Confluent's gateway isolates by custom domain and client quota, which separates traffic but doesn't give tenants their own rules.
Data security
Encryption that covers every client, in production today
Field-level encryption, masking, and tokenization run as Gateway interceptors with keys in your KMS, so every producer and consumer is covered without a library. Confluent's CSFLE is client-side, which any team can skip; its gateway-side encryption is Early Access and Docker-only as of 1.3.0.
Schema Registry governance
The registry gets the same treatment as the brokers
Schema Registry Proxy sits in front of the registry you already run and adds OIDC authentication, per-subject authorization, and an audit trail, managed from Console or reusing your Kafka ACLs. Confluent Platform can do subject-level RBAC on its own registry through an enterprise plugin; its gateway proxies Kafka traffic only, and neither covers a Glue, Karapace, or Redpanda registry.
Confluent Gateway fits if...
You are all-in on Confluent Private Cloud, your proxy requirements are a one-time migration to Confluent Cloud or blue-green upgrades where a restart is acceptable, and you're comfortable waiting for the governance features to reach GA inside Confluent's packaging.
Conduktor Gateway fits if...
You need multi-tenancy, encryption, masking, or data quality on the wire now; you run Confluent alongside other Kafka providers or want the option to; you want the Schema Registry governed as well; or you'd rather your governance layer not be tied to one vendor's licensing.
"Confluent Cloud without governance on top is unusable for our enterprise. I will never let a user touch the portal directly. Everyone goes through Conduktor."
IT Project Lead
Leading German Automotive Manufacturer
"I don't want to commit to any Kafka provider. Conduktor gives me that flexibility."
IT Project Lead
Leading German Automotive Manufacturer
Read more customer stories
Does Conduktor Gateway work with Confluent Platform and Confluent Cloud?
Yes. Gateway sits in front of Confluent brokers like any other Kafka, and Schema Registry Proxy fronts Confluent Schema Registry. Several customers run Gateway in front of Confluent Cloud specifically so developers never touch the Confluent portal directly.
Can Conduktor Gateway migrate us to Confluent Cloud?
Yes, as a cluster switch: clients keep one bootstrap address while Gateway redirects them without a restart, and you can rehearse the cutover with chaos testing. Confluent's gateway has a more packaged migration path with credential swapping and Confluent tooling, at the cost of a gateway restart per switch. If migration to Confluent Cloud is the only requirement, both do it; Gateway is the choice when the same layer also needs to govern.
Is Confluent's gateway encryption the same as Conduktor's?
Not today. Confluent's gateway-side field-level and payload encryption arrived in release 1.3.0 as Early Access, limited to Docker deployments, with configuration that may change before GA. Confluent's production encryption, CSFLE, is client-side. Conduktor Gateway's field-level encryption, masking, and tokenization are GA on the wire and cover clients that never install a library.
Do either of these replicate data for disaster recovery?
No. Both are proxies that switch client traffic; replication is Cluster Linking, Replicator, or MirrorMaker 2, and both vendors document that a switch can abort in-flight transactions. Conduktor adds chaos-testing interceptors so you can prove applications survive the switch before you need it.
What about the IBM acquisition?
IBM completed the acquisition in March 2026. Roadmaps and pricing are IBM's to announce. The practical effect has been platform teams checking how much of their control layer depends on a single vendor; Gateway is provider-neutral by design, so it can be adopted without changing where your brokers run.
Can we run Conduktor Gateway and Confluent's gateway together?
Technically yes, since both are transparent proxies, but most teams pick one layer in the data path. The usual split is Confluent's gateway for a one-time migration and Conduktor Gateway as the permanent governance layer.
See Gateway in front of your Confluent clusters
Thirty minutes: virtual clusters, encryption on the wire, and Schema Registry governance, with no client changes.