BROKA — releases and guides

Broka 1.3.2

2026-10-24T00:00:00Z

Highlights

Making an API token is a permission of its own. Create API tokens is in every built-in role, and every account that already had a token keeps the ability. Take it away, and that person's tokens are revoked.
More at a glance. A chart writes its latest reading beside its title, Kafka service accounts say when Broka last changed their rules, the Redis configuration marks what differs from Redis's default, and a saved view opens on its screen.

Changes

Access

Create API tokens (api_tokens.create) — making an API token now takes this permission, which every built-in role carries; an account that held a working token when you upgrade is given it on its own, so nobody who used one loses it. Without it, Profile ▸ API tokens shows New token greyed out with the reason, and the list stays readable and revocable. If the permission is taken away — a role removed or changed, a team left, a deny — the person's tokens are revoked at their next use and within the hour otherwise, each revocation recorded in the audit trail. If someone other than an administrator manages users through a role of your own, add Create API tokens to that role: the console does not let a person reset or sign out an account that holds a permission they do not, and every built-in role now carries this one.
The list of people — the names and e-mail addresses the console offers when you add a team's members or an application's owners — is read with Manage users, Manage teams, Manage applications or See the applications catalog. An account with none of them, such as one created at its first single sign-on and not yet given a role, reads nobody's address.

Metrics

The latest reading beside the title. A metric chart — a Metrics tab, an overview's Metrics section, the alert rule dialog — writes its latest reading beside its title, or beside each target's name in the key of a chart that draws several. It shows only while the range runs to now and the line has not stopped; hover it for when it was read.

Kafka

Service accounts: Last changed in Broka. Beside each account's rule count, when a rule of its was last granted or revoked through Broka. Kafka keeps no time on an ACL, so this is read from Broka's audit trail; a change made with Kafka's own tools, or older than the trail keeps, reads as a dash.

Redis (Commercial)

Configuration: Changed and Only changed. A parameter that is not at Redis's own default for the server's version is marked Changed — hover it for the default — and Only changed shows just those. Redis does not report its defaults, so Broka keeps them for every release from 6.2 to 8.10; where and how the server runs (its directory, address and port) is never counted as a change, and a fork or a newer release has none to compare with.

Saved views

What a view holds, and Open. Each row on Operations ▸ Saved views says on one line what the view holds — its sort, optional columns and page size, or a saved search's topics and filter — and Open takes you to the screen it was saved on with the view applied. Views saved before 1.3.2 have no Open.

Security

The release check-in is signed. Each installation signs its daily check-in with its own key and sends the key's public half with it, so what we hold for an installation — the registration its security notices go to — changes only on that installation's word. Nothing else is added to what it sends.
The console image runs nginx 1.30.6 and Brotli 1.2.1. nginx 1.30.5 and Brotli 1.2.0, in the console image of 1.3.1 and earlier, carry CVE-2026-15176, CVE-2026-93479, CVE-2026-97205 and CVE-2026-111497; none is reachable in the configuration BROKA ships — see BROKA-SA-2026-005.
POST /api/v1/ping/echo is gone. An unauthenticated route that answered with whatever was posted to it, which nothing in the product called. GET /api/v1/ping stays.

What changed in BROKA from 1.2 to 1.3

2026-10-24T00:00:00Z

People sign in through your identity provider, with its groups mapped to BROKA teams; one search reads many Kafka topics at once; and consumer groups are deleted in bulk.

Broka 1.3.1

2026-10-21T00:00:00Z

Highlights

A calmer console. Every list keeps one action on a row and the rest in its ⋯ menu, page headers show their main action and one other, and the explanations sit behind a ? beside the title instead of on the page. An action you cannot take is shown greyed out, with the reason.
Searching Kafka messages is simpler. One box searches the key, the value and the headers at once; the filter language, conditions, formats and limits are under More options, and where to start reads as a time range.
Figures that say how far they go. An Apache Artemis count the broker stopped early reads at least, message counter times are written like every other date, and offsets are written in full.

Changes

The whole console

Row actions in one menu — every list shows at most one action on a row; the rest, deleting included, are in the row's ⋯ menu, and an action you cannot take is shown greyed out with the reason.
Calmer page headers — a page shows its main action and one other; Delete, Purge, Reset and the like are in the header's ⋯ menu, still confirmed as before. Back buttons are gone: the breadcrumb leads back.
Explanations behind ? — a page opens with one line saying what it lists; how it works and why sits behind a ? beside the page, card, field or dialog title. Warnings that change what you are about to do stay in view.
Internal objects hidden — Kafka's internal topics (_schemas, _connect-*), Schema Registry subjects starting with _, and Apache Artemis's own queues are hidden until you choose Show internal (n), then marked Internal.
Units in words — durations and sizes you type are read back ("= 3 days", "= 2 MiB/s"); -1 limits read Unlimited.
Tables — Columns and View sit at the right of the filter row on lists, and are not shown over an empty table or on small tables in tabs, cards and dialogs; an empty list shows only its empty state, with no pager. A list with no filters keeps View in its table header.
Confirmations — a confirmation can carry a ? with its explanation, and the note under a reason field reads Recorded in the audit trail.
Status — a normal state (running, healthy, enabled) reads quietly; only states that need attention are coloured.
Sentence case — titles, buttons, columns, badges, the sidebar and the breadcrumbs (Consumer groups, Client quotas, Audit logs).
Notable moves: a consumer group's Reset offsets is a button at the top of its details; Schema Registry's compatibility and mode change from their value in the summary line; a Redis key's Rename, Copy, Move, TTL, Export and Import are in its panel's ⋯ as small dialogs; Profile ▸ API tokens lists the tokens first, with New token in a side panel; the Audit log has Export and Verify integrity in its header.
Documentation examples — the documentation's examples and screenshots now follow an investment firm: market data, orders, trades and settlement.

Screens reworked

Overview shows every figure in one row — one connections card, open alerts, Kafka lag, Redis, RabbitMQ, Apache Artemis and Memcached — with connection health right under it; recent activity reads as sentences and shows changes, with reads one click away. The panels under them are titled Highlights; a row no longer repeats its name on a second line, and RabbitMQ rows name their vhost.
A connection's form shows a stored secret as one Stored · Change row, with Rotate key and Clear in its ⋯; the test result sits above the form's buttons, with its caveats apart. Supported features lists what is unavailable first and folds the rest.
Sign-in has no placeholder dots and a Forgot password? hint; a one-time password has one Copy, on one line.
Settings pages save through one bar — Unsaved changes · Save / Discard appears when something changed; actions that take effect at once (rotate a key, stop forwarding, send a test) keep their own buttons. MCP's client snippets are on tabs, and Feature flags is left out of the menu while no feature reads a flag.
Connections can be searched by name or tag, and Search has a full-width box, platform icons and a platform filter.
Alerts group open incidents by rule, with Acknowledge and Silence for a selection; an incident opens with Acknowledge, Silence and a link to its resource, its condition in words and the moment it fired on the chart; History shows when each incident was resolved and how long it lasted. In the rule dialog every condition is boxed alike, Enabled is in its header, and the preview shows the targets that would fire; Silences' header action reads Silence alerts.
Administration — API token scopes are grouped, with View everything and Manage everything, and token dates read with the time since; Users hide columns that are the same on every row; Resource metadata fades the rows of deleted connections and removes them together; Data masking lists its methods in a fixed order; About is one About this installation card with the update check. Applications (Commercial) has no row of figures, an initial as each application's icon and a list that goes past 12, and an application opens on its Resources. Saved views are grouped by screen, and templates are listed with their platform and kind.
Kafka broker and consumer group details are pages of their own; change dialogs show what would change as you type; the Brokers page sums the cluster up in one strip; broker configuration opens on the changed properties.
Kafka lists — Topics drop the row of figures and gain a Messages column; Replication factor and Min ISR show only when topics differ, and labels stay on one line with +n. Consumer groups show one state badge, Type only when kinds mix, and no rate for a group with no members. The Schema Registry list puts the name first, counts versions only where they differ, and has a Show soft-deleted toggle.
Kafka details — the Kafka overview is titled with the connection's name and reads its activity as sentences; a broker has a Log directories tab with usage bars; a group's protocol is in its subtitle and its epochs on the Members and Topology tabs; a topic's idle rates read No activity.
Kafka forms — client quotas are named in words with their unit, Kafka's key beneath; the connector wizard picks the plugin first (Sources, Sinks, Utility) and asks for the name with the properties, and the connector form marks defaults with a Reset and saves through the Unsaved changes bar; Produce has one Insert… menu for the sample and templates, with format, subject and version on one line; a record's detail no longer repeats its partition and offset; a service account has a Rules column, Add access rule and the Unsaved changes bar; Schema Registry's Structure shows enum symbols, with a version's metadata beside the schema.
RabbitMQ Overview shows its key figures in one row; Routing opens on one exchange; move, binding and shovel dialogs pick existing queues and exchanges from a list; permissions read in Configure, Write and Read columns; Exchanges and Connections leave the broker's built-in exchanges and direct connections out until asked.
RabbitMQ lists — Channels lead with the client's name and read prefetch 0 as Unlimited; Consumers show the queue, client, ack mode and prefetch under one summary strip; the vhost line shows only with All vhosts; Exchanges flag only exceptions; a queue's Overview is in three groups and its Metrics three to a row; the Overview puts health checks and deprecated features in one summary and sorts node memory; Policies, Virtual hosts, Shovels and Federation can be searched.
Redis Overview, Pending entries (a stream picker), stream ids on one line, Diagnostics (reports folded when they found nothing) and Hot keys (one Start/Stop) are simpler.
Redis keys and tools — Keys show one count and Load more; the slow log is summed on one line with relative times; configuration is edited by clicking its row; JSON documents are indented; keyspace notification flags are labelled checkboxes; Analysis shows the sample first and key sizes as bars; cluster shards are in slot order; consumer groups are grouped by stream and link to their pending entries; Trim asks for a reason.
Apache Artemis Addresses and Consumers leave the broker's own objects out until asked; a prepared transaction's time is a date; Commit and Roll back are in the transaction's details; Maintenance is one list with a Danger zone; Address settings read in words and units. Memcached's node picker is in the page header.
Apache Artemis lists and forms — lists search by name as you type, with other fields under Add filter; a queue's Messages have a Bulk actions menu, each action confirmed with the number of messages it matches; Edit queue has an Unlimited checkbox for each -1 limit and an Advanced section; address settings and permissions pick their match from the broker's addresses or a wildcard; Configuration lists the editable settings first; the Overview's top row counts connections and sessions. With the broker's own objects left out, a page more than 10,000 rows in is refused, with a message to filter or show them.
Memcached shows four headline figures; capabilities read All available or the number missing; Nodes show state, items and memory; the slab histogram is drawn as bars; one Look up with Show value; Watch and Stop are in the header; Flush asks in one sentence, with the delay in seconds.

Kafka

Searching messages is simpler — on a topic's Messages tab and in Message Search (Commercial), one box searches the key, the value and the headers at once (Search in: Anywhere, the default), or only one of them. The less common options — the filter language, conditions, formats and limits — are under More options. Where to start reads as a time range (the last 15 minutes, hour, 24 hours or 7 days) as well as the newest, the beginning or a time.
Topics as chips — Message Search lists matching topic names as you type, in the console's own list, and each chosen topic is a chip.
Name pattern help — a ? beside Message Search's name pattern explains that the whole name must match and gives examples (Commercial).
Selecting consumer groups to delete stops at 500 — Select all takes the first 500 groups in the list's order and the other boxes lock, since one deletion takes at most 500; it was possible to select more and have the deletion refused.
Connectors with a failed task — a connector Kafka reports as running while one of its tasks has failed now reads Degraded, in the list and on the connector's page; it read Running.
Offsets in full — offsets, epochs and sequence numbers are written in full (785,583) in offset resets, Brokers ▸ Quorum, producers and a topic's held range; they were shortened (785K), which hid what a reset would commit.
A consumer group's lag — the figure at the top of a group's details now agrees with the tables under it; it could show the lag of the list's last refresh.
Comparing schema versions — the version pickers follow the two panels, older on the left and newer on the right.
Converter settings named apart — a connector's form names the key and value converters' settings Key encoding and Value encoding; both read Encoding.
The Topics page is titled Topics and counts topics; it was titled Kafka and counted consumer groups.
States in words — transaction states, broker configuration sources and consumer, share and streams group states read as words (Complete commit, Static broker config, Preparing rebalance); a configuration source shows Kafka's own name on hover.
Known zeros — an emptied partition counts 0 records, and a topic with no traffic yet shows 0 on its Metrics tab; both showed a dash.
Samples that match the schema — on a topic whose key or value is produced through the Schema Registry, Produce's Load sample fills a sample built from the chosen subject and version (Avro, JSON Schema or Protobuf), with its defaults, enum symbols and timestamps, which the schema accepts; it filled the same order event on every topic, which a schema refused. In Batch it fills two such records.

Apache Artemis

Selector boxes say they hold an example (JMS selector, e.g. tenant = 'acme'); the bare example read like a filter already applied.
Dates instead of milliseconds — the broker's current time on Broker ▸ Configuration, and a held message's timestamp and expiry in a transaction's details, are written as dates.
Subscriptions are paged by the broker service with the broker's own internal queues already left out, so every page is full and the total counts subscriptions only.
The oldest message's age reads in whole units (22 d) on a queue's Overview.
The broker's own addresses — the cluster's store-and-forward address, the mirror address and $sys.mqtt.sessions are recognised as the broker's own when every queue on them is internal: they are hidden behind Show internal and badged Internal when shown.
A count the broker gets wrong — when Artemis reports a negative message, consumer, delivering or scheduled count, the console shows a dash and says what the broker reported, instead of printing the negative number; alert rules treat it as not measured.
Anonymous connections — a connection whose sessions are all anonymous carries the Anonymous badge, as its sessions do; it showed a dash.
Clearer read failures — a message list that cannot be read says why in plain words; the broker's Java exception no longer reaches the screen, and an unexpected failure points to the broker service's log.
Count by original address says how much it counted — Artemis 2.44 stops this count after 200 messages (the address's management browse page size), so a dead-letter queue of 1,500 counted to 200 and the table read as the whole queue. The result now says Counted 200 of the 1,500 messages in this queue and why, and with a filter how many of the messages looked at match; a broker that counts the whole queue shows no such line.
Filtered match counts say "at least" — with a selector, the same limit applies to the number of matches on a queue's Messages tab, so a filtered bulk action on a large queue could state fewer matches than it would act on. When the broker stopped counting, the pager shows the figure with a + and the bulk action's confirmation says at least that many and that the broker counted only the first 200 messages.
Message counter times as dates — a queue's Counters tab writes Last sampled, Last message added and Last message acknowledged, and the hours on its chart, like every other date in the console, in the installation's time zone; they showed the broker's own format (10/20/26, 12:14:14 PM). A time that cannot be read shows a dash that says so.

Redis

Testing a command as an ACL user moved to the user's row menu, Test command. It tests the rules saved on the server; inside the edit dialog it looked as if it tested the unsaved edits. Anyone who can see the list can use it, since it is a read. The edit dialog shows every command category, wrapped.
Uptime under an hour — Tools ▸ Command activity says how long ago the counters started in minutes when it is under an hour (25 min); it read 0h. Longer spans read like the rest of the console (3 d 4 h).
Primary and replica — a server's role reads primary or replica everywhere, including the Overview and the client-type filter when disconnecting clients; it read master in places.
JSON keys — a RedisJSON key's type reads json in the type chip and the type filters, not ReJSON-RL.
Pending entries opened by name — when a stream is opened from a link or typed in, the line under the picker says so and how many SCAN calls have looked for others (Opened by name · no others found in 20 SCAN calls so far); it read 0 found so far beside the chosen stream.
Overview tables fit their cards — the Keyspace and Replication tables no longer scroll sideways and cut off their last column.

RabbitMQ

Rebalance queue leaders on one node — the Overview's Rebalance queue leaders is disabled on a single-node cluster, with the reason; there is nothing to rebalance there.
Units on rates — the In / out column names its unit (msg/s, or B/s on Connections), and a missing value is always the same dash.

Memcached

Why a node refuses Flush — the reason on a node started with -F can be reached with the keyboard as well as by pointing at it.
Item-size histogram labels — each bucket is labelled in exact bytes (2,144 B, 2,176 B), so neighbouring buckets no longer share one rounded label such as 2.1 KB.

Alerts

An incident's reading is labelled Reading when it fired: it is the value at that moment, while the chart runs on to now.
One name for a rule nothing could measure — unevaluatable, in the rule list, its banner and a rule's Check; the same state was also called unmeasurable.

Console

Counts read as English — messages, keys, records, replicas and the rest are written as 1 message or 10 messages, with the sentence agreeing; they read message(s).
Live screens on an expired session — Memcached Live events, Kafka consume and message search, and Redis Pub/Sub and stream following now renew an expired sign-in when they start, as every other screen does, or go to the sign-in page when the session has ended. They said Authentication is required and stayed on the console, signed out, until the page was reloaded.

Settings and connections

Single sign-on providers fit the page — the providers table no longer scrolls sideways and cuts off View in its header at a common desktop width.
Resource metadata — each row has one actions menu; Edit and Delete could fall off the right edge of the table. A row whose connection was deleted says so, instead of showing the connection's identifier.
A Kafka connection that is not secure is shown as a warning, and its sentence now says the environment's policy does not allow skipping the hostname check — it said the check was disabled.
Settings ▸ MCP — the Claude Code command wraps inside its box, so the whole command is visible; its end was cut off.
Settings ▸ Users — the column of each user's roles is titled Roles (it said Groups) and writes them as the Roles page does; the button that adds a user reads Add user (it said Create members).
Connections — every row keeps the same actions column, so the status labels line up across platforms.
Single sign-on with no provider shows one New provider button, and empty lists there show no 0–0 of 0 pager.
Settings ▸ About links the Licence page it mentions.

Known limitations

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 multi-factor authentication of Broka's own. With single sign-on, a second factor the identity provider says was used is recorded.
Single sign-on speaks OpenID Connect and LDAP, not SAML: a provider that speaks only SAML is bridged through an identity provider that speaks both.
Nothing is provisioned from an identity provider. Someone removed there keeps an open session until its maximum length, and an account that signs in only through the provider keeps its API tokens until 30 days without a sign-in; disable the account in Broka to stop it at once.
Google sends no groups, so a Google provider maps no groups to teams and creates no accounts.
A sign-in that carries no groups changes no team membership, and some identity providers, Okta, Microsoft Entra ID and Keycloak among them, send no groups at all for someone in none of the groups they are set to send. Removing someone from their last mapped group there changes nothing in Broka: disable the account, unlink it or remove the mapping.
No self-service password reset in the console: an administrator resets a user's password.
The metric history starts empty. Charts, changes, comparisons and bands have nothing to draw or compare with until it fills, and a band waits for three days of its hour.
A connection keeps at most 1,000 series; a resource beyond them has no chart. A Redis stream has a chart only when an alert rule watches it.
The Brokers ▸ Graphs JMX figures are live. A JMX figure is kept in the history only when an alert rule watches it.
If every broker of a Kafka cluster is replaced at once by brokers with other names, Broka finds the new ones when the connection's settings are changed or the broker service is restarted.
The release check needs a route to license.broka.dev; without one, Settings ▸ System cannot tell you that a newer release exists, or that a security advisory affects the version you run.

Upgrade notes

Change the pinned version. Set BROKA_VERSION to 1.3.1 in your .env, take the new compose.yml, pull and start. Nothing else in the recipe changed.
No database migration. This release changes no table, so 1.3.0 can be put back on the same database by setting BROKA_VERSION back.
Commercial: upgrading a Commercial installation is described in the customer portal.

Broka 1.3.0

2026-10-16T00:00:00Z

Highlights

Single sign-on (Commercial). People sign in through your organisation's identity provider — Okta, Microsoft Entra ID, Google, Keycloak or any other OpenID Connect provider — or with their directory password over LDAP, from Active Directory or OpenLDAP. Groups at the provider map to Broka teams, and accounts can be created at a first sign-in, inside the limits you set. Signing in with a password stays available, always.
Message Search (Commercial). One search reads many Kafka topics at once — by name, by a name pattern, by a consumer group's topics or all of them — with the message browser's filter, and shows the topic of each match. Export the results, produce one again to any topic, and save the search for yourself or a team.
Deleting consumer groups in bulk. Tick several groups and delete them together, or clean up the empty groups whose names match a pattern, such as the ones console consumers leave behind.

Changes

Single sign-on (Commercial)

Providers — in Settings ▸ Security ▸ Single sign-on: OpenID Connect and LDAP providers, several at once, each enabled only after a test has passed with its saved settings. Test sign-in signs nobody in, links nothing and creates nothing; a directory has Test connection and Look up a person.
Signing in — one button per OpenID Connect provider, above the password form, which is always there. A directory's people sign in on the password form, with their e-mail address and directory password.
Which account — an identity is linked to an account by the provider's own identifier for the person. An existing account can be linked by a verified e-mail address in your domains, never one that can manage anything in Broka; an account can be created at a first sign-in, only for a verified address in your domains with a mapped group, under an hourly ceiling. An administrator links anyone else from their refused sign-in.
Groups and teams — a mapped group puts people in its team at each sign-in and takes them out when a sign-in no longer carries the group. Memberships added by hand are never changed.
Sessions — a session started through a provider lasts at most the provider's maximum length, 12 hours by default. An account that signs in only through a provider stops using its API tokens after 30 days without such a sign-in. Signing out of Broka can sign the person out of the provider too.
Disabling a provider ends every session it started, at once.
The audit trail records how each session was signed in, through which provider, and whether the provider said a second factor was used.

Kafka

Message Search (Commercial) — Kafka ▸ Message Search reads up to 50 topics at once: the names you type, every topic whose whole name matches a pattern, a consumer group's topics, or all of them. It starts at the newest records, the beginning or a time, and filters with the message browser's own filter, conditions and formats. Topics you may not read are left out and counted. Each topic keeps a share of the limit while it is being read, so a busy topic cannot crowd out a quiet one. Results can be exported as NDJSON or CSV, produced again to their own topic or another with an x-broka-origin header, and the search saved for yourself, a team or everyone. Each topic read is recorded in the audit trail as its own read. In Community the entry is shown, marked Commercial.
Deleting consumer groups in bulk — tick groups in the consumer groups list and choose Actions ▸ Delete selected, or Clean up the empty groups whose names match a pattern (console-consumer-*). Clean up lists the groups it will delete first; both ask for a reason and confirm, up to 500 groups at once. Kafka deletes only a group without members, so a group that is consuming is never offered and is refused in a selection; a card names every group that was not deleted, and why. On a protected environment the same guard applies as to deleting one group.

Users and teams

A password administrator is always kept — at least one account that can sign in with a Broka password and holds both Manage users and Manage security settings. A change that would remove the last is refused, and unused accounts are never disabled past it.
How each account signs in (Commercial) — a Sign-in column in Settings ▸ Users, and a Sign-in tab in the user's panel for linking, unlinking and linking to a directory. In Community the tab is shown locked.
Memberships a group gives (Commercial) are marked in a team's Members, and removing someone by hand there takes away only the membership you added.
A deleted account's identities are blocked (Commercial): signing in through a provider again creates no new account until an administrator lifts the block.

Console

Dates in one format — every date and time is written the same way whatever the browser's language, day first, 24-hour, in the installation's time zone (15 Oct 2026, 14:09:50).
The installation's time zone is set at setup — the time zone chosen on the first-run screen now becomes the installation's display zone; it was kept only on the administrator's profile, which left times in UTC.
A dialog stays open while you type — a dialog or side panel no longer closes when you press a password manager's or a writing assistant's button drawn over one of its fields. A press on the dimmed page around it still closes it.

RabbitMQ

A queue's figures follow a change — after a publish, a purge or another write on a queue's page, its statistics keep refreshing for a full 15 seconds from that change, so a purge shortly after a publish no longer leaves the Ready count frozen.

Security

The API's .NET runtime — updated to 10.0.13, which closes five CVEs in the runtime's XML signature and encryption and CMS libraries; none was reachable in the way Broka ships — see BROKA-SA-2026-002.

Known limitations

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 multi-factor authentication of Broka's own. With single sign-on, a second factor the identity provider says was used is recorded.
Single sign-on speaks OpenID Connect and LDAP, not SAML: a provider that speaks only SAML is bridged through an identity provider that speaks both.
Nothing is provisioned from an identity provider. Someone removed there keeps an open session until its maximum length, and an account that signs in only through the provider keeps its API tokens until 30 days without a sign-in; disable the account in Broka to stop it at once.
Google sends no groups, so a Google provider maps no groups to teams and creates no accounts.
A sign-in that carries no groups changes no team membership, and some identity providers, Okta, Microsoft Entra ID and Keycloak among them, send no groups at all for someone in none of the groups they are set to send. Removing someone from their last mapped group there changes nothing in Broka: disable the account, unlink it or remove the mapping.
No self-service password reset in the console: an administrator resets a user's password.
The metric history starts empty. Charts, changes, comparisons and bands have nothing to draw or compare with until it fills, and a band waits for three days of its hour.
A connection keeps at most 1,000 series; a resource beyond them has no chart. A Redis stream has a chart only when an alert rule watches it.
The Brokers ▸ Graphs JMX figures are live. A JMX figure is kept in the history only when an alert rule watches it.
If every broker of a Kafka cluster is replaced at once by brokers with other names, Broka finds the new ones when the connection's settings are changed or the broker service is restarted.
The release check needs a route to license.broka.dev; without one, Settings ▸ System cannot tell you that a newer release exists, or that a security advisory affects the version you run.

Upgrade notes

Change the pinned version. Set BROKA_VERSION to 1.3.0 in your .env, take the new compose.yml, pull and start. The API applies its database migrations when it starts; they only add tables and columns, and every session open at the upgrade carries on as a password session.
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.2.1 on the same database is not supported.
Commercial: nothing is switched on. No identity provider exists until one is added, and the sign-in page is unchanged until one is enabled. Upgrading a Commercial installation, and what single sign-on needs from the deployment, are described in the customer portal.
Moving from Commercial back to Community removes sign-in through identity providers. Accounts with no Broka password — created at a first sign-in, or linked to a directory — sign in again once an administrator's Reset password gives them one.

Hardening a self-hosted operations console

2026-10-15T00:00:00Z

The order of decisions after install — broker credentials, environment policy, roles, the brokers' own authorisation, TLS at the edge, the key you cannot lose, and the trail you can stand behind.

Production deployment checklist

2026-10-15T00:00:00Z

Four containers, one port, one volume, one irreplaceable key. What to settle before the first `docker compose up -d` in production, and what restart, upgrade and restore look like afterwards.

What a tamper-evident audit trail actually buys you

2026-10-15T00:00:00Z

A sealed trail does not stop anyone changing a record. It makes a change visible to whoever holds a copy the changer could not reach — what BROKA seals, how to check it with a tool that is not BROKA, and where the proof stops.

Broka 1.2.1

2026-10-12T00:00:00Z

Changes

Settings

Security advisories on the Version card — when a security advisory we have published affects the version an installation runs, the release check's answer names it, and Settings ▸ System lists it on the Version card: its title, which opens the advisory on broka.dev, then its identifier, its severity and the version that fixes it. The row is there only while an advisory applies; upgrading past the fix clears it at the next check. The check sends the same fields as before.

Security

The broker service's own libraries name themselves — each module of the broker service now carries its own Maven coordinates. Image scanners took one module for Kestra's io.kestra:core and reported CVE-2026-73247 against the 1.2.0 broker image, and another for a Kora library; Broka contains no Kestra or Kora code. The 1.2.1 images and their SBOMs name the modules as what they are.

Known limitations

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.
The metric history starts empty. Charts, changes, comparisons and bands have nothing to draw or compare with until it fills, and a band waits for three days of its hour.
A connection keeps at most 1,000 series; a resource beyond them has no chart. A Redis stream has a chart only when an alert rule watches it.
The Brokers ▸ Graphs JMX figures are live. A JMX figure is kept in the history only when an alert rule watches it.
If every broker of a Kafka cluster is replaced at once by brokers with other names, Broka finds the new ones when the connection's settings are changed or the broker service is restarted.
The release check needs a route to license.broka.dev; without one, Settings ▸ System cannot tell you that a newer release exists, or that a security advisory affects the version you run.

Upgrade notes

Change the pinned version. Set BROKA_VERSION to 1.2.1 in your .env, take the new compose.yml, pull and start. The API applies one database migration when it starts; it adds a column.
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.2.0 on the same database is not supported. Upgrading a Commercial installation is described in the customer portal.

What changed in BROKA from 1.1 to 1.2

2026-10-12T00:00:00Z

BROKA keeps what it measures now: a metric history in your own database, charts on topics, groups, queues and nodes, alert rules of several conditions that compare a figure with its past, and a new Redis key browser.

Broka 1.2.0

2026-10-11T00:00:00Z

Highlights

Metric history. Broka now keeps what it measures: every figure an alert rule watches and a default set for every connection — a reading a minute for 48 hours, then one an hour for 7, 30, 45 or 90 days, in the installation's own database.
Charts. Topics, consumer groups, queues, streams and nodes have a Metrics tab. An alert rule shows the last six hours of what it would watch, and an incident shows its figure from before it fired to when it closed.
Alert rules with conditions. A rule can hold up to four conditions on the same resource — depth above 1,000 and no consumers — and compare a figure with its own past: a change over a window, the same time yesterday or last week, or its usual range for the hour.
A new Redis key browser. Keys fold into a tree, a search matches by part of a name, a pattern or the exact name, and a value opens in the format it was stored in.

Changes

Monitoring

Metric history — once a minute the alert evaluator keeps the figures it read: every metric an enabled rule watches, then a default set for the connection, at most 1,000 series a connection with a rule's series kept first. The default set: on Kafka the cluster's throughput, under-replicated partitions and size, each topic's produce rate, messages and size, and each consumer group's lag and consume rate; on Redis memory, operations a second, connected clients, hit rate and keys; on RabbitMQ the publish and deliver rates and messages, and each queue's messages, unacknowledged messages and consumers; on Apache Artemis each queue's messages, consumers and messages in delivery, and each address's size; on Memcached each node's memory, hit rate, items and connections. A reading that could not be taken is a gap in the history, never a zero.
How long it is kept — the minute readings for 48 hours, then the hour's mean, minimum and maximum for the retention you choose in Settings ▸ System: 7, 30, 45 or 90 days, 7 unless you change it. Shortening it asks first and removes the history beyond the new window at once.
Metrics tabs — a chart for every figure kept for the resource, over 1 hour, 6 hours, 24 hours, 7 days, or the retention when it is longer: a Kafka topic and consumer group, a RabbitMQ queue, an Apache Artemis queue, a Redis stream that an alert rule watches, and Memcached's nodes. An Apache Artemis address and the Kafka, Redis and RabbitMQ overviews show the same charts in a Metrics section.
A chart follows the page's permissions — the history of a topic, a consumer group or a connector you may not view is not shown to you, and a platform you may not view has no charts for you.

Alerts

Conditions — a rule holds one to four conditions, all of which must hold on the same resource at the same time. Add a condition offers only the metrics that describe the same kind of resource as the first.
A change — how far a figure rose or fell over the last 5 minutes to 24 hours, in percent or in its own unit.
Compared with the past — how far a figure is from the same minute yesterday or the same hour last week, in percent.
Its usual band — whether a figure is above, below or outside the range of the same hour over the last seven days: its mean plus or minus 1 to 10 standard deviations, used once three days of that hour are kept.
Not enough history yet — a condition whose past is not kept yet neither fires nor clears. The rule says why, and an open incident stays open.
Check — the dry run decides an unsaved rule's conditions as the evaluator will, past included, and draws the last six hours of the first five resources it measured, with the threshold when the rule is one plain threshold.
An incident's chart — an incident's detail draws its figure from an hour before it fired to when it closed, or to now while it is open.
What fired, condition by condition — an incident of a rule with conditions, and its notification, name each condition with what it read; the reason it closed follows them.
The rule list — the Condition column reads every condition of a rule.

Kafka

A cluster that is down no longer fills the log — while a registered Kafka cluster answered nothing, the client Broka keeps for it went back to the cluster's bootstrap servers in a loop and logged each attempt, a few lines a second at first and hundreds a second within minutes. It now waits for the cluster at the addresses it knows, logs one warning per reconnect attempt, and carries on within seconds of the cluster's return.
A topic's rates — the bytes and messages in and out set their unit beside the figure, so a row of cards no longer breaks a rate over two lines; a topic of one partition reads 1 partition.

Redis

Keys as a tree — the loaded keys fold into a tree on a separator you choose, kept per connection, with the count under each folder; the table is still there as a view. Load more adds to what is loaded, up to 50,000 keys.
Search — by Contains (the default), Glob or Exact name.
The key beside the list — the open key sits beside the list instead of in a sheet, and the arrow keys move through the keys. The first page of keys is read when the page opens.
Values in their format — Text, JSON, Hex, MessagePack, Gzip, Deflate or Brotli, detected or chosen, edited and saved back in the format they were stored in (Brotli is saved uncompressed); PHP serialize, Java serialization and Pickle are shown and not edited. A value too large or too deeply nested to show is cut rather than left to hang the page.
Inside a collection — a hash, set or sorted set is filtered on the server; a sorted set is read in score order, highest or lowest first; N of M loaded; and Copy as command writes the commands that recreate a key.
Listing keys is an ordinary read — listing keys, the keyspace analysis and the hot-key ranking no longer ask for a confirmation, and neither does listing Memcached's keys.

Security

The console's HTML sanitiser — DOMPurify is updated to 3.4.16.
The images — the broker service carries lz4-java 1.11.4 and no longer ships Ubuntu's unused pebble service manager; the console's image takes libtiff 4.7.2. Each closes a high-severity CVE with a published fix; none was reachable in the way Broka ships — see BROKA-SA-2026-001.

Known limitations

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.
The metric history starts empty. Charts, changes, comparisons and bands have nothing to draw or compare with until it fills, and a band waits for three days of its hour.
A connection keeps at most 1,000 series; a resource beyond them has no chart. A Redis stream has a chart only when an alert rule watches it.
The Brokers ▸ Graphs JMX figures are live. A JMX figure is kept in the history only when an alert rule watches it.
If every broker of a Kafka cluster is replaced at once by brokers with other names, Broka finds the new ones when the connection's settings are changed or the broker service is restarted.
The release check needs a route to license.broka.dev; without one, Settings ▸ System cannot tell you that a newer release exists.

Upgrade notes

Change the pinned version. Set BROKA_VERSION to 1.2.0 in your .env, take the new compose.yml, pull and start. The API applies its database migrations when it starts; they only add tables and columns.
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.1.2 on the same database is not supported.
Plan for the history's space. A connection at its 1,000 series takes about 180 MB with 7 days kept and about 300 MB with 90 days; the 48 hours of minute readings are most of it. Fewer series take less.
Your rules are unchanged. Each existing rule is a rule of one condition and works as before. Upgrading a Commercial installation is described in the customer portal.

When a Kafka cluster is down, its admin client can fill your log

2026-10-11T00:00:00Z

Since Kafka 4.0, a Java admin client that can reach no broker goes back to its bootstrap servers in a loop and logs every attempt — about 90 MB a minute with the client's defaults once it settles, for as long as the cluster is down. What we measured, why it happens, what does not help, and the one setting that stops it.

Alert rules you can trust

2026-10-10T00:00:00Z

Write each alert rule from the metric catalogue, measure it against your live estate before saving, and read its state for what it is — a rule nothing could measure has not passed.

Investigating consumer lag without guesswork

2026-10-10T00:00:00Z

Read offset lag for what it counts, time lag for what it measures, find the stuck member, and preview a reset before applying it.

Queue backlogs: drain, divert, or let it run

2026-10-10T00:00:00Z

A backlog is two numbers, not one — waiting and in flight — and the split decides whether you let it drain, divert it, or purge it. The same read works on RabbitMQ, Kafka and Redis Streams.

Reading Kafka broker health over JMX

2026-10-10T00:00:00Z

The Admin API says what a Kafka cluster holds, not how hard its brokers are working. Set up JMX once and BROKA reads a fixed list of health, request, saturation, disk and JVM figures from every broker and controller, shows them where you already look and lets a rule watch them.

An AI assistant, under the same rules as a person

2026-10-09T00:00:00Z

Giving an assistant broker access usually means handing it a broker credential. BROKA's MCP server has it act as one person instead — that person's permissions, the environment's guards, and the same audit trail.

Giving broker resources an owner

2026-10-09T00:00:00Z

A broker knows its topics, queues and keys, not the service behind each one or the team to call. The application catalogue records that: an owner and a team per service, bindings that say what it does with each resource, and dependencies, health and alerts that follow from them.

Kafka Connect without guesswork

2026-10-09T00:00:00Z

A connector can read RUNNING while one of its tasks has failed. Read the worker, then the connector, then its tasks — and act as narrowly as the problem.

Reading Kafka ACLs by principal

2026-10-09T00:00:00Z

Kafka keeps its permissions as a flat list of bindings. Read them per principal instead — one rule per row, denies first — and change them as a draft that is applied in a safe order, guarded and recorded.

Reading messages without the secrets in them

2026-10-09T00:00:00Z

Developers need to open a topic or a queue to debug it; the messages carry fields they have no reason to see. Masking rules hide those fields on every path that shows contents, fail closed, and leave a recorded permission for the few who need them as they are.

What changed in BROKA from 1.0 to 1.1

2026-10-09T00:00:00Z

Four releases in four days: Kafka's own health over JMX, alerts on Connect and the Schema Registry, an MCP server and data masking in Commercial, a release check, and unused accounts disabled by default.

Broka 1.1.1

2026-10-08T00:00:00Z

Changes

Kafka

Client metrics, chosen rather than typed — the subscription dialog offers the metrics as choices (producer, consumer, every metric) with other prefixes beside them, the push interval as a list with Kafka's five minutes chosen for a new subscription, and the clients to match as rows of a selector and a pattern. What is saved is the same subscription as before.
Client metrics on Kafka 3.7 to 3.9 — a subscription with no match (every client) or no metrics is made there as well; those versions refused an empty match as an illegal client matching pattern.
Clearing the Topics search ends a cluster search — after Enter had searched the whole cluster, emptying the box left that search applied, and the page said the cluster had no topics. The Topics card now reads Matching topics while a cluster search runs.
Reading from a time refuses a value that is not a time — a read asked to start from a timestamp written as text, such as a date, started from the beginning of the topic without a word; it is refused, with the reason.

Redis

Times in the installation's time zone — stream entries, the live tail, Pub/Sub messages, latency events, the slow log and hot-key tracking showed the browser's time zone instead of the one every other screen uses.
Switching cluster ends a Pub/Sub watch — a running watch kept the previous cluster's messages coming under the new cluster's name.

Memcached

Switching cluster ends the live events watch and starts over on the new cluster's first node; the Keys and Memory pages also choose the new cluster's node instead of keeping the old one's.

Alerts

An incident's reading is in its metric's unit — 1.2 GB read as "1.2B", a lag in milliseconds as "3.6M" and a ratio at full precision in the incident list and dialog.

Console

A tab opened before an upgrade reloads itself — it used to fail to open any screen it had not visited yet, with Try again unable to help. The sign-in and setup screens now have an error screen with Reload.
Copy says when it could not copy — on an installation served over plain HTTP the browser offers no clipboard to the page, and every Copy button still said Copied; the one-time password could be dismissed without ever being copied. Copy now uses a fallback, and says so when the browser refuses.
A role without the dashboard lands where it may go — such a role met an empty page after sign-in and after every refused page; it now lands on the first page of the menu it may open. A platform page whose settings could not be read says so, with Try again, instead of staying empty.
Enter on a control inside a table row is the control's — Enter or Space on a button, checkbox or menu in a clickable row opened the row instead.
Downloads cannot come out empty — the RabbitMQ definitions export and the offline activation request are saved the way every other download is.
Templates and Saved Views say when they could not be loaded, with Try again, instead of No templates yet.

Users and the audit trail

A password reset unlocks the account — after too many wrong passwords, an administrator's reset left the lockout in place, and the new temporary password was refused until it ran out.
Sorting the audit log by Actor sorts by name — it sorted by the account's internal id. Sorting by Result groups the results as they are shown.

Licence

The licence messages say what stops — an installation without a valid licence was told reading live data works, while every platform other than Kafka is unavailable until a licence is activated; a licence bound to another installation was said to withhold nothing, while changes on the Commercial platforms are withheld until it is rebound.

Known limitations

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.
The release check needs a route to license.broka.dev; without one, Settings ▸ System cannot tell you that a newer release exists.

Upgrade notes

Change the pinned version. Set BROKA_VERSION to 1.1.1 in your .env, take the new compose.yml, pull and start. This release changes nothing in the database.
Back up first, as for any upgrade: the database, and .env with it — BROKA_KEK decrypts every stored credential. Upgrading a Commercial installation is described in the customer portal.

Broka 1.1.2

2026-10-08T00:00:00Z

Changes

Access Review (Commercial)

By permission no longer freezes the browser — opening the tab, before a permission was picked, locked the page until it was closed. It now opens and waits for a permission, and lists everyone who holds the one you pick.

Known limitations

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.
The release check needs a route to license.broka.dev; without one, Settings ▸ System cannot tell you that a newer release exists.

Upgrade notes

Change the pinned version. Set BROKA_VERSION to 1.1.2 in your .env, take the new compose.yml, pull and start. This release changes nothing in the database.
Back up first, as for any upgrade: the database, and .env with it — BROKA_KEK decrypts every stored credential. Upgrading a Commercial installation is described in the customer portal.

Broka 1.1.0

2026-10-07T00:00:00Z

Highlights

A check for new releases. Settings ▸ System says when a newer release is out. Once at start and once a day, the installation sends its identifier, version and edition — and nothing about your brokers or how you use Broka.
Unused accounts are disabled. An account nobody has used for 90 days is disabled; the window is yours to change or turn off, and the sign-in lockout is configurable too.
Access Review shows resource grants (Commercial): the access a resource-pattern grant gives, account by account and permission by permission.

Changes

Security

Unused accounts — Settings ▸ Security disables an account nobody has used for a window you set: 90 days by default, 30 to 365, or off. Use is a sign-in, a session's activity, an API token's use or a re-enable. The last account that can manage users is never disabled, and every disable is recorded with the reason.
Sign-in lockout — after 3 to 9 failed sign-ins (5 unless you change it), the account is locked for 5 to 1440 minutes (15 unless you change it).

Settings

Version — Settings ▸ System shows Update available with the newer version, Up to date, or Not checked yet, and when the last check was answered.
Registration — an optional e-mail address and company, entered in Settings ▸ System, sent with the release check so that we can write to you about a security issue. Empty unless an administrator fills it in.

Kafka

Produce — a JSON value is edited with syntax highlighting, keeping its validation, Format and status line.

Access Review (Commercial)

Resource grants — an account's effective access lists the resource-pattern grants that give it, with the operations, the cluster and whether the grant came to the account directly or through a team; the holders of a permission include accounts that hold it only through such a grant.

RabbitMQ (Commercial)

Publishing to a queue, on the record — a message published to a queue through the default exchange names that queue in the audit trail; until now the event named only the default exchange. The routing key of a publish through any other exchange is the message's own data and is still not recorded.

Licence agreement and privacy policy

Version 2026-10-07 — both now describe the release check: the licence agreement (§5) names it beside the licence calls as the only bytes an installation sends us, and the privacy policy (§6) lists every field it sends and what we keep — one record per installation with the last address only, deleted after twelve months without a check. A Commercial subscription renewed from now on is renewed on this version.

Known limitations

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.
The release check needs a route to license.broka.dev; without one, Settings ▸ System cannot tell you that a newer release exists.

Upgrade notes

Change the pinned version. Set BROKA_VERSION to 1.1.0 in your .env, take the new compose.yml, 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.1 on the same database is not supported.
Unused accounts are disabled after the upgrade. An account nobody has used for 90 days is disabled within an hour of the first start, and refused at once if it tries to sign in. Open Settings ▸ Security right after the upgrade to change the window or turn it off; re-enable an account from Users. The last account that can manage users is kept.
BROKA_LICENCE_SERVER is no longer read. The licence server's address is built in; remove the line from .env, or leave it — it does nothing.
The release check starts at once. It needs no setting and has none; an installation that cannot reach license.broka.dev simply makes no check. Upgrading a Commercial installation is described in the customer portal.
The licence agreement is version 2026-10-07. Running 1.1.0 accepts it (§1); a Commercial renewal asks for acceptance of this version (§15).

Broka 1.0.1

2026-10-06T00:00:00Z

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.

Broka 1.0.0

2026-10-05T00:00:00Z

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.

Memcached evicts before it looks full

2026-10-03T00:00:00Z

A Memcached node can evict with half its memory apparently free. Memory is committed to slab classes a page at a time and stays with its class until something moves it, so the answer to "why is it evicting" is one node's per-class table, not the totals.

Policies in RabbitMQ: only one applies

2026-10-03T00:00:00Z

RabbitMQ policies do not combine. One user policy governs a queue or exchange — the highest-priority match — the rest contribute nothing, and an operator policy sits on top as a separate layer. Read which one applies from the broker, not from the list.

Reading a Kafka cluster you did not build

2026-10-03T00:00:00Z

The first hour with an inherited Kafka cluster, in the order that answers the most: is it whole, what does it really run, how are its brokers set up and loaded, what do its topics hold, who reads them, and who may do what — all read without changing anything.

Schema Registry without guesswork

2026-10-03T00:00:00Z

Which subject a consumer looks for, which version a record was written with, which rule a new version must pass, and what delete really removes — read from the registry instead of guessed.

Where an Artemis message went: reading from the address down

2026-10-03T00:00:00Z

On Apache Artemis a message is sent to an address, not to a queue. Where it went — routed nowhere, shared, copied, filtered, held for a time, held by a consumer or dead-lettered — is read from the address down, and each answer has its own safe action.

Operating every broker with one permission model

2026-09-30T00:00:00Z

Map teams once, scope roles per environment, and let each broker keep its own native enforcement underneath.

Reading a routing problem from the bindings out

2026-09-30T00:00:00Z

A message that did not arrive was usually discarded at the exchange, not lost from a queue. The diagnosis runs from the routing graph out, and ends with a publish the broker answers — confirmed, returned or refused.

Redis Streams in production: the pending entries list

2026-09-30T00:00:00Z

Delivered is not acknowledged. Read owner, idle time and delivery count, then acknowledge, claim behind the interlock, or go and fix the consumer.