Add feature to build and enable UI V2 by sysadmind · Pull Request #4974 · prometheus/alertmanager

sysadmind · 2026-02-08T03:50:55Z

Adds the Makefile and UI embedding components to serve the new UI based on Mantine. This can be enabled when built with the tag builtinassets. This is a close match to what Prometheus does to build and embed the UI.

The UI is still very early, so the utility is very limited, but this will allow testing the features more easily as they become available.

Adds the Makefile and UI embedding components to serve the new UI based on Mantine. This can be enabled when built with the tag `builtinassets`. This is a close match to what Prometheus does to build and embed the UI. The UI is still very early, so the utility is very limited, but this will allow testing the features more easily as they become available. Signed-off-by: Joe Adams <github@joeadams.io>

Signed-off-by: Joe Adams <github@joeadams.io>

siavashs · 2026-02-10T13:31:01Z

CI is failing even after a re-run.
It is not clear why the build is failing for elm, it does not seem that there are any changes to that:

cd /__w/alertmanager/alertmanager/ui/app && make script.js
make[1]: Entering directory '/__w/alertmanager/alertmanager/ui/app'
>> building elm-env docker image
/bin/sh: 3: docker: not found
make[1]: *** [Makefile:17: elm-env] Error 127
make[1]: Leaving directory '/__w/alertmanager/alertmanager/ui/app'
make: *** [Makefile:67: ui/app/script.js] Error 2

sysadmind · 2026-02-10T14:00:18Z

The problem is that this is now happening in the build process where it was not before and it's already inside docker so it doesn't have access to run docker. I think the logical option is to remove the elm build from the regular build process. The other option would be to enable the docker in docker build.

Signed-off-by: Joe Adams <github@joeadams.io>

featurecontrol/featurecontrol.go

siavashs · 2026-02-11T10:21:58Z

scripts/compress_assets.sh

@@ -0,0 +1,46 @@
+#!/usr/bin/env bash


We removed this file in #4617 do we need to add it back now again?

It's used in prometheus for the bundling of static assets into a go file. I think we should keep it.

I don't think we should add compress_assets.sh.

It is very complex, having to both generate .go files and running extra shell scripts as part of the build. It would be better to just directly use Vite for building the gzip files in a dist folder. This would allow us to easily add brotli compression later.

Everytime the ui is opened, alertmanager will decompress the files before sending them over the network. This can be seen from the curl output:

curl -s -D - -H "Accept-Encoding: gzip" http://localhost:9093/assets/index-D3YozeYE.js -o /dev/null HTTP/1.1 200 OK Accept-Ranges: bytes Content-Length: 530907 Content-Type: application/javascript Date: Sat, 07 Mar 2026 19:22:22 GMT

So, we are missing out on the main benefit of compression: Reducing the number of TCP round trips.

The benefits of compression are negligible:

❯ du -hs assets/index-D3YozeYE.js.gz assets/index-pOPVlMO9.css.gz index.html.gz 164K assets/index-D3YozeYE.js.gz 32K assets/index-pOPVlMO9.css.gz 4.0K index.html.gz ❯ du -hs assets/index-D3YozeYE.js assets/index-pOPVlMO9.css index.html 520K assets/index-D3YozeYE.js 216K assets/index-pOPVlMO9.css 4.0K index.html

Thus, your change will reduce the binary size by 500K .

TLDR; We should keep it simple and not do any compression. If we want to do compression, we should do it properly, and support streaming the files compressed over the network.

The binary file saving are small right now because of tree shaking. There is very little in the UI if you compile it from this PR. As more features and functionality get added, this will grow. I don't have hard data around what that will be, but if there's consensus around embedding the uncompressed files, I'll pull this out.

siavashs · 2026-02-11T10:23:35Z

ui/web.go

+	if enableUIV2 {
+		RegisterUIV2(r, logger)
+	} else {
+		RegisterUIV1(r, logger)
+	}


Should we use Elm and React for naming these to be more clear?

I'm certainly open to renaming them. I don't know that I love the word "react" though because in some future, there may be a UI v3 that is also based on react.

ui/web.go

ui/ui.go

siavashs · 2026-02-11T10:54:30Z

Makefile


 .PHONY: build
-build: common-build
+build: assets-compress common-build


Currently the project ships pre-compiled assets bundle so UI does not have to be built each time.

I think we should re-evaluate that for the mantine based UI. The build output has unique filenames per build. This will cause a lot of churn in git.

siavashs · 2026-02-11T10:56:23Z

ui/web.go

