Conduktor Passthrough Gateway
Reach Kafka across networks.
A Kafka proxy that translates broker addresses across networks, without changing the brokers, the credentials, or the auth model.
Your Kafka cluster lives in a network your clients can't reach.
When a client connects, the broker hands back the addresses of every broker in the cluster, and the client connects to those addresses directly. If your network can't route to them, a standard load balancer doesn't help, and most managed Kafka services don't let you reconfigure what brokers advertise.
When to Use Conduktor Passthrough Gateway
Three patterns where the proxy fits.
Reach Kafka without adding peerings
Every new client VPC would otherwise need its own peering with the cluster. Route them through one proxy in an already-peered VPC. The cluster sees one attachment, no matter how many client networks reach in.
Reach private clusters from outside
In situations where a cluster has no public endpoint, a proxy on the boundary lets external clients, partners, or cross-cloud workloads reach in. No cluster reconfiguration or per-client endpoints.
Single egress point
Each internal client opens its own connection to remote Kafka. One proxy funnels them all. One firewall rule, one TLS termination, and one audit trail.
How It Works
Three steps from unreachable cluster to working client.
Drop in
Update bootstrap.servers to the proxy's address. No client code changes. Existing SASL credentials.
Translate
The proxy rewrites broker addresses in Kafka's metadata responses, so clients see addresses they can actually reach.
Route
Each broker gets its own port on the proxy. Traffic routes deterministically per broker. SASL passes straight through.
# Upstream Kafka (where the brokers actually live)
KAFKA_BOOTSTRAP_SERVERS=kafka1:9092,kafka2:9092,kafka3:9092
KAFKA_SECURITY_PROTOCOL=SASL_SSL
KAFKA_SASL_MECHANISM=PLAIN
KAFKA_SASL_JAAS_CONFIG=<upstream SASL credentials>
# Gateway listener: one port per upstream broker
GATEWAY_LISTENER_NAMES=external
GATEWAY_LISTENER_EXTERNAL_PORTS=6969-6971
GATEWAY_LISTENER_EXTERNAL_ADVERTISED_HOST=gateway.example.com
GATEWAY_LISTENER_EXTERNAL_SECURITY_PROTOCOL=SASL_SSL
# Passthrough mode: client SASL forwards to Kafka
GATEWAY_SECURITY_MODE=KAFKA_MANAGED
GATEWAY_ACL_ENABLED=false
GATEWAY_LICENSE_KEY=<your-passthrough-license>Clients connect with bootstrap.servers=gateway.example.com:6969. Each broker is reachable through its own port on the gateway.
Deploy anywhere
Conduktor Passthrough Gateway is a sibling of Conduktor Gateway, so it deploys the same way. On your Kubernetes, Docker, or cloud. Your data never leaves your environment.
What You Don't Add
The proxy adds reachability. Nothing else.
No broker reconfiguration
Adds new advertised addresses to clusters you can't change. Works with managed Kafka where listener config is locked.
No new credentials
SASL flows straight through. Existing API keys and OAuth tokens authenticate directly against Kafka.
No new auth model
Kafka ACLs and Confluent RBAC remain the source of truth. The proxy doesn't issue or store identities.
Step 1 — Request your license
Free to use. We'll send your license and install instructions by email within 1 business day.
Step 2 — Run the stack
Once your license arrives, paste it into the second command and run these in your terminal.
# Clone the repo
git clone https://github.com/conduktor/passthrough-gateway-quickstart && cd passthrough-gateway-quickstart
# Add your license key (from the email)
echo 'GATEWAY_LICENSE_KEY=<paste-key-from-email>' > .env
# Start the stack
docker compose up -dWhy is Passthrough Gateway free?
We built it because customers kept asking for the reachability piece of Gateway without the full governance stack. Free isn't a trial. There's no time limit, no expiration, and no plan to put it behind a paywall.
What's the difference between Conduktor Passthrough Gateway and Conduktor Gateway?
Conduktor Passthrough Gateway is a license-restricted mode of Conduktor Gateway. It handles broker address translation and passes SASL credentials through to Kafka. Full Conduktor Gateway adds governance, encryption, masking, schema enforcement, virtual clusters, disaster recovery, and partner data sharing. See Gateway →
What features are not included?
A Conduktor Passthrough Gateway license excludes Interceptors, topic views, alias topics, Virtual Clusters, Gateway service accounts, Gateway groups, topic concentration, and failover. These all require a full Conduktor Gateway license.
Does the proxy terminate or store my Kafka credentials?
No. SASL flows straight through to Kafka in KAFKA_MANAGED mode. The broker authenticates the client, and Kafka ACLs or Confluent RBAC enforce authorization.
Which Kafka providers are supported?
Any Kafka 2.5+, including Confluent Cloud, Confluent Platform, AWS MSK, GCP Managed Service for Apache Kafka, Aiven, Redpanda, and self-managed Apache Kafka. SASL_PLAINTEXT and SASL_SSL only.
How does this compare to Grepplabs kafka-proxy, Kroxylicious, or AWS MSK Multi-VPC?
Grepplabs kafka-proxy is an open-source passthrough proxy with similar scope, without commercial support or operational tooling. Kroxylicious is a filter framework with broader scope that requires authoring and operating filters. AWS MSK Multi-VPC Private Connectivity is AWS-only and MSK-only. Conduktor Passthrough Gateway is the right choice when you want a narrow-scope address translator that works across any Kafka, with an upgrade path to full Conduktor Gateway when you need governance, encryption, or schema enforcement.
Does it work across cloud providers?
Yes. Cross-cloud is a common use case. For example, on-prem or AWS clients reaching a Confluent Cloud cluster on GCP.
What level of support does Passthrough Gateway come with?
Same as Community Edition: best-effort email support, plus docs and Slack.
Last updated: May 2026