Upgrading to Web UI 1.1

Before upgrading to Karafka Web UI 1.1, review our General Karafka Upgrade Guide first.

This release does not change the consumer reporting schema. The one change that may need action affects only Pro users who use a custom messages policy to restrict what users can do.

Publishing Messages Is Allowed By Default

The Explorer gains a Publish message capability in Pro: you can produce a new message to a topic directly from the Web UI. It is a separate action from republishing an existing message.

The capability is gated by a new #publish? method on the messages policy of the policies engine. The default messages policy returns true, so publishing is enabled after the upgrade. A custom messages policy that inherits from the default one also inherits this true, so it allows publishing too, even if it blocks other actions such as #republish?.

If you restrict what your users can do and do not want them to produce messages from the Web UI, override #publish? in your policy before you deploy:

class MyCustomMessagesPolicy < Karafka::Web::Pro::Ui::Lib::Policies::Messages
  # @param _topic [String] name of the topic to which we want to publish a message
  # @return [Boolean] true if we should allow publishing
  def publish?(_topic)
    false
  end
end

Unlike the other messages policy methods, #publish? receives a topic name as a String rather than a ::Karafka::Messages::Message, because the message it guards does not exist yet. You can use it to allow publishing selectively:

def publish?(topic)
  # Allow producing test messages, but never to the production order stream
  topic.start_with?('sandbox_')
end

Returning false hides the Publish message action in the Explorer and rejects a crafted request to the publishing endpoint, so the control holds even if a user knows the URL.

Aggregated Health Views

The Pro Health views are aggregated per topic instead of per partition, so they stay readable on clusters with many partitions. Each topic is one summary row (lag, maximum and average lag, a skew flag, LSO risk and paused partitions) that drills down into the per-partition views you had before.

The thresholds that drive the flags and row highlighting are configurable under config.ui.health.lags:

Setting	Default	Meaning
skew_threshold	3	How many times bigger than the average a single partition's lag has to be for a topic to be flagged as skewed
skew_minimum	100	Biggest-partition lag below which a topic is never flagged as skewed, so small imbalances stay quiet
high_threshold	10_000	Lag at which a row is highlighted as a high-lag (error) row
warning_ratio	0.5	Fraction of high_threshold at which a row is highlighted as a warning instead of an error

The defaults mean a lag of 5_000 or more is a warning and 10_000 or more is an error:

Karafka::Web.setup do |config|
  config.ui.health.lags.high_threshold = 50_000
  config.ui.health.lags.skew_threshold = 5
end

Deployment

This release does not change the consumer reporting schema, so the zero-downtime dance that schema bumps require does not apply here:

1. If you use a custom messages policy and do not want users to produce messages from the Web UI, override #publish? as described above.
2. Test the upgrade on a staging or dev environment.
3. Perform a rolling deployment (or a regular one) and replace all consumer processes.
4. Update the Web UI Puma.
5. No CLI command execution is required.
6. No migration is required.
7. Enjoy.

---

Last modified: 2026-09-23 10:57:18