+
+	reactAssetsRoot := "/static/mantine-ui"
+
+	serveReactApp := func(w http.ResponseWriter, _ *http.Request) {


Missing cache-control headers?

What outcome would you like to see with those?

Just noticed they are missing and wondered if we need them.

Personally, if we think they will provide value, I would want to see this happen towards the end of the project. That way we can test what benefits and what tradeoffs they cause.

The caching headers are need such that users can seamlessly update their alertmanager binaries: If the browser caches the index.html, we will have situation that a browser will run an old index.html against a new alertmanager server. This will definitely cause failures, as far as I can see, because alertmanager will return 404s for these files:

<script type="module" crossorigin src="/assets/index-D3YozeYE.js"></script> <link rel="stylesheet" crossorigin href="/assets/index-pOPVlMO9.css">

We should add the cache-control headers now, since this cannot be fixed retroactively.

The other caches should be fine, since the index files contain the hashes.

Signed-off-by: Joe Adams <github@joeadams.io>

siavashs

LGTM at this stage since it is not the default UI.
Let's wait for other maintainers to also take a look.

SoloJacobs

Hey,

I finally had a bit of time to look over these changes. Thanks for gathering all this information, I tried it out locally and it works. I do have some feedback, though: You stuck very close to Prometheus, but that implementation has drawbacks.

But have a look at the comments. I can also help with concrete implementations in this change.

Kind regards

SoloJacobs · 2026-03-07T19:24:13Z

scripts/compress_assets.sh

@@ -0,0 +1,46 @@
+#!/usr/bin/env bash


I don't think we should add compress_assets.sh.

It is very complex, having to both generate .go files and running extra shell scripts as part of the build. It would be better to just directly use Vite for building the gzip files in a dist folder. This would allow us to easily add brotli compression later.

Everytime the ui is opened, alertmanager will decompress the files before sending them over the network. This can be seen from the curl output:

curl -s -D - -H "Accept-Encoding: gzip" http://localhost:9093/assets/index-D3YozeYE.js -o /dev/null HTTP/1.1 200 OK Accept-Ranges: bytes Content-Length: 530907 Content-Type: application/javascript Date: Sat, 07 Mar 2026 19:22:22 GMT

So, we are missing out on the main benefit of compression: Reducing the number of TCP round trips.

The benefits of compression are negligible:

❯ du -hs assets/index-D3YozeYE.js.gz assets/index-pOPVlMO9.css.gz index.html.gz 164K assets/index-D3YozeYE.js.gz 32K assets/index-pOPVlMO9.css.gz 4.0K index.html.gz ❯ du -hs assets/index-D3YozeYE.js assets/index-pOPVlMO9.css index.html 520K assets/index-D3YozeYE.js 216K assets/index-pOPVlMO9.css 4.0K index.html

Thus, your change will reduce the binary size by 500K .

TLDR; We should keep it simple and not do any compression. If we want to do compression, we should do it properly, and support streaming the files compressed over the network.

SoloJacobs · 2026-03-07T19:26:21Z

ui/ui.go

+	"path/filepath"
+	"strings"
+
+	"github.com/shurcooL/httpfs/filter"


We should not be using shurcool. The files can be easily be routed to the correct location with a few lines of go.

SoloJacobs · 2026-03-07T19:32:48Z

ui/web.go

+
+	reactAssetsRoot := "/static/mantine-ui"
+
+	serveReactApp := func(w http.ResponseWriter, _ *http.Request) {


The caching headers are need such that users can seamlessly update their alertmanager binaries: If the browser caches the index.html, we will have situation that a browser will run an old index.html against a new alertmanager server. This will definitely cause failures, as far as I can see, because alertmanager will return 404s for these files:

<script type="module" crossorigin src="/assets/index-D3YozeYE.js"></script> <link rel="stylesheet" crossorigin href="/assets/index-pOPVlMO9.css">

We should add the cache-control headers now, since this cannot be fixed retroactively.

The other caches should be fine, since the index files contain the hashes.

SoloJacobs · 2026-03-07T19:36:33Z

ui/web.go

+			return
+		}
+		defer func() { _ = f.Close() }()
+		idx, err := io.ReadAll(f)


Nit: Why not use io.Copy

SoloJacobs · 2026-03-07T19:37:05Z

ui/web.go

+	// Static files required by the React app.
+	router.Get(reactStaticAssetsDir+"/*filepath", func(w http.ResponseWriter, r *http.Request) {
+		r.URL.Path = path.Join(reactAssetsRoot+reactStaticAssetsDir, route.Param(r.Context(), "filepath"))
+		fs := server.StaticFileServer(Assets)


I don't think we should create a StaticFileServer on every request.

SoloJacobs · 2026-03-07T19:40:03Z

featurecontrol/featurecontrol.go

 	return f.enableAutoGOMAXPROCS
 }

+func (f *Flags) EnableUIV2() bool {


I don't think UI is ready to be shipped with next release, so I would rather not include it in the release. Would it be possible for us to provide a separate build target instead?

SoloJacobs · 2026-03-07T19:56:55Z

ui/mantine-ui/src/components/ThemeSelector.tsx

@@ -0,0 +1,31 @@
+import { FC } from 'react';


Does this possibly belong in a different PR?

Yes I will pull it out.

SoloJacobs · 2026-03-07T20:01:23Z

ui/web.go

+		router.Get(p, serveReactApp)
+	}
+
+	reactStaticAssetsDir := "/assets"


nit: inline

SoloJacobs · 2026-03-07T20:03:17Z

ui/web.go

+	// Serve the React app.
+	reactRouterPaths := newUIReactRouterPaths
+
+	for _, p := range reactRouterPaths {


I'm wondering about this: Aren't we building a SPA? Typically, you would serve everything, not just a fixed set of subpaths, i.e., localhost:9093/alerts/special-name should also serve the react app?

For now, serving 404 is fine I suppose, but we will definitely have to touch this part, once we build deep links. I am wondering whether it is better just have a general /ui path.

I think that /ui is a fair option if there is general agreement on that direction.

Just a comment from the sidelines, since I don't have the capacity to get more deeply involved at the moment:

Since this routing code was taken from the Prometheus server: any UI URL parametrization in the Prometheus server happens only via HTTP parameters (since we encode a lot of different parameters in there on some of the pages, and then we just standardized on that single mechanism), so we only need to explicitly list a couple of fixed paths there. I wonder if for Alertmanager you really want to split this up and store some (prominent) parameters in the path and others (like detailed filters) in HTTP params, or whether it's nicer to just dump them all into HTTP params like in Prometheus and have one unified way of handling them all?

Aside from that: as a user I personally aesthetically prefer UI paths without a /ui/... prefix. Maybe the path routing can also be restructured to serve the UI for a set of patterns, or for everything that is not /api/..., /-/healthy, or one of the other special endpoints.

SoloJacobs · 2026-03-18T07:34:21Z

Hey, just because I saw you might be active here: I did make some progress on what I think the UI should look like.
https://github.com/SoloJacobs/alertmanager/tree/example-ui

This change is not ready, yet: I put the first three commit into review, but the final commit contains the interesting changes:

Zero-Overhead compression: We directly stream the compressed files from the binary, and don't decompress them unless the client requests it.
Optimization to the caching, using Vites file hashing.
Disallow go get github.com/prometheus/alertmanager/ui.

The basic idea is that we have to move to vite sooner or later, so we might as well do it now and find out how it affects users.

sysadmind · 2026-03-24T02:18:55Z

I think based on the feedback, I want to take a different approach. I have opened a PR for the small UI change - #5106 . After the changes from @SoloJacobs above from the example-ui branch, I can rework this build in that spirit, in some smaller increments so that we can align on direction more easily.

sysadmind added 5 commits February 7, 2026 22:45

Update make build for assets

c92d7b1

Signed-off-by: Joe Adams <github@joeadams.io>

Update Makefile

e261fab

Signed-off-by: Joe Adams <github@joeadams.io>

Take 3

b158b66

Signed-off-by: Joe Adams <github@joeadams.io>

Fix lint

63c7487

Signed-off-by: Joe Adams <github@joeadams.io>

Pull frontend v1 build out of make assets

bf54ae4

Signed-off-by: Joe Adams <github@joeadams.io>

sysadmind requested review from SuperQ, TheMeier, juliusv, siavashs and ultrotter February 11, 2026 02:03

sysadmind added 2 commits February 10, 2026 22:38

Add theme toggle and fix header styles

607a983

Signed-off-by: Joe Adams <github@joeadams.io>

Lint fix

6686470

Signed-off-by: Joe Adams <github@joeadams.io>

siavashs reviewed Feb 11, 2026

View reviewed changes

Review feedback

7a63a78

Signed-off-by: Joe Adams <github@joeadams.io>

siavashs approved these changes Feb 19, 2026

View reviewed changes

SoloJacobs added the component/ui label Feb 20, 2026

SoloJacobs removed the request for review from TheMeier February 20, 2026 15:50

SoloJacobs requested changes Mar 8, 2026

View reviewed changes

SoloJacobs requested a review from TheMeier March 8, 2026 09:21

sysadmind closed this Mar 24, 2026


		reactAssetsRoot := "/static/mantine-ui"

		serveReactApp := func(w http.ResponseWriter, _ *http.Request) {

Conversation

sysadmind commented Feb 8, 2026

Uh oh!

siavashs commented Feb 10, 2026

Uh oh!

sysadmind commented Feb 10, 2026

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

siavashs left a comment

Choose a reason for hiding this comment

Uh oh!

SoloJacobs left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

SoloJacobs commented Mar 18, 2026

Uh oh!

sysadmind commented Mar 24, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants