Zilla Kafka Gateway
Universal Kafka access, governed at the edge.
Zilla Kafka Gateway puts a secure, stateless edge in front of Kafka. Proxy native Kafka clients, connect the clients that don't speak Kafka, and enforce identity, schema, policy, and audit controls without changing your applications or your clusters.

The Problem
Kafka was built for systems, not for governed access at scale.
The wrapper farm
Exposing Kafka to apps, partners, devices, and agents means wrapper services, until the wrapper layer becomes the product.
Custom code
Duplicated logic
Ops overhead
Uneven governance
The governance gap
Isolation, identity, and edge enforcement aren't built in. You build them yourself or go without.
Tenant isolation
Identity end-to-end
Schema at the edge
Per-tenant quotas
Field-level privacy
Audit trails

The Solution
One stateless data plane. Declarative. In your perimeter.
Zilla Kafka Gateway sits at the edge of your Kafka cluster as a stateless container, Kubernetes pod, or AWS AMI. One zilla.yaml defines every protocol, route, identity, schema, and policy.
No database. No persistent state. No coordination between instances.
Stateless by design
Scale horizontally. Restart safely. Run multiple instances with no shared state and no coordination layer between them.
no database
no persistence
Declarative configuration
Kafka access, protocol mediation, schemas, and policies live in one config file. Reload changes without rewriting applications.
zilla.yaml
In your perimeter
Data, credentials, keys, and Kafka traffic stay inside your network. Zilla governs access without moving data into an external platform.
vpc
on-prem
air-gapped


Kafka-native proxying
Proxy Kafka traffic without changing clients.
Zilla is a transparent proxy for Kafka producers, consumers, and Kafka Connect. Clients connect exactly as they would to a broker — only bootstrap.servers changes.
The Kafka protocol stays intact end to end, including produce, fetch, consumer groups, transactions, idempotent producers, and Kafka Connect.
Kafka wire-protocol passthrough
Standard Kafka clients in Java, Go, Python, .NET, Node, and other languages connect without SDKs, drivers, or rewrites.
only bootstrap.servers changes
Identity at the wire
Authenticate Kafka clients with SASL, SCRAM, mTLS, or AWS IAM, then enforce access at the gateway.
sasl
scram
mtls
aws iam
Policy on the passthrough path
Apply configuration rules, schema validation, and data privacy controls before Kafka traffic reaches the cluster.
config
schema
privacy
Data masking and encryption
Encrypt sensitive and PII fields at the gateway before they reach Kafka, then decrypt, redact, or omit them per consumer authorization on read — including fields already stored in the clear.
encrypt on write · redact on read
Virtual Clusters
Segment one physical Kafka cluster into isolated logical clusters for teams, tenants, partners, or environments.
one cluster → many tenants
Dynamic topic aliases
Every client addresses the same topic name; the gateway rewrites it to that client's own internal topic from the authenticated identity — no per-client config.
messages → messages-${identity}
Performance
Close to Kafka's native ceiling.



Baseline Controls at the Edge
Identity, schema, and telemetry before traffic reaches Kafka.
The controls enterprises expect at a boundary, applied on the traffic path, not bolted on behind it.
Identity for every client
Authenticate non-Kafka clients with JWT, Azure AD, or AWS Lambda authorizers.
Authenticate Kafka-native clients with SASL, SCRAM, mTLS, or AWS IAM.
Use identity to authorize routes, topics, tools, tenants, and access patterns.
jwt
azure ad
sasl
mtls
Schema enforcement
Validate messages against the registry you already run, and reject invalid data at the edge before it reaches Kafka.
Registries: Confluent Schema Registry, Karapace, Apicurio, AWS Glue, and inline filesystem schemas.
Formats: Avro, JSON Schema, Protobuf, and scalar types.
avro
json schema
protobuf
Telemetry
Export Kafka-aware metrics and structured events to Prometheus, OpenTelemetry, stdout, CloudWatch, and Syslog.
Track request duration, response codes, produce and fetch volume, topic access, client identity, and quota violations.
No log spelunking to answer who read what, and when.
prometheus
otlp
cloudwatch

Governance
Data quality and governance, enforced where the traffic flows.
Define policy centrally. Enforce it at the gateway. Keep Kafka ACLs and quotas in place and add the controls Kafka cannot provide on its own.
Configuration policy enforcement
Apply guardrails to Kafka nouns: topics, clusters, producers, and consumers. Enforce naming rules, retention boundaries, deprecated API restrictions, client-version requirements, record-size limits, poll-rate limits, and lag protection.
guardrails on kafka nouns
Field-level encryption and crypto-shredding
Encrypt fields before they reach Kafka; decrypt, redact, or omit them on read by the consumer's authorization. Keys stay in your KMS — destroy a per-user KEK for GDPR erasure.
registryless kek
registry-backed
Streaming schema validation
Validate JSON, Avro, and Protobuf messages at near line rate before they reach Kafka. Reject bad data at the edge, not downstream.
near line rate


Multi-Protocol Mediation
Connect every client that does not speak Kafka.
Kafka data needs to reach more than Kafka clients. Browsers, mobile apps, IoT devices, partner systems, internal services, and AI agents all need governed access to live data.
Zilla maps these protocols to Kafka at the edge in the same runtime, with the same configuration, identity, schema, telemetry, and policy controls.
Spec-driven configuration
Zilla treats API specifications as configuration, not code generation.
OpenAPI
AsyncAPI
Define channels, operations, messages, and protocol mappings.
OpenAPI → AsyncAPI proxy
Create HTTP request-response surfaces backed by Kafka.
Protobuf
Use .proto definitions for gRPC and Kafka message contracts.




Ready to get started?
Get started on your own, or request a demo with one of our real-time data experts.
Explore pricing
Straightforward, usage-based pricing with no per-connection surprises — start free and scale when you are ready.
Join the Community
Trade notes with the engineers running Zilla in production, and get help from the team in Slack or Discord.

Frequently asked questions
Most products in the category do one of two things: they proxy Kafka-native traffic, or they bridge a single non-Kafka protocol. Few govern, and fewer still do both. The Zilla Kafka Gateway does all three. The same stateless binary that proxies Kafka-native traffic with Virtual Cluster isolation, identity at the wire, and configuration-policy enforcement also mediates HTTP, SSE, WebSocket, gRPC, MQTT, and MCP clients — including AI agents — into the same cluster, under the same governance.
Any Kafka-compatible cluster: Apache Kafka, Amazon MSK (provisioned and serverless), Confluent, Aiven, Redpanda, and Cloudera. Schema registries: Confluent Schema Registry, Karapace, Apicurio, AWS Glue Schema Registry, and inline filesystem schemas. Formats: Avro, JSON Schema, Protobuf, and scalar types.
Zilla is made available under the Aklivity Community License. This is an open source-derived license that gives you the freedom to deploy, modify and run Zilla as you see fit, as long as you are not turning into a standalone commercialized “Zilla-as-a-service” offering. Running Zilla in the cloud for your own workloads, production or not, is completely fine.
Community covers protocol mediation, schema validation, identity guards, and telemetry — everything needed to connect non-Kafka clients to Kafka. Plus adds Kafka-native proxying with Virtual Clusters, custom domains, identity at the wire, configuration policy enforcement, field-level encryption and crypto-shredding, and support. Enterprise adds the management control plane, multi-cluster and multi-environment governance, and enterprise support terms.
No. Kafka-native clients change bootstrap.servers and nothing else — no SDK, driver, or rewrite. Non-Kafka clients speak their own protocol to the gateway. Kafka itself is untouched: existing ACLs, quotas, and topics keep working, and the gateway adds the controls Kafka cannot enforce on its own.
t replaces the wrapper layer: bespoke bridge services, per-protocol adapters, edge auth glue, and the ad-hoc scripts that expose Kafka to partners. It complements what you already run — Kafka ACLs and quotas, your schema registry, your identity provider, your KMS, and your observability stack all stay in place and are enforced on the traffic path.
Anywhere the Zilla runtime runs: a container, a Kubernetes pod, an AWS AMI, or a systemd service — in your VPC, on-prem, or air-gapped. The data plane is stateless and holds no data at rest. Payloads, credentials, and keys never leave your perimeter.












