chore (asset): Use //go:embed over vfsgen

[SoloJacobs]

Stacked commit, see #5027

This change removes shurcooL/vfsgen. The change has a couple of benefits:

• Fewer dependencies.
• Simplifies the build process for downstream distributions such as Debian.
• Removes logic around different build targets.

A few additional differences between vfsgen and embed now follow.

1. embed does not compress files, whereas vfsgen compresses the files before adding them to the binary. However, the files are decompressed before sending them. This means that the binary size in this change slightly increases:

❯ du alertmanager-vfsgen
40540   alertmanager-vfsgen
❯ du alertmanager-embed
41756   alertmanager-embed

In the future, we should ensure that we only send compressed files over the network. Moreover, we should compress the files before the build.

2. vfsgen will memory map the files on startup, i.e.,

var Assets = func() http.FileSystem {
    fs := vfsgen۰FS{  // map-like type

embed serves files from read-only section of the binary, see https://github.com/golang/go/blob/9d828e80fa1f3cc52de60428cae446b35b576de8/src/embed/embed.go#L151 For this reason, this change should reduce the overall heap usage and startup time.

3. The build still appears to be reproducible, tested by touching ui/app/script.js. This is a deliberate decision in embed, i.e., embed: modification time not set for embedded files golang/go#44854

4. With this change, we no longer send the Last-Modified: Thu, 01 Jan 1970 00:00:01 GMT HTTP header. Since we have disabled all caching, this seems fair. In the future, we should enable caching.

Closes: #3115

Pull Request Checklist

Please check all the applicable boxes.

• Please list all open issue(s) discussed with maintainers related to this change
  • Fixes #
• Is this a new Receiver integration?
  • I have already tried to use the Webhook Receiver Integration and 3rd party integrations before adding this new Receiver Integration
• Is this a bugfix?
  • I have added tests that can reproduce the bug which pass with this bugfix applied
• Is this a new feature?
  • I have added tests that test the new feature's functionality
• Does this change affect performance?
  • I have provided benchmarks comparison that shows performance is improved or is not degraded
    • You can use benchstat to compare benchmarks
  • I have added new benchmarks if required or requested by maintainers
• Is this a breaking change?
  • My changes do not break the existing cluster messages
  • My changes do not break the existing api
• I have added/updated the required documentation
• I have signed-off my commits
• I will follow best practices for contributing to this project

Which user-facing changes does this PR introduce?

[SoloJacobs]

Below some additional information, which does not need to be reviewed, but might come in handy while reviewing:

I verified the lack of compression like so

❯ curl -s -D - -o /dev/null -H "Accept-Encoding: gzip, deflate, br" http://localhost:9093/script.js
HTTP/1.1 200 OK
Accept-Ranges: bytes
Cache-Control: no-cache, no-store, must-revalidate
Content-Length: 111355
Content-Type: text/javascript; charset=utf-8
Expires: 0
Pragma: no-cache
Date: Sat, 21 Feb 2026 08:57:27 GMT

Moreover, for changes to heap memory, I did following:

❯ cat main_test.go
package main

import (
	"testing"

	"github.com/prometheus/alertmanager/template"
	"github.com/prometheus/alertmanager/ui"
	"github.com/prometheus/common/route"
)

func TestMain(t *testing.T) {
	router := route.New()
	ui.Register(router, nil, nil)
	template.FromGlobs([]string{})
}
❯ go test -memprofile mem.vfsgen.profile main_test.go
ok  	command-line-arguments	0.005s
❯ go tool pprof -text -diff_base mem.embed.profile mem.vfsgen.profile
File: main.test
Build ID: b13f5fb94f4571159937af2558ae82332b043b02
Type: alloc_space
Time: 2026-02-21 08:58:46 CET
Showing nodes accounting for 2228.94kB, 108.59% of 2052.65kB total
      flat  flat%   sum%        cum   cum%
 1714.52kB 83.53% 83.53%  1714.52kB 83.53%  github.com/prometheus/alertmanager/asset.init.func1
  515.38kB 25.11% 108.64%   515.38kB 25.11%  io.ReadAll
    -513kB 24.99% 83.64%     -513kB 24.99%  runtime.allocm
  512.05kB 24.95% 108.59%   512.05kB 24.95%  github.com/prometheus/client_golang/prometheus.(*goCollector).Describe
 -512.02kB 24.94% 83.65%  -512.02kB 24.94%  github.com/prometheus/client_golang/prometheus.(*Registry).Register
  512.01kB 24.94% 108.59%   512.01kB 24.94%  text/template/parse.(*ListNode).append (inline)
         0     0% 108.59%  1027.39kB 50.05%  command-line-arguments.TestMain
         0     0% 108.59%  1714.52kB 83.53%  github.com/prometheus/alertmanager/asset.init
         0     0% 108.59%  1027.39kB 50.05%  github.com/prometheus/alertmanager/template.(*Template).Parse
         0     0% 108.59%  1027.39kB 50.05%  github.com/prometheus/alertmanager/template.FromGlobs
         0     0% 108.59%  -512.02kB 24.94%  github.com/prometheus/client_golang/prometheus.(*Registry).MustRegister
         0     0% 108.59%   512.05kB 24.95%  github.com/prometheus/client_golang/prometheus.(*Registry).Register.func1
         0     0% 108.59%  -512.02kB 24.94%  github.com/prometheus/client_golang/prometheus.MustRegister (inline)
         0     0% 108.59%  -512.02kB 24.94%  github.com/prometheus/client_golang/prometheus.init.0
         0     0% 108.59%  1202.51kB 58.58%  runtime.doInit (inline)
         0     0% 108.59%  1202.51kB 58.58%  runtime.doInit1
         0     0% 108.59%  1202.51kB 58.58%  runtime.main
         0     0% 108.59%     -513kB 24.99%  runtime.mstart
         0     0% 108.59%     -513kB 24.99%  runtime.mstart0
         0     0% 108.59%     -513kB 24.99%  runtime.mstart1
         0     0% 108.59%     -513kB 24.99%  runtime.newm
         0     0% 108.59%     -513kB 24.99%  runtime.resetspinning
         0     0% 108.59%     -513kB 24.99%  runtime.schedule
         0     0% 108.59%     -513kB 24.99%  runtime.startm
         0     0% 108.59%     -513kB 24.99%  runtime.wakep
         0     0% 108.59%  1027.39kB 50.05%  testing.tRunner
         0     0% 108.59%   512.01kB 24.94%  text/template.(*Template).Parse
         0     0% 108.59%   512.01kB 24.94%  text/template/parse.(*Tree).Parse
         0     0% 108.59%   512.01kB 24.94%  text/template/parse.(*Tree).action
         0     0% 108.59%   512.01kB 24.94%  text/template/parse.(*Tree).itemList
         0     0% 108.59%   512.01kB 24.94%  text/template/parse.(*Tree).parse
         0     0% 108.59%   512.01kB 24.94%  text/template/parse.(*Tree).parseControl
         0     0% 108.59%   512.01kB 24.94%  text/template/parse.(*Tree).parseDefinition
         0     0% 108.59%   512.01kB 24.94%  text/template/parse.(*Tree).rangeControl
         0     0% 108.59%   512.01kB 24.94%  text/template/parse.(*Tree).textOrAction
         0     0% 108.59%   512.01kB 24.94%  text/template/parse.Parse

We can see a slight performance (which does not matter in whole scheme of things).

For checking that our builds are reproducible, I used this script.

#!/bin/bash

# 1. Freeze the build environment so Promu doesn't inject a new
# timestamp or username into the binary on the second run.
export SOURCE_DATE_EPOCH=$(date +%s)

echo "Building Alertmanager (First Run)..."
make build

echo "Computing SHA256 of the first binary..."
HASH1=$(sha256sum alertmanager | awk '{print $1}')
echo "Hash 1: $HASH1"

stat ui/app/script.js
echo "Changing modification time of ui/app/script.js..."
touch ui/app/script.js
stat ui/app/script.js

echo "Building Alertmanager (Second Run)..."
make build

echo "Computing SHA256 of the second binary..."
HASH2=$(sha256sum alertmanager | awk '{print $1}')
echo "Hash 2: $HASH2"

echo "-----------------------------------"
if [ "$HASH1" == "$HASH2" ]; then
  echo "SUCCESS: The hashes match. The file modification time does not break reproducibility."
else
  echo "FAILED: The hashes differ. The build is not reproducible."
fi

Thus, the modification times are still not part of the build.

[SoloJacobs]

A sad site note: This change does not remove the checked in build artefacts, it simply replaces assets_vfsdata.go with ui/app/script.js.

At the moment, we are forced to check-in any build artefact, which uses docker. The reason are our github workflows, .github/workflows/ci.yml and .github/workflows/golangci-lint.yml . We use quay.io/prometheus/golang-builder:1.25-base as a base image, which does not provide docker. Moverover, .github/workflows/golangci-lint.yml ignores make lint. Hopefully, we can fix this...

[Spaceman1701]

is it right to remove this Procfile? I always thought this was there as an example for users.

[SoloJacobs]

Good catch, thanks! I did not mean to commit that change.

[SoloJacobs]

Fixed a documentation line too.

[TheMeier]

A sad site note: This change does not remove the checked in build artefacts, it simply replaces assets_vfsdata.go with ui/app/script.js.

At the moment, we are forced to check-in any build artefact, which uses docker. The reason are our github workflows, .github/workflows/ci.yml and .github/workflows/golangci-lint.yml . We use quay.io/prometheus/golang-builder:1.25-base as a base image, which does not provide docker. Moverover, .github/workflows/golangci-lint.yml ignores make lint. Hopefully, we can fix this...

Maybe we can get rid of docker here too with this https://github.com/prometheus/alertmanager/pull/4896/changes#diff-e607ec0aa5cc1bb54b418caa5ae0f5d10116ed19a4d016748dff76b68a11f8d4R22

[Spaceman1701]

LGTM

[jan--f]

Great to see this merged! Apologies for missing the pings on the old PR.

If you're still interested in reducing the binary size:
You can use https://github.com/prometheus/common/blob/main/assets/embed_gzip.go and zip the assets before embedding them like #3115 did. Happy to help with this if there is interest.

[SoloJacobs]

Ah, thank you for the links. I will definitely implement some sort of compression, once I have a bit time.