Zilla Console
Command every Kafka cluster. Govern every access path. Ship data products at scale.
One console for every Kafka cluster you run. Define policy, publish governed API Data Products, and issue identities — enforced in real time at the Zilla Kafka Gateway.
available in
Plus add-on
Bundled in Enterprise
Powering Global Data Driven Organizations
The problem
The hardest part of running Kafka isn’t Kafka.
The gap
Kafka moves the data. It doesn't ship a catalog, a developer portal, credentials, or policy enforcement — so platform teams build it themselves, out of tickets.
The consequence
Every access request lands in your queue. Policy scatters across ACLs, registries, and broker config. As clusters multiply, you're governing Kafka through ten browser tabs.
The resolution
The Zilla Console puts that layer in one place: see every cluster, define policy once, publish topics as governed data products, and push it all to the gateways that enforce it.
Architecture
Three planes. One identity model. No data leaves your network.
The management plane is where you design — APIs, products, policies, access. The control plane makes it real: designs become live gateway configuration. The data plane is where the action happens — the Zilla Kafka Gateway, inside your network, enforcing every decision.
Only governance metadata moves between planes. Your data never does.
Stateless data plane
Configuration is the source of truth. No operational database in the data path; every gateway hydrates independently when it attaches.
Metadata only, one direction
Gateways register outbound over an authenticated channel. Governance metadata flows down; your Kafka traffic never crosses between planes.
Multi-vendor by default
Apache Kafka, MSK, Confluent Cloud, Aiven, Redpanda, Cloudera — one Environment model, one identity model, whoever runs the broker.
The fleet
Every cluster. Every gateway. One console.
Any distribution, one model.
Drill into any cluster. Same console.
Every gateway, dialing home.
How it works
Define policy once. Enforce it where the traffic flows.
You define policy here; the gateway enforces it on every request — including passthrough clients with no subscription. Your ACLs and quotas stay as they are; this governs what they can’t reach.
Step 1
Cluster policies
Global guardrails on cluster behaviour — broker-config allow-lists, client-ID requirements, API version floors, codec allow-lists. Run audit mode to observe violations, then block mode to deny them.
Step 2
Topic policies
Naming conventions, partition and replica bounds, config allow-lists, delete protection — enforced on every create, alter, and delete request that reaches the gateway.
Step 3
Self-service mTLS certificates
Developers issue their own client certificates against a CA you control; the private key never leaves their machine. You onboard mTLS clients without ever touching a key.
Step 4
Producer and consumer policies
Producers: record and batch size limits, throughput caps, schema-registry requirements. Consumers: poll-rate limits, lag protection, read-only protection.
Topics to products
From topics to self-service data products.
One arc, one console: extract an AsyncAPI spec from live Kafka traffic, publish it as a governed API Data Product, and hand developers self-service access.
Live Kafka traffic in. AsyncAPI specs out.
Point the Console at a cluster and it generates an AsyncAPI spec from live topic traffic. One spec, two jobs: defining your API Data Products and driving schema enforcement at the gateway. With a Schema Registry, its contracts are inlined. Without one, the spec alone is enough — the fastest way to keep bad data out of Kafka, with nothing new to stand up.
From a live topic to a versioned AsyncAPI spec, with no manual authoring.
Turn a spec into an API Data Product.
Each product is its spec plus Plans — rate limit and security policy per tier: internal, partner, trial. Versions run side by side, and deployment pushes configuration to every gateway in the target Environment. No restarts, no reload scripts.
API Data Products in a catalog. Each row is one product; versions and deployments stack underneath.
Then developers take it from there.
Register an Application, subscribe to a product, version, and plan, then copy a working client config from the Connection Guide into any standard Kafka client. No ticket, ever.
New developer to first governed Kafka call. Standard Kafka client over SASL/PLAIN + TLS.
Developers never see your cluster credentials, other teams’ products, or registry config. You get the audit trail: every subscription auditable, every credential revocable, every byte attributable.
The operating model
Teams, environments, gateways. One operating model.
Team-based access control
Group users into Teams and attach Entitlements. Catalog visibility, deployment rights, policy authorship, and CA access are all gated by Team membership.
.svg){kind=icon}
Multi-environment, multi-cluster
Each Environment holds its own clusters, gateways, and registries. Deploy one product to many environments at once, each with its own Plans.
In production at
Zilla Plus gave us exactly what we needed — secure, Kafka-native connectivity to our private MSK clusters from anywhere, without compromising security or building custom integrations.
Zilla's extensive protocol support, integrations with AWS services such as Glue Schema Registry and Secrets Manager, as well as robust logging capabilities, gives me confidence it can be a one-stop solution.
Gordon Zardoya
Solution Architect
FAQ
Questions platform teams ask.
Get started
Take command of your Kafka fleet.
Producers: record and batch size limits, throughput caps, schema-registry requirements. Consumers: poll-rate limits, lag protection, read-only protection.
runs the full platform locally · under fifteen minutes