Release notes

Highlights

• Kafka's own health, over JMX. With JMX set up, every broker and controller reports what it measures about itself — the active controller, offline partitions, partitions under their minimum in-sync replicas, request rates and their 99th-percentile time, how idle the request handlers and network threads are, heap, garbage collection, CPU and file descriptors. The figures are read live and never stored.
• Alerts on what surrounds Kafka. A rule can watch a Kafka Connect cluster and its connectors, the Schema Registry, and every JMX figure worth acting on, with starter rules for each.
• Alerting that settles. An incident resolves once its figure has stayed clear for a while, an incident that reopens soon after does not notify again, and everything that breaches on one connection at once reaches a channel as one message.
• An MCP server for AI assistants (Commercial). Claude Code, Claude Desktop, Cursor or another MCP client reads the estate and, where an administrator allows it, changes it — as the owner of an API token, with that person's permissions, under every guard the console applies, and on the audit trail. Off until an administrator turns it on.
• Data masking (Commercial). Rules hide chosen fields of messages and values — a card number, an address, a header — from people who may read the rest. Seeing them unmasked is a permission of its own, and every such read is recorded.

Changes

Kafka

• JMX in its own dialog — an address per broker and per controller, for clusters whose brokers sit behind a load balancer, and a test that asks every node once and names why one did not answer.
• Health on the Brokers page — Active controller, Offline partitions and Under min ISR tiles, and optional State and Offline log dirs columns.
• Graphs — requests per second and their p99 time by type, handler and network idle, the request and response queues, and messages in per broker.
• A broker's Metrics tab — heap, garbage collection, CPU, file descriptors, threads, log flush time, ISR changes, failed requests and rejected bytes. A controller that is not a broker is read as a node too, from the Quorum tab.
• A topic's rates — bytes in and out and messages in per second, read when its page is open.
• When not every node answers — a figure about one node shows for each node that answered; a figure about the whole cluster shows only when every node it depends on answered, and says why when it does not.

Alerts

• New things to watch — Kafka Connect clusters and connectors (unreachable, failed, paused or stopped, failed tasks), the Schema Registry (unreachable, slow, read-only, subject count), and the JMX figures per node. A component that does not answer reads reachable = 0, which a rule can fire on.

• Resolve after and Cooldown — two minutes and ten minutes unless you choose otherwise; Notify when resolved, on unless you turn it off.

• Stale and unevaluatable, said plainly — a rule nothing has evaluated for three periods reads stale; a rule on an old Kafka snapshot says how old; a rule that would watch more than 500 targets on one cluster watches the first 500 and says so.

• Each connection on its own schedule — a cluster that is down or slow delays only its own rules, and a component that does not answer fails alone.

• Delivery — one message per channel per connection per evaluation, listing every breach; a channel that asks to be waited for is waited for, and a slow channel holds back no other.

• History — resolved incidents and the record of their notifications are kept for the audit retention window, then removed.

• Shovels, federation links, bridges and broker connections (Commercial, with RabbitMQ or Apache Artemis) — a rule can watch whether a RabbitMQ shovel or federation link runs, what a shovel has pending, whether an Artemis bridge or broker connection is connected, and how many members a cluster connection sees.

MCP server (Commercial)

• Settings ▸ MCP — Off by default, Read only, or Read and write; the endpoint's address and the configuration for Claude Code, Claude Desktop and Cursor. A token for an assistant is made under Profile ▸ API tokens and can be limited to the permissions the work needs.
• The mcp.use permission — in the built-in Admin role only; anyone else is granted it, across the installation.
• Tools for Kafka, Redis, RabbitMQ, Apache Artemis and Memcached — reads, including message contents where the token's owner may read them; changes the console makes, with a preview first where the console previews and a reason on every destructive tool.
• Never through MCP — users, roles, grants, tokens, settings, the licence, connections, environments, alerting, broker access control and whole-cluster operations stay in the console.
• On the record — every call carries the channel MCP with the tool, the client and the token's prefix, and the audit log filters on it. Contents somebody else wrote come back marked as data, never as instructions.

Data masking (Commercial)

• Settings ▸ Data masking — rules by platform, scope and resource pattern; fields by JSON path, header, record key, whole value or Redis hash or stream field; Redact, which keeps a JSON value's type, or Partial, which keeps the first and last characters you choose; a live preview and who sees each rule unmasked.
• Everywhere contents are shown — Kafka records, RabbitMQ and Artemis messages, Redis and Memcached values, and what the MCP server returns, masked before they leave the broker service. A value a rule cannot read is masked whole.
• Read masked contents unmasked (messages.read.unmasked) — in no built-in role, granted on an environment, a connection or a resource pattern; every unmasked read is recorded, whatever the read-recording setting.
• Filters, writes and copies — a filter cannot reveal a masked field, a masked item cannot be written back, and moving or copying masked contents somewhere the rule does not reach is refused.
• Kept when a licence lapses — every rule stays applied; only changing the rules waits for a valid licence.

RabbitMQ (Commercial)

• Restart a shovel — from its row, after the far end of a shovel that terminated is fixed. Recorded in the audit trail.

Console

• Resizable columns — the resize handles are visible and easy to grab, and a resized name column can be made narrower.

