aklivity/zilla: a multi-protocol gateway for Kafka, MQTT, APIs and MCP

The protocol gap Zilla is built to close

Browsers do not speak Kafka. The README states this plainly, and it is the whole motivation. A web client wants HTTP or Server-Sent Events; an IoT device may speak MQTT; the system of record sits on Kafka; an AI agent wants MCP tools. Each hop between those worlds normally becomes a custom bridge with its own authentication code, its own schema checks and its own metrics endpoint.

Zilla's answer is a gateway that terminates one protocol and originates another, with routing, identity, authorization, schema and telemetry shared across every route. The target reader is an engineer who owns that integration layer: a platform team exposing Kafka topics to front-end developers, an IoT group whose devices and backend disagree on protocol, or an AI infrastructure team that needs one governed MCP endpoint instead of a wrapper per provider. The repository topics (api-gateway, kafka-proxy, mqtt, grpc, server-sent-events, asyncapi) describe that audience accurately.

It is worth being precise about what Zilla is not. It is a gateway, not a broker and not a stream processor. It does not store events or run transformations across windows. If your problem is joining two streams over time, a gateway is the wrong layer.

How the streaming engine and the two gateway surfaces fit together

Zilla runs one protocol-native streaming engine and presents two surfaces on top of it. The Event Gateway exposes Kafka and MQTT to applications over HTTP, SSE, gRPC, MQTT or WebSocket. The MCP Gateway gives AI agents a single MCP endpoint backed by MCP servers, HTTP APIs, OpenAPI services or Kafka. Both are described in one zilla.yaml and share routing, identity, authorization, schema, telemetry and deployment.

The architecture section of the README lists the mechanisms. Code-generated flyweights give typed access over encoded buffers. Each connection stays assigned to one worker for its lifetime, which removes cross-thread coordination from the request path. Bindings exchange back-pressured stream frames through shared memory. Cache-enabled Kafka routes can fetch once and serve many downstream consumers. MCP listing and authorization state can be externalized when several replicas must agree.

That last point is the one to watch. Zilla is stateless by design, but MCP capability listings and authorization decisions are state. The README says Zilla Plus adds shared Redis or Hazelcast stores for multi-replica deployments. So the stateless claim holds for request processing, not for the whole system, and a multi-replica MCP deployment without those stores is a topology the README does not describe.

MCP capability naming is namespaced as <toolkit>__<capability>, so github__create_pr and payments__refund cannot collide. The toolkit selects the route. Large catalogs can be split into eager and cold tools so an agent loads only what it needs, and Zilla can relay MCP elicitation and apply schema guardrails on JSON, Avro and Protobuf payloads.

Installing Zilla and running the REST-over-Kafka example

The README gives Docker Compose as the prerequisite and points at the examples directory. Clone the repository and change into it first. Nothing is installed globally; the examples bring up Zilla and its dependencies as containers.

git clone https://github.com/aklivity/zilla.git
cd zilla/examples

The first path is the Event Gateway exposing Kafka over REST. The command below starts the http.kafka.crud example, which the README uses to create and list items.

docker compose --project-directory http.kafka.crud up -d

Once the containers are up, Zilla listens on port 7114. A POST creates a record and a GET reads the collection back.

curl -X POST http://localhost:7114/items \
  -H 'Content-Type: application/json' \
  -d '{"name": "widget", "price": 9.99}'

curl http://localhost:7114/items

What you should see is the created item returned by the second call. The README says the records are visible in Kafka UI at http://localhost:8080/ui/clusters/local/all-topics, which is how you confirm the HTTP request actually became a Kafka record rather than being served from a local store.

The second path is the MCP Gateway. It starts the mcp.proxy example, then you point a Streamable HTTP MCP client at the gateway.

docker compose --project-directory mcp.proxy up -d

http://localhost:7114/mcp

MCP metrics are exposed separately on port 7190, and the README shows a curl against that endpoint. The README also documents a Docker image, ghcr.io/aklivity/zilla:latest, for running the gateway outside the examples, though the install section is truncated in the README and does not show the full docker run invocation.

Where Zilla stops: state, editions and licence

The most important limitation is documented rather than hidden, but it is easy to miss. Advanced OAuth grants and shared Redis or Hazelcast stores for multi-replica deployments are Zilla Plus features. The community edition includes the core Event Gateway and MCP Gateway. If your design assumes several replicas behind a load balancer with consistent MCP authorization state, you are reading about a commercial edition, not the code in this repository.

