# Upgrading to Web UI 1.1

Before upgrading to Karafka Web UI `1.1`, review our [General Karafka Upgrade Guide](https://karafka.io/docs/Upgrades-Upgrading.md) 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.

## Upgrading to Web UI 1.1 / 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](https://karafka.io/docs/Pro-Web-UI-Policies.md). 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:

```ruby
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:

```ruby
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.

## Upgrading to Web UI 1.1 / 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`:

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

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

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

## Upgrading to Web UI 1.1 / 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.
1. Test the upgrade on a staging or dev environment.
1. Perform a rolling deployment (or a regular one) and replace all consumer processes.
1. Update the Web UI Puma.
1. **No** CLI command execution is required.
1. **No** migration is required.
1. Enjoy.


---

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