Known limitations

• linux/amd64 only.
• The API runs as a single replica; there is no high-availability mode.
• TLS is not terminated in the stack: put a reverse proxy or a load balancer in front.
• The Compose recipe runs its own PostgreSQL; it has no setting for an external one.
• No single sign-on (SSO, LDAP) and no multi-factor authentication.
• No self-service password reset in the console: an administrator resets a user's password.
• JMX figures are live only: there is no history of them. A managed Kafka service that exposes no JMX shows Needs JMX where they would be.
• A topic's own rates are shown on its page and cannot be alerted on.
• Data masking changes what BROKA shows, not what the broker holds: a client reading the broker directly sees the original, and nothing is encrypted at rest.
• The MCP server reaches no alert rule, incident or silence, and changes no Kafka ACL. A plan an assistant previewed is kept in memory for ten minutes, so a restart of the API drops it and the assistant previews again.

Upgrade notes

• Change the pinned version. Apart from the version they pin, 1.0.1's compose.yml and .env.example are 1.0.0's, so only BROKA_VERSION changes in your .env: set it to 1.0.1, pull and start. The API applies its database migrations when it starts.
• Back up first. Back up the database, and .env with it — BROKA_KEK decrypts every stored credential. Migrations go forward only: moving back to 1.0.0 on the same database is not supported.
• JMX settings carry over. A connection's JMX port, user and password from 1.0.0 are read as they are. Open the JMX dialog to give a broker or a controller an address of its own.
• Existing alert rules take the new defaults — resolve after two minutes, a ten-minute cooldown, and a notice when an incident resolves. Change them on the rule.
• Commercial: nothing new is switched on. The MCP server starts Off, no masking rule exists until one is written, and no role holds messages.read.unmasked. Upgrading a Commercial installation is described in the customer portal.

Highlights

• One operations console for Apache Kafka, on your own infrastructure. Broka runs in your network and manages Kafka in full depth — and any Kafka-protocol-compatible broker, such as Redpanda or Amazon MSK, through the same connection.
• One operational layer around it. Environments that carry a policy, production guardrails, users, teams and scoped roles, and an audit trail that records every write and every refusal — hash-chained, verifiable and exportable.
• Installed with Docker Compose, with no account and no activation. It sends nothing anywhere. The three images are on Docker Hub and signed; cosign verify --key https://broka.dev/keys/cosign.pub checks each one before you run it.

Changes

This is the first release, so this section lists what it contains.

Kafka

• Clusters and brokers — the cluster overview, each broker's configuration and log directories, partition and leader skew, under-replicated partitions, and live broker graphs.
• Topics — the topic list, topic detail with partitions, editable configuration, creation and deletion.
• Messages — browse a topic with filters, and produce single messages or batches.
• Consumer groups — lag per group and partition, group detail, and offset resets.
• ACLs and service accounts — describe, create and delete ACLs, per principal.
• Schema Registry — subjects and versions with a side-by-side diff, Avro, JSON Schema and Protobuf, compatibility settings, and messages encoded and decoded against the registry when producing and browsing.
• Kafka Connect — connectors and their tasks.
• Transactions, client quotas and client metrics.
• Supported features per connection — what the connected cluster can do is probed rather than assumed from its version, and a feature the cluster does not offer is shown disabled with the reason.

Console

• Connections — a registry of clusters per environment, with credentials encrypted at rest.
• Dashboard and search — health across the estate, and one search over clusters and resources.
• Saved views, table layouts, templates and resource metadata — owners and labels on the resources you operate.
• Alerts — rules on broker metrics, silences, and delivery by e-mail.
• Access — users, teams and roles scoped to an environment or a connection; reading message contents is a permission of its own.
• Guardrails — a destructive operation asks for a reason, and a production environment can be read-only.
• Audit — every administrative action, write and refusal, kept for at most 180 days — which is also the default — with integrity verification and export.
• Your account — sessions, password change and personal API tokens. Administrators set the session idle timeout and the password policy.

Deployment

• Docker Compose — compose.yml and .env.example at /download/1.0.0/, with their SHA-256 checksums.
• Four containers — the console, the API, the broker service and PostgreSQL 17, with only the console published on one port.
• Signed images — orchestalabs/broka-orchestrator, broka-broker and broka-ui, each signed and carrying an SBOM attestation.
• Migrations at startup — the API applies its database migrations when it starts.

Known limitations

• linux/amd64 only.
• The API runs as a single replica; there is no high-availability mode.
• TLS is not terminated in the stack: put a reverse proxy or a load balancer in front.
• The Compose recipe runs its own PostgreSQL; it has no setting for an external one.
• No single sign-on (SSO, LDAP) and no multi-factor authentication.
• No self-service password reset in the console: an administrator resets a user's password.

Upgrade notes

This is the first release, so there is nothing to upgrade from.

• Pin the version. .env.example ships with BROKA_VERSION=1.0.0; keep it pinned, so an upgrade is an edit you make rather than something that happens on restart.
• Back up .env with the database. BROKA_KEK encrypts every stored credential: a database restored without it cannot decrypt them.
• Migrations go forward only. Moving to a later version is supported; moving back to an earlier one on the same database is not.