The licence situation needs the same care. GitHub reports NOASSERTION, and the repository root carries LICENSE, LICENSE-AklivityCommunity, LICENSE-Apache, COPYRIGHT-AklivityCommunity, COPYRIGHT-Apache and a NOTICE.template. That layout suggests a split between Aklivity community terms and Apache-licensed components, but the README does not explain which files fall under which. Treat this as something to confirm with your own legal review rather than something to infer from directory names.

Upgrade cost is visible in the release history. The 2.x line and the 1.3 line both received releases in September 2026, with 2.4.0 and 1.3.2 published on the same day. A project maintaining two lines at once means configuration and migration questions matter. The repository does include a MIGRATING.md and a CHANGELOG.md at the root, which is where those answers live; the README itself does not document rollback or downgrade paths.

Finally, the README's own framing is that Zilla is evolving into a unified Event and AI Gateway, with 2.0 extending the engine with native MCP capabilities. That is a statement about direction, not about completeness, and it is the honest way to read the MCP Gateway surface today.

Zilla compared with a hand-written bridge

The obvious alternative is the thing Zilla replaces: a small service you write yourself that consumes from Kafka and serves HTTP, plus a wrapper per MCP provider. That approach is not wrong. It is often the right call for one protocol pair and one team.

The difference is where the configuration lives. A custom bridge encodes routing, authentication and schema handling in application code, so every new protocol pair is a new service with its own deployment, its own instrumentation and its own failure modes. Zilla moves those decisions into declarative routes in zilla.yaml, so adding gRPC in front of the same Kafka topic is a configuration change rather than a new codebase.

The trade-off runs the other way too. A custom bridge can do anything; a gateway can only do what its bindings support. Zilla's bindings cover the protocols listed in the README (HTTP, SSE, gRPC, MQTT, WebSocket, Kafka, MCP), and anything outside that set means either a new binding or a service next to the gateway. For a single protocol pair with unusual transformation logic, the gateway adds a component without removing much work.

There is also an operational difference. A custom bridge is one process you already know how to debug. Zilla is a gateway with worker affinity, shared-memory frame exchange and, for MCP, externalized state. That is a different mental model, and the README points to a separate architecture write-up rather than explaining it end to end.

Who should adopt Zilla and what to check first

The fit is narrow but real. If you already run Kafka or MQTT and need to expose it over HTTP, SSE or gRPC without writing a bridge per protocol, Zilla's declarative routes are a reasonable bet, and the examples directory gives you runnable starting points for each combination. If you are standing up an MCP endpoint that must aggregate several providers with one authentication and authorization story, the namespaced toolkit model and the eager/cold tool split address a problem that is otherwise solved with per-provider wrappers.

The misfit is equally clear. If you need a commercial support contract, distributed OAuth grants or shared stores across replicas, the community edition does not include them, and you should price Zilla Plus before designing around the gateway. If your integration logic is genuinely bespoke, a gateway will constrain you more than it helps.

Before deploying anything, resolve the licence question by reading LICENSE-AklivityCommunity and LICENSE-Apache directly, since the repository reports NOASSERTION and the README does not map files to terms. Then read MIGRATING.md to understand what a move between the 1.3 and 2.x lines involves, because both lines are receiving releases. The last push to the default branch was on 2026-09-10, and the most recent release was 2.4.0 on 2026-09-07, so the project is moving; that also means your configuration is a moving target.

Editorial conclusion

Adopt Zilla if you already run Kafka or MQTT and want HTTP, SSE, gRPC or MCP access without writing a bespoke bridge, and if Docker Compose plus a zilla.yaml route file matches how your team already deploys. Do not adopt it if you need a supported commercial contract, distributed OAuth grants or shared stores across replicas, because those are Zilla Plus features, and do not adopt it if you will not read the configuration reference. Before committing, verify three things: the exact licence terms in LICENSE-AklivityCommunity and LICENSE-Apache, whether the Zilla Plus features you need are mandatory for your topology, and whether the MCP Gateway surface is stable enough for your agent traffic, given that 1.3.x and 2.4.0 shipped within days of each other in September 2026.

Frequently asked questions

Official sources

1. aklivity/zilla on GitHub
2. Issues
3. Project website
4. README
5. Releases