apache · wu-sheng · Aug 29, 2026
diff --git a/README.md b/README.md
@@ -17,28 +17,105 @@ There are required values that you must set explicitly when deploying SkyWalking
 
 | name | description | example |
 | ---- | ----------- | ------- |
-| `oap.image.tag` | the OAP docker image tag | `10.4.0` |
+| `oap.image.tag` | the OAP docker image tag | `11.0.0` |
 | `oap.storageType` | the storage type of the OAP | `elasticsearch`, `postgresql`, `banyandb`, etc. |
-| `ui.image.tag` | the Horizon UI docker image tag | `horizon-0.6.0` |
+| `ui.image.tag` | the Horizon UI docker image tag | `horizon-1.0.0` |
 
-You can set these required values via command line (e.g. `--set oap.image.tag=10.4.0 --set oap.storageType=elasticsearch`),
+You can set these required values via command line (e.g. `--set oap.image.tag=11.0.0 --set oap.storageType=elasticsearch`),
 or edit them in a separate file(e.g. [`values.yaml`](chart/skywalking/values.yaml), [`values-my-es.yaml`](chart/skywalking/values-my-es.yaml))
 and use `-f <filename>` or `--values=<filename>` to set them.
 
 ## Web UI (Horizon UI)
 
-The web UI shipped by this chart is [Apache SkyWalking Horizon UI](https://github.com/apache/skywalking-horizon-ui),
-which replaces the legacy `skywalking-booster-ui`. Compared to booster-ui:
+The web UI shipped by this chart is [Apache SkyWalking Horizon UI](https://github.com/apache/skywalking-horizon-ui) — the official SkyWalking web console, and the only UI this chart deploys.
 
-- The container bundles a Node-based BFF in front of the SPA. It connects to OAP on **two** ports: the GraphQL query port (`12800`, `oap.ports.rest`) and the admin REST port (`17128`, `oap.ports.admin`, available on OAP 10.5+).
+**Horizon 1.0.0 works with OAP 10.4.0 as well as OAP 11.x**, so there is no reason to stay on the old UI: pin `ui.image.tag=horizon-1.0.0` whichever OAP release you run. Against a 10.x OAP, add `ui.config.templates.mode: readonly` (see below) — everything else works the same.
+
+### Booster UI is not supported
+
+The legacy `skywalking-booster-ui` (and the `skywalking-rocketbot-ui` before it) is **no longer supported by this chart or by SkyWalking**. This is not a chart policy — OAP 11.0.0 removed the UI from the distribution entirely:
+
+- `apm-webapp/` — the Armeria reverse proxy that powered the `skywalking/ui` Docker image — and the `skywalking-ui` git submodule tracking `apache/skywalking-booster-ui` were both deleted, along with the `docker.ui` Maven target and the image build.
+- Consequently the last booster UI image published to `apache/skywalking-ui` is `10.4.0`. There is no `11.x` tag and there will not be one; the repository now carries only `horizon-x.y.z` tags.
+- The OAP-side surfaces booster depended on are gone too: the on-disk `ui-initialized-templates` seed files, the sidebar menu storage, the `UIConfigurationManagement` GraphQL mutations and queries, and the `SW_ENABLE_UPDATE_UI_TEMPLATE` flag. Horizon ships its own dashboard library and menu, and manages templates over the admin REST port.
+
+If you are upgrading from a chart release that deployed booster UI, replace `ui.image.tag=<oap-version>` with `ui.image.tag=horizon-1.0.0` and read the auth section below — Horizon requires configured users and has no `admin/admin` fallback.
+
+Compared to booster-ui:
+
+- The container bundles a Node-based BFF in front of the SPA. It connects to OAP on **two** ports: the GraphQL query port (`12800`, `oap.ports.rest`) and the admin REST port (`17128`, `oap.ports.admin`). OAP 11 enables every admin module by default and serves `/status/*` and `/debugging/*` **only** on the admin port, so `oap.ports.admin` is required.
 - The container exposes **port 8081** (was 8080) and **does not pass-through `/graphql`** to OAP. Callers that previously talked to the UI's GraphQL endpoint (e.g. `swctl --base-url=http://<ui>/graphql`) must now talk to the OAP service directly (`http://<oap>:12800/graphql`).
-- The BFF requires **authentication**. There is no built-in `admin/admin` fallback — `ui.config.auth.local.users` ships **empty**, and the BFF refuses to start until you provide at least one user.
-- The full `horizon.yaml` schema (server, oap, auth, rbac, session, audit, debugLog) is owned upstream:
-  - Canonical commented example: [horizon.example.yaml](https://github.com/apache/skywalking-horizon-ui/blob/main/horizon.example.yaml) (also shipped inside the image at `/app/horizon.example.yaml`)
-  - Per-section reference: [docs/setup/horizon-yaml.md](https://github.com/apache/skywalking-horizon-ui/blob/main/docs/setup/horizon-yaml.md)
+- The BFF requires **authentication**. There is no built-in `admin/admin` fallback, and no login is configured by default. The BFF does **not** fail closed: it boots, logs an error, serves the login page, and answers the readiness probe with 200 — so the pod goes **Ready and nobody can log in**. Configure users before you rely on the deployment.
+- The full `horizon.yaml` schema (server, templates, oap, auth, rbac, session, audit, ai, mcp, oauth, debugLog) is owned upstream: [docs/setup/horizon-yaml.md](https://github.com/apache/skywalking-horizon-ui/blob/main/docs/setup/horizon-yaml.md).
+
+### Configuring the UI: env vars, not a config file
+
+The image's `/app/horizon.yaml` is fully env-tokenized — every field is a `${HORIZON_*:default}` placeholder — so the container is configured by environment variable. **Prefer `ui.extraEnv` and `ui.envFromSecret` for everything.**
+
+The chart mounts a ConfigMap over that file, but writes only the values it has to compute:
 
-  Anything you set under `ui.config:` in your Helm values is rendered verbatim into `horizon.yaml`, so the upstream docs apply 1:1.
-- Release images are published to Docker Hub as `apache/skywalking-ui:horizon-x.y.z`. Pre-release / dev images live at `ghcr.io/apache/skywalking-horizon-ui` (tags: SHA, `vX.Y.Z`, `main`).
+| field | source |
+|---|---|
+| `oap.queryUrl` | the in-cluster OAP service and `oap.ports.rest` |
+| `oap.adminUrl` | the in-cluster OAP service and `oap.ports.admin` |
+| `oap.zipkinUrl` | the in-cluster OAP service and `oap.ports.zipkin-query`, only when that port is set |
+| `server.publicUrl` | the first `ui.ingress.hosts` entry, only when an ingress is enabled |
+| `server.port` | `ui.service.internalPort`, so the BFF binds the port the container exposes |
+
+Each is written as a token — `queryUrl: ${HORIZON_OAP_QUERY_URL:http://<release>-oap:12800}` — so the in-cluster value is the default and the env var still overrides it.
+
+**Why this matters:** Horizon expands `${...}` over the raw *text* of the config file before parsing it. A field written as a plain literal therefore makes its `HORIZON_*` env var silently inert, and a field the file omits falls back to a built-in default that consults env for only a handful of cases. So a config file full of literals doesn't just duplicate defaults — it disables most of the image's configuration surface. That is why `ui.config` is empty by default and why you should reach for env vars first.
+
+`ui.config` is still there when you want to pin a field regardless of env, and `${VAR}` tokens you write in it *do* expand — which is how the Secret pattern below works.
+- Release images are published to Docker Hub as `apache/skywalking-ui:horizon-x.y.z`. Pre-release / dev images live at `ghcr.io/apache/skywalking-horizon-ui` (tags: full commit SHA, `x.y.z`, `main`).
+
+### Horizon UI and OAP versions
+
+Horizon releases **independently** of OAP — there is no 1:1 mapping, and you pin the two image tags separately.
+
+Against **OAP 10.4.0** — the last 10.x release — set two values:
+
+```yaml
+oap:
+  ports:
+    admin: null          # 10.x has no admin server
+ui:
+  config:
+    templates:
+      mode: readonly     # 10.x does not serve /ui-management
+```
+
+The admin host arrived in OAP 11. On a 10.x release port 17128 is the AI-pipeline URI-recognition server, so leaving `oap.ports.admin` at its default would put that port on the OAP Service and point Horizon's `adminUrl` at the wrong thing. With it set to `null` the chart omits `adminUrl` entirely, and Horizon — which probes for capabilities rather than checking a version number — simply hides Inspect, DSL Management, Live Debugger, the Alarm Rule editor and Cluster Status → Admin.
+
+`templates.mode: readonly` is needed for the same reason: Horizon reads dashboard templates from OAP 11's `/ui-management/templates*` REST API, and in the default `live` mode an unreachable template store blocks every layer-driven page rather than silently rendering a bundle that may not match. `readonly` renders the templates bundled in the image and makes the configuration surface display-only. Dashboards, traces, logs, topology, alarms and profiling all work.
+
+### Paths, not values: tokens and source maps
+
+Two Horizon 1.0.0 settings take a filesystem path, so they need a volume — use `ui.extraVolumes` / `ui.extraVolumeMounts`:
+
+- `auth.tokensFile` — API tokens for callers with no browser (scripts, CI, MCP clients). Mount a Secret.
+- `sourceMaps.bootMountDir` — durable `.map` files for the Browser Errors tab. The image sets this to `/app/sourcemaps`; without a volume, runtime uploads are in-memory only and are lost on pod restart.
+
+```yaml
+ui:
+  extraVolumes:
+    - name: horizon-tokens
+      secret:
+        secretName: horizon-tokens
+  extraVolumeMounts:
+    - name: horizon-tokens
+      mountPath: /app/tokens
+      readOnly: true
+  config:
+    auth:
+      tokensFile: /app/tokens/tokens.json
+```
+
+### Behind an ingress
+
+When `ui.ingress.enabled` is true and `ui.ingress.hosts` is non-empty, the chart derives `server.publicUrl` from the first ingress host (`https` when `ui.ingress.tls` is set, `http` otherwise). Horizon uses it to build SSO callbacks and as its OAuth issuer; blank it derives the URL per-request, which is wrong behind a proxy that rewrites `Host`. Set `ui.config.server.publicUrl` to override.
+
+Set `ui.config.server.trustProxy` to a hop count (`1` = one proxy in front) or the ingress address/CIDR if you want the login audit to record the real client address rather than the ingress. `true` is refused at boot — it would let any caller choose the address recorded.
 
 ### Quick demo install (publicly-known credentials)
 
@@ -121,7 +198,7 @@ Full `horizon.yaml` reference: https://github.com/apache/skywalking-horizon-ui/b
 Let's set some variables for convenient use later.
 
 ```shell
-export SKYWALKING_RELEASE_VERSION=4.9.0  # change the release version according to your need
+export SKYWALKING_RELEASE_VERSION=5.0.0  # change the release version according to your need
 export SKYWALKING_RELEASE_NAME=skywalking  # change the release name according to your scenario
 export SKYWALKING_RELEASE_NAMESPACE=default  # change the namespace to where you want to install SkyWalking
 ```
@@ -133,9 +210,9 @@ helm install "${SKYWALKING_RELEASE_NAME}" \
   oci://registry-1.docker.io/apache/skywalking-helm \
   --version "${SKYWALKING_RELEASE_VERSION}" \
   -n "${SKYWALKING_RELEASE_NAMESPACE}" \
-  --set oap.image.tag=10.4.0 \
+  --set oap.image.tag=11.0.0 \
   --set oap.storageType=elasticsearch \
-  --set ui.image.tag=horizon-0.6.0
+  --set ui.image.tag=horizon-1.0.0
 ```
 
 To use BanyanDB as storage solution, you can try
@@ -145,14 +222,21 @@ helm install "${SKYWALKING_RELEASE_NAME}" \
   oci://registry-1.docker.io/apache/skywalking-helm \
   --version "${SKYWALKING_RELEASE_VERSION}" \
   -n "${SKYWALKING_RELEASE_NAMESPACE}" \
-  --set oap.image.tag=10.4.0 \
+  --set oap.image.tag=11.0.0 \
   --set oap.storageType=banyandb \
-  --set ui.image.tag=horizon-0.6.0 \
+  --set ui.image.tag=horizon-1.0.0 \
   --set elasticsearch.enabled=false \
   --set banyandb.enabled=true \
-  --set banyandb.image.tag=0.10.1
+  --set banyandb.image.tag=0.11.0
 ```
 
+> **OAP and BanyanDB versions are locked together.** OAP ships the BanyanDB
+> server API versions it accepts in `SW_STORAGE_BANYANDB_COMPATIBLE_SERVER_API_VERSIONS`;
+> OAP 11.0.0 accepts API `0.11`, which maps to BanyanDB release `0.11.x`. Pairing
+> OAP 11 with BanyanDB 0.10.x makes OAP refuse to start with
+> `Incompatible BanyanDB server API version`. The mapping is published at
+> [BanyanDB API versions](https://skywalking.apache.org/docs/skywalking-banyandb/latest/installation/versions/).
+
 BanyanDB can be configured through various parameters. A comprehensive list of these parameters can be found in the configuration section of [BanyanDB Helm](https://github.com/apache/skywalking-banyandb-helm?tab=readme-ov-file#configuration) repository. These parameters allow you to customize aspects such as replication, resource allocation, persistence, and more to suit your specific deployment needs. Remember to prepend 'banyandb.' to all parameter names when applying the settings. For example, `banyandb.image.tag` can be used to specify the version of BanyanDB.
 
 
@@ -220,13 +304,13 @@ specify those configurations, they may take no effect.
 
 here are some examples.
 
-- Deploy SkyWalking 10.4.0
+- Deploy SkyWalking 11.0.0
 
 ```shell script
 helm install "${SKYWALKING_RELEASE_NAME}" ${REPO}/skywalking -n "${SKYWALKING_RELEASE_NAMESPACE}" \
-  --set oap.image.tag=10.4.0 \
+  --set oap.image.tag=11.0.0 \
   --set oap.storageType=elasticsearch \
-  --set ui.image.tag=horizon-0.6.0 \
+  --set ui.image.tag=horizon-1.0.0 \
   --set eck-operator.installCRDs=false
 ```
 
@@ -268,9 +352,9 @@ helm -n istio-system install skywalking \
   oci://ghcr.io/apache/skywalking-helm/skywalking-helm \
   --version "0.0.0-b670c41d94a82ddefcf466d54bab5c492d88d772" \
   -n "${SKYWALKING_RELEASE_NAMESPACE}" \
-  --set oap.image.tag=10.4.0 \
+  --set oap.image.tag=11.0.0 \
   --set oap.storageType=elasticsearch \
-  --set ui.image.tag=horizon-0.6.0
+  --set ui.image.tag=horizon-1.0.0
 ```
 
 ## Install development version using source codes

diff --git a/chart/skywalking/Chart.yaml b/chart/skywalking/Chart.yaml
@@ -16,7 +16,7 @@
 apiVersion: v2
 name: skywalking-helm
 home: https://skywalking.apache.org
-version: 4.9.0
+version: 5.0.0
 description: Helm Chart for Apache SkyWalking
 icon: https://raw.githubusercontent.com/apache/skywalking-kubernetes/master/logo/sw-logo-for-chart.jpg
 sources: