diff --git a/mkdocs.yml b/mkdocs.yml
index 56bfcfd..d5cdcf4 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -41,6 +41,11 @@ nav:
           - Overview: how-to/upgrade/05-config-reference.md
           - Wire Server 5.24: how-to/upgrade/config-references/wire-server-5.24.0.md
           - Wire Server 5.25: how-to/upgrade/config-references/wire-server-5.25.0.md
+          - Wire Server 5.26: how-to/upgrade/config-references/wire-server-5.26.0.md
+          - Wire Server 5.27: how-to/upgrade/config-references/wire-server-5.27.0.md
+          - Wire Server 5.28: how-to/upgrade/config-references/wire-server-5.28.0.md
+          - Wire Server 5.29: how-to/upgrade/config-references/wire-server-5.29.0.md
+          - Wire Server 5.30: how-to/upgrade/config-references/wire-server-5.30.0.md
   - Administration:
       - Overview: how-to/administrate/README.md
       - kubernetes: how-to/administrate/kubernetes/README.md
diff --git a/src/how-to/upgrade/config-references/wire-server-5.24.0.md b/src/how-to/upgrade/config-references/wire-server-5.24.0.md
index 27b2cf2..ada9dde 100644
--- a/src/how-to/upgrade/config-references/wire-server-5.24.0.md
+++ b/src/how-to/upgrade/config-references/wire-server-5.24.0.md
@@ -1,12 +1,24 @@
-# Wire-Server 5.24.0 release
+# Wire-Server `5.24.0` release
 
-The following reference was written based on the following [`build.json` charts](https://raw.githubusercontent.com/wireapp/wire-builds/79660a72c74c8644fb3717bd147368e4c5848117/build.json).
+Reference based on these [`build.json` charts](https://raw.githubusercontent.com/wireapp/wire-builds/79660a72c74c8644fb3717bd147368e4c5848117/build.json), and the [release changelog](https://github.com/wireapp/wire-server/releases/tag/v2025-11-26).
 
-For additional details, you can also read our [release chagelog](https://github.com/wireapp/wire-server/releases/tag/v2025-11-26).
+Artifact:
+[`wire-server-deploy-static-f88a2db81e763f7376fc0f7ecc40166a3bc37ee8.tgz`](https://s3-eu-west-1.amazonaws.com/public.wire.com/artifacts/wire-server-deploy-static-f88a2db81e763f7376fc0f7ecc40166a3bc37ee8.tgz)
+
+## Heads up
+
+`5.24` is one of the heavier upgrades in this series. Two big things going on:
+
+* `databases-ephemeral` is replaced by `redis-ephemeral`. The hostname `gundeck` uses for Redis changes.
+* Conversation data moves from Cassandra to PostgreSQL. **The original docs called this optional. It must be treated as mandatory.** Skipping it here and then upgrading to `5.25` causes conversations to silently disappear from reads, because of a bad chart default at `5.25`. See the post-upgrade migrations section below.
+
+This page assumes the source version is `5.23.x`.
 
 ## Known bugs
 
-There is a bug with our `brig` charts failing to deploy in a non-federated environment. If you are running a non-federated environment, to work around this, set the following configuration in your `brig`:
+### `brig` won't deploy in non-federated environments
+
+The `5.24` `brig` chart has a bug that breaks deployment when federation is off. Workaround, in `values/wire-server/values.yaml`:
 
 ```yaml
 brig:
@@ -14,94 +26,243 @@ brig:
     enableFederation: true
 ```
 
-## Mandatory (breaking) changes
+This is fixed at `5.25`, so once `5.25` is reached the workaround can be taken back out.
+
+## What must change
+
+Listed in the order things should be done.
+
+### 1. Deploy `redis-ephemeral` (replaces `databases-ephemeral`)
+
+The upstream chart for the in-cluster Redis was swapped. The new chart is `redis-ephemeral` and ships Redis `7.4.6` (the old chart was based on Bitnami). It only supports standalone deployments.
+
+Deploy it **before** the `wire-server` upgrade. If `wire-server` is upgraded first with `gundeck.config.redis.host` already pointing at `redis-ephemeral`, gundeck won't be able to connect.
+
+```bash
+d helm upgrade --install redis-ephemeral ./charts/redis-ephemeral \
+  --values ./values/redis-ephemeral/prod-values.example.yaml
+```
+
+Defaults are fine. Nothing should be carried over from `databases-ephemeral`, it's a different chart.
+
+The old `databases-ephemeral` chart isn't auto-removed. Don't uninstall it yet either, wait until everything else is verified. See "Cleanup" at the bottom.
+
+### 2. Edit `brig.config.rabbitmq` in the wire-server values
+
+In `values/wire-server/values.yaml`:
 
-### `brig`
+```yaml
+brig:
+  config:
+    rabbitmq:
+      host: rabbitmq-host-or-service
+```
+
+In `values/wire-server/secrets.yaml`:
 
 ```yaml
 brig:
-  rabbitmq:
-    host: rabbitmq-host-or-service
-    port: 5672 # default
   secrets:
     rabbitmq:
       username: wire-server
-      password: verysecurepassword
+      password: <rabbitmq-password>
 ```
 
-### `background-worker`
+`port` defaults to `5672`, only set it if the RabbitMQ instance listens somewhere else.
+
+Why: for those using our ansible infrastructure package, starting at `5.23`, `rabbitmq` is deployed as an external service instead of in-cluster. `brig` can't rely on the in-cluster default service name anymore, so the hostname has to be set explicitly.
+
+### 3. Add the new `background-worker` config
+
+`background-worker` needs a few new fields. In `values/wire-server/values.yaml`:
 
 ```yaml
 background-worker:
   config:
-    federationDomain: "example.com" # must match federation domain used for the instance in other services (brig etc.)
+    federationDomain: example.com  # match the federation domain used everywhere else (brig, etc.)
     cassandraBrig:
-      host: your-cassandra-host-or-service # same as your current cassandra.host value
+      host: <cassandra-host-or-service>  # same value as the existing cassandra.host
     cassandraGalley:
-      host: your-cassandra-host-or-service # same as your current cassandra.host value
+      host: <cassandra-host-or-service>  # same value as the existing cassandra.host
+    postgresql:
+      host: <postgresql-host-or-service>
+```
+
+In `values/wire-server/secrets.yaml`:
+
+```yaml
+background-worker:
+  secrets:
+    pgPassword: <postgresql-password>
+```
+
+To grab the existing PostgreSQL password from a typical deploy:
+
+```bash
+d kubectl get secret postgresql-external -o jsonpath='{.data.password}' | base64 -d
+```
+
+Why: `background-worker` now runs jobs that need PostgreSQL access and that talk directly to the Cassandra keyspaces of `brig` and `galley`. The federation domain is needed for federation-related background tasks.
+
+> **Warning about the `postgresMigration.conversation` default.** At this release the `background-worker` chart defaults `postgresMigration.conversation` to `postgresql`. That default must **not** be left in place when conversations haven't been migrated yet. If they have not yet been migrated, the data will still be in Cassandra, so a `postgresql` setting points the worker at an empty table. See the migration section below. This is the bug that may have caused conversations to disappear at `5.25` for installs that didn't migrate.
+
+### 4. Update `gundeck.config.redis.host`
+
+For those using the in-cluster Redis service shipped with our bundle, The Redis service hostname has changed from `{{ .Release.Name }}-master` to `{{ .Release.Name }}`. With the standard `redis-ephemeral` release name, the in-cluster service is just `redis-ephemeral` now (used to be `databases-ephemeral-redis-ephemeral-master`).
+
+Check the cluster:
+
+```bash
+d kubectl get svc | grep redis
+```
+
+The output looks something like this (the old `databases-ephemeral-*` services will still be there until the old chart is uninstalled, see "Cleanup"):
+
+```
+databases-ephemeral-redis-ephemeral-headless   ClusterIP   None            <none>   6379/TCP
+databases-ephemeral-redis-ephemeral-master     ClusterIP   10.x.x.x        <none>   6379/TCP
+redis-ephemeral                                ClusterIP   10.x.x.x        <none>   6379/TCP
+redis-ephemeral-headless                       ClusterIP   None            <none>   6379/TCP
+```
+
+The one to use is the plain `redis-ephemeral`. In `values/wire-server/values.yaml`:
+
+```yaml
+gundeck:
+  config:
+    redis:
+      host: redis-ephemeral
 ```
 
-#### Conversation Data Migration
+> **Bug in `wire-server-deploy` `5.24`**: the bundled `values/wire-server/prod-values.example.yaml` ships `gundeck.config.redis.host: databases-ephemeral-redis-ephemeral` (the old service). If that file was used as a starting point, override it to `redis-ephemeral` in the local `values.yaml`.
+
+### 5. Run the wire-server helm upgrade
+
+Once all the values are in place:
+
+```bash
+d helm upgrade --install wire-server ./charts/wire-server --timeout=15m0s \
+  --values ./values/wire-server/values.yaml \
+  --values ./values/wire-server/secrets.yaml
+```
+
+Watch in another terminal:
+
+```bash
+d kubectl get events
+```
+
+## Post-upgrade: migrate conversation data to PostgreSQL
+
+> **Back up before starting.** Take a backup of the Cassandra `galley` keyspace and of the target PostgreSQL database before running any of the steps below. The migration is destructive in the sense that data starts being written to PostgreSQL from step 1 onwards, and rolling back without a backup is not straightforward.
+
+It can only be done **after** the `5.24` `wire-server` helm upgrade has succeeded. Some required services don't exist yet on `5.23`, so trying to migrate before the upgrade just fails.
 
-The following configuration is only mandatory if you decide to migrate conversation data to PostgreSQL at this stage.
+The migration runs in three steps. Each step is a values change followed by a `helm upgrade --install wire-server ...`.
 
-Starting this release, migrating conversation data to PostgreSQL from Cassandra is possible. This is only required for channel search and channel management from Team Settings. Follow [this document](../../../developer/reference/config-options.md#using-postgresql-for-storing-conversation-data) for the steps and configuration required.
+### Step 1: prepare wire-server for migration
 
-If you do so, the following configurations are for `background-worker` are required.
+In `values/wire-server/values.yaml`:
 
 ```yaml
+galley:
+  config:
+    postgresMigration:
+      conversation: migration-to-postgresql
 background-worker:
   config:
-    postgresql:
-      host: your-postgresql-host-or-service
+    migrateConversations: false
+    postgresMigration:
+      conversation: migration-to-postgresql
 ```
 
-And for secrets:
+Then run:
+
+```bash
+d helm upgrade --install wire-server ./charts/wire-server --timeout=15m0s \
+  --values ./values/wire-server/values.yaml \
+  --values ./values/wire-server/secrets.yaml
+```
+
+Once it's set to `migration-to-postgresql`, do not switch back to `cassandra`. New conversations from this point on are written to PostgreSQL, reads still come from Cassandra.
+
+### Step 2: run the actual migration
+
+In `values/wire-server/values.yaml`:
 
 ```yaml
 background-worker:
-  secrets:
-    pgPassword: "your-postgresql-password"
+  config:
+    migrateConversations: true
+    postgresMigration:
+      conversation: migration-to-postgresql
+```
+
+Then run:
+
+```bash
+d helm upgrade --install wire-server ./charts/wire-server --timeout=15m0s \
+  --values ./values/wire-server/values.yaml \
+  --values ./values/wire-server/secrets.yaml
 ```
 
-### `gundeck`
+The `background-worker` pods restart and start moving data. This can take a long time on a database with a lot of conversations.
 
-Upstream Helm chart for `redis-ephemeral` has been replaced. New Redis service hostname has been changed from `{{ .Release.Name }}-master` to `{{ .Release.Name }}`. Verify your Redis service name with:
+Watch the logs (look for `finished migration`):
 
 ```bash
-kubectl get svc | grep redis
+d kubectl logs deployment/background-worker --tail=2000 | grep migrate-conversations
 ```
 
-Then set accordingly:
+Or watch the metrics, both of these should hit `1.0`:
+
+* `wire_local_convs_migration_finished`
+* `wire_user_remote_convs_migration_finished`
+
+### Step 3: switch reads over to PostgreSQL
+
+Once the metrics are at `1.0`, in `values/wire-server/values.yaml`:
 
 ```yaml
-gundeck:
+galley:
   config:
-    redis:
-      host: "your-redis-service"
+    postgresMigration:
+      conversation: postgresql
+background-worker:
+  config:
+    migrateConversations: false
+    postgresMigration:
+      conversation: postgresql
 ```
 
+Then run:
+
+```bash
+d helm upgrade --install wire-server ./charts/wire-server --timeout=15m0s \
+  --values ./values/wire-server/values.yaml \
+  --values ./values/wire-server/secrets.yaml
+```
+
+From this point forward reads and writes both go to PostgreSQL. This configuration must be kept on every subsequent upgrade.
+
 ## Optional changes
 
-### `background-worker`
+### `background-worker` PostGreSQL tunables
 
-New settings, change only if required. The following are defaults as they come in charts
+These are chart defaults, only set them when an actual change is needed:
 
 ```yaml
 background-worker:
   postgresql:
-    host: postgresql # This one is already referenced in the mandatory category
+    host: postgresql # already referenced as mandatory above
     port: "5432"
     user: wire-server
     dbname: wire-server
-  # Background jobs consumer configuration
+  # Background jobs consumer
   backgroundJobs:
-    # Maximum number of in-flight jobs per process
-    concurrency: 8
-    # Per-attempt timeout in seconds
-    jobTimeout: 60s
-    # Total attempts, including the first try
-    maxAttempts: 3
+    concurrency: 8       # max in-flight jobs per process
+    jobTimeout: 60s      # per-attempt timeout
+    maxAttempts: 3       # total attempts including the first try
   postgresqlPool:
     size: 5
     acquisitionTimeout: 10s
@@ -109,17 +270,86 @@ background-worker:
     idlenessTimeout: 10m
 ```
 
-### `gundeck`
+### `gundeck` Redis tunables
 
-New settings, change only if required. The following are defaults as they come in charts
+Also chart defaults, don't touch unless necessary:
 
 ```yaml
 gundeck:
   config:
     redis:
-      host: redis-ephemeral # This one is already referenced in the mandatory catefory
+      host: redis-ephemeral # already referenced as mandatory above
       port: 6379
       connectionMode: "master" # master | cluster
       enableTls: false
       insecureSkipVerifyTls: false
-```    
+```
+
+## Verification
+
+After the helm upgrade is done.
+
+`brig` should connect to RabbitMQ. The log lines look something like this:
+
+```bash
+d kubectl logs deployment/brig --tail=300 | grep -iE 'rabbit|amqp'
+```
+
+```
+{"level":"Info","msgs":["Trying to connect to RabbitMQ"]}
+{"level":"Info","msgs":["Retrieved connection..."]}
+{"level":"Info","msgs":["Opening channel with RabbitMQ"]}
+{"level":"Info","msgs":["RabbitMQ channel opened"]}
+```
+
+`background-worker` does the same and also opens a Cassandra control connection:
+
+```bash
+d kubectl logs deployment/background-worker --tail=300 | grep -iE 'rabbit|cassandra'
+```
+
+`gundeck` pods should all be `Running`:
+
+```bash
+d kubectl get pods | grep gundeck
+```
+
+If the conversation migration is already done, the row count in PostgreSQL should be non-zero. SSH into one of the postgres nodes:
+
+```bash
+ssh <postgres-node> "sudo -u postgres psql -d wire-server -c 'SELECT COUNT(*) FROM conversation;'"
+```
+
+And before calling it done, log in on the webapp and on a mobile client, send a message in an existing conversation, confirm conversations are still there. The whole point of the migration is to keep that data, so it must be verified for real.
+
+## Cleanup
+
+Once `redis-ephemeral` looks healthy, the old `databases-ephemeral` chart can go. Nothing uninstalls it automatically.
+
+First confirm nothing still references it:
+
+```bash
+d helm list -A | grep databases-ephemeral
+d kubectl get svc | grep databases-ephemeral
+grep -r "databases-ephemeral" values/wire-server/values.yaml
+```
+
+The grep on `values/wire-server/values.yaml` should come back empty. If it doesn't, fix the override first, then come back.
+
+Then:
+
+```bash
+d helm uninstall databases-ephemeral
+```
+
+## Disk space note
+
+For those of you using our ansible based deployment package, each upgrade in this series re-runs `setup-offline-sources`, which copies the new release's binaries, container images, and debs into `/opt/assets` on the assethost. After a few versions, the assethost runs out of space and the playbook fails with `no space left on device`.
+
+When that happens, SSH into the **assethost** (not the adminhost) and clear it:
+
+```bash
+sudo rm -rvf /opt/assets
+```
+
+Then re-run `setup-offline-sources` from the adminhost.
diff --git a/src/how-to/upgrade/config-references/wire-server-5.25.0.md b/src/how-to/upgrade/config-references/wire-server-5.25.0.md
index 767ae44..4a7c44b 100644
--- a/src/how-to/upgrade/config-references/wire-server-5.25.0.md
+++ b/src/how-to/upgrade/config-references/wire-server-5.25.0.md
@@ -1,28 +1,86 @@
-# Wire-Server 5.25.0 release
+# Wire-Server `5.25.0` release
 
-The following reference was written based on the following [`build.json` charts](https://raw.githubusercontent.com/wireapp/wire-builds/5a74084feeb1138925dcb671b333da0c76f88f08/build.json).
+Reference based on these [`build.json` charts](https://raw.githubusercontent.com/wireapp/wire-builds/5a74084feeb1138925dcb671b333da0c76f88f08/build.json), and the [release changelog](https://github.com/wireapp/wire-server/releases/tag/v2026-01-13).
 
-For additional details, you can also read our [release changelog](https://github.com/wireapp/wire-server/releases/tag/v2026-01-13).
+Artifact:
+[`wire-server-deploy-static-1ca0f1beecb9022e9c7cde2d3ab02fc7e90695e0.tgz`](https://s3-eu-west-1.amazonaws.com/public.wire.com/artifacts/wire-server-deploy-static-1ca0f1beecb9022e9c7cde2d3ab02fc7e90695e0.tgz)
 
-## Known bugs
+## Heads up
 
-Bug in `brig` for non-federated environments in `wire-server-5.24.0` release has been fixed with this release. You can remove (or set to false!) the following config, if it was used as a workaround in the last release:
+Coming from `5.24.0`. If the deploy is still at `5.24` and the conversation data migration to PostgreSQL described on the `5.24` page hasn't been done yet, do that first. There's a chart-default bug at `5.25` that silently breaks anything that hasn't migrated, so it really matters.
+
+## Notes from the previous release
+
+The `brig` non-federated bug from `5.24` is fixed at `5.25`. If `enableFederation: true` was set in `values/wire-server/values.yaml` as a workaround, it can be removed (so it falls back to the default of `false`).
+
+## What must change
+
+### 1. Set `background-worker.config.postgresMigration.conversation` explicitly
+
+The `5.25` `background-worker` chart ships with `postgresMigration.conversation` defaulting to `postgresql`. That's wrong for any deploy that hasn't migrated conversations to PostgreSQL yet, the data is still in Cassandra and the worker would be reading from an empty postgres table. This is the bug that may have caused conversations to disappear in real upgrades.
+
+It has to be set explicitly. Either of these, depending on the actual state of the deploy:
+
+If conversation data hasn't been migrated to PostgreSQL yet (most installs coming from `5.23`):
 
 ```yaml
-brig:
+background-worker:
   config:
-    enableFederation: false
+    postgresMigration:
+      conversation: cassandra
 ```
 
-## Mandatory (breaking) changes
+If the migration was already done (per the `5.24` page):
 
-No mandatory changes in comparison to the last release.
+```yaml
+background-worker:
+  config:
+    postgresMigration:
+      conversation: postgresql
+```
+
+Set this before running the wire-server helm upgrade. The default is corrected back to `cassandra` at `5.26`.
+
+### 2. Make sure `mlsPrivateKeys` is configured (even if MLS is off)
+
+Webapp builds from after November 2025 need `mlsPrivateKeys` set on the backend, even when MLS is disabled and the deploy is Proteus-only. Without the keys, the endpoint `v13/mls/public-keys` returns `400`, and the webapp throws `MLSService is required to construct ConversationService with MLS capabilities`.
+
+Check `values/wire-server/secrets.yaml` has something like:
+
+```yaml
+galley:
+  secrets:
+    mlsPrivateKeys:
+      removal:
+        ed25519: |
+          -----BEGIN PRIVATE KEY-----
+          ...
+          -----END PRIVATE KEY-----
+```
+
+If it's missing, generate the keys with `bin/offline-secrets.sh`. Environments that were originally deployed from older `wire-server-deploy` versions may not have run that script and won't have the keys.
+
+### 3. If `galley.settings.featureFlags.cells` is overridden, add the new fields
+
+The `cells` feature flag schema gained new required fields at this release: `channels`, `groups`, `one2one`, `users`, `collabora`, `publicLinks`, `storage`, `metadata`. Any local override of `cells` in the `values.yaml` has to add them.
+
+If `cells` isn't overridden and the chart default is in use, no action needed.
+
+### 4. Run the wire-server helm upgrade
+
+Once values and secrets are updated:
+
+```bash
+d helm upgrade --install wire-server ./charts/wire-server --timeout=15m0s \
+  --values ./values/wire-server/values.yaml \
+  --values ./values/wire-server/secrets.yaml
+```
 
 ## Optional changes
 
-### `nginx-ingress-services`
+### `nginx-ingress-services` private key rotation policy
 
-Support for `cert-manager` certificate private key rotation policy has been added in this release. This allows preserving private keys across certificate renewals for client key pinning scenarios in both federator and ingress certificates. The following shown are defaults as they come in charts from referenced `build.json`.
+`cert-manager` certificate private key rotation policy is now configurable, both for the ingress and the federator. Useful when client key pinning is in use and keys need to survive renewals.
 
 ```yaml
 nginx-ingress-services:
@@ -35,20 +93,30 @@ nginx-ingress-services:
       rotationPolicy: Always
 ```
 
-Options are:
+* `Always` (default): regenerate the key on each renewal.
+* `Never`: keep the same key across renewals (for key pinning).
 
-* Always (default) - regenerates key on each renewal
-* Never - preserves key across renewals (for key pinning)
+Edit `values/nginx-ingress-services/values.yaml` during the nginx ingress upgrade step. Only relevant for `cert-manager`-based deploys with a key pinning requirement.
 
-### `background-worker`
+### New migration failure metrics
 
-Configuring page size and parallelism for conversation migration to PostgreSQL is now possible. This can be configured like this:
+Two metrics for tracking migration failures:
 
-```yaml
-background-worker:
-  config:
-    migrateConversationsOptions:
-      pageSize: 10000
-      parallelism: 2
+* `wire_local_convs_migration_failed`
+* `wire_user_remote_convs_migration_failed`
+
+If either of these hits `1`, the migration has failed. The actual error will be in the `background-worker` logs. To retry, restart the `background-worker` pods.
+
+These go alongside the already-existing `wire_local_convs_migration_finished` and `wire_user_remote_convs_migration_finished` ones.
+
+## Disk space note
+
+Each upgrade in this series re-runs `setup-offline-sources`, which copies the new release's binaries, container images, and debs into `/opt/assets` on the assethost. After a few versions, the assethost runs out of space and the playbook fails with `no space left on device`.
+
+When that happens, SSH into the **assethost** (not the adminhost) and clear it:
+
+```bash
+sudo rm -rvf /opt/assets
 ```
-  
\ No newline at end of file
+
+Then re-run `setup-offline-sources` from the adminhost.
diff --git a/src/how-to/upgrade/config-references/wire-server-5.26.0.md b/src/how-to/upgrade/config-references/wire-server-5.26.0.md
index a9d8e13..edda5b1 100644
--- a/src/how-to/upgrade/config-references/wire-server-5.26.0.md
+++ b/src/how-to/upgrade/config-references/wire-server-5.26.0.md
@@ -1,24 +1,105 @@
-# Wire-Server 5.26.0 release
+# Wire-Server `5.26.0` release
 
-The following reference was written based on the following [`build.json` charts](https://raw.githubusercontent.com/wireapp/wire-builds/7023ffdd52f9de2a1eb5ce2e01cefaf16253274b/build.json).
+> **Federated environments: skip this version.**
+>
+> The `5.26` charts have unresolved issues in federated mode. The original release PR was closed without merging. Federated deploys should go straight from `5.25` to `5.27`.
+>
+> Non-federated deploys can apply `5.26` if they want, but there are no breaking changes between `5.25` and `5.27`, so skipping is also fine.
 
-For additional details, you can also read our [release changelog](https://github.com/wireapp/wire-server/releases/tag/v2026-01-26).
+Reference based on these [`build.json` charts](https://raw.githubusercontent.com/wireapp/wire-builds/7023ffdd52f9de2a1eb5ce2e01cefaf16253274b/build.json), and the [release changelog](https://github.com/wireapp/wire-server/releases/tag/v2026-01-26).
 
-## Known bugs
+Artifact:
+[`wire-server-deploy-static-6ccd1d01db71f30efa1164cf0f9fb6c1f6f5bf64.tgz`](https://s3-eu-west-1.amazonaws.com/public.wire.com/artifacts/wire-server-deploy-static-6ccd1d01db71f30efa1164cf0f9fb6c1f6f5bf64.tgz)
 
-Previous release introduced a bug into `background-worker` default settings for `postgresMigration` and have now been correctly set to Cassandra. If you are relying on default values from our charts, but have migrated your conversations to PostgreSQL, update your config accordingly to keep using PostgreSQL. Specifically, this value:
+## Heads up
 
+Coming from `5.25.0`. For deploys at any earlier version, do the `5.25` page first.
+
+## Notes from the previous release
+
+The `background-worker` chart default for `postgresMigration.conversation` is corrected at this release. It defaults to `cassandra` again, matching the `galley` default. Earlier versions of the chart defaulted to `postgresql`, which is exactly the bug that broke conversations on installs that hadn't migrated.
+
+If `postgresMigration.conversation` was already set explicitly in `values/wire-server/values.yaml` (which `5.25` told operators to do), no action.
+
+If the chart default at `5.25` was being relied on, **and** the migration was already done, the value has to be set explicitly to `postgresql` now, otherwise the new `cassandra` default flips the worker back to reading from Cassandra:
+
+```yaml
+background-worker:
+  config:
+    postgresMigration:
+      conversation: postgresql
+```
+
+## What must change
+
+### 1. Make sure the Kubernetes cluster is at `1.27` or newer
+
+Anything below `1.27` is no longer supported. On older clusters, Kubernetes itself has to be upgraded before touching wire-server.
+
+### 2. Re-fill the Elasticsearch index from Cassandra (after the upgrade)
+
+User search now returns user type info (regular, app, legacy bot). The new fields don't show up in search results until the Elasticsearch index is re-filled from Cassandra. Do this after the wire-server upgrade.
+
+For deploys that call `brig-index` directly instead of letting the chart run it, the tool needs PostgreSQL access now, on top of its existing settings. The invocation has to be updated accordingly.
+
+See [Refill ES documents from Cassandra](../../../developer/reference/elastic-search.md) for the actual procedure.
+
+### 3. Run the wire-server helm upgrade
+
+```bash
+d helm upgrade --install wire-server ./charts/wire-server --timeout=15m0s \
+  --values ./values/wire-server/values.yaml \
+  --values ./values/wire-server/secrets.yaml
+```
+
+## Post-upgrade: migrate conversation codes to PostgreSQL (optional)
+
+> **Back up before starting.** Take a backup of the Cassandra `galley` keyspace and of the target PostgreSQL database before running any of the steps below. The migration writes to PostgreSQL from step 1 onwards, and rolling back without a backup is not straightforward.
+
+Same shape as the conversation data migration from `5.24`. Only makes sense when conversation data has already been migrated, otherwise leave it.
+
+Step 1, in `values/wire-server/values.yaml`:
+
+```yaml
+galley:
+  config:
+    postgresMigration:
+      conversationCodes: migration-to-postgresql
+background-worker:
+  config:
+    postgresMigration:
+      conversationCodes: migration-to-postgresql
+    migrateConversationCodes: false
 ```
+
+Run the helm upgrade.
+
+Step 2, set `migrateConversationCodes: true` on `background-worker` and run the helm upgrade again. Wait for the `wire_conv_codes_migration_finished` metric to hit `1.0`.
+
+Step 3, switch reads to PostgreSQL:
+
+```yaml
+galley:
+  config:
+    postgresMigration:
+      conversationCodes: postgresql
 background-worker:
   config:
     postgresMigration:
-      conversation: postgresql | cassandra # default is cassandra, and should be if not migrated to postgresql
+      conversationCodes: postgresql
+    migrateConversationCodes: false
 ```
 
-## Mandatory (breaking) changes
+Run the helm upgrade.
+
+## Disk space note
 
-No mandatory changes.
+Each upgrade in this series re-runs `setup-offline-sources`, which copies the new release's binaries, container images, and debs into `/opt/assets` on the assethost. After a few versions, the assethost runs out of space and the playbook fails with `no space left on device`.
 
-## Optional changes
+When that happens, SSH into the **assethost** (not the adminhost) and clear it:
+
+```bash
+sudo rm -rvf /opt/assets
+```
 
-Conversation codes can now be migrated to PostgreSQL. For details, read our [changelog](https://github.com/wireapp/wire-server/releases/tag/v2026-01-26).
+Then re-run `setup-offline-sources` from the adminhost.
diff --git a/src/how-to/upgrade/config-references/wire-server-5.27.0.md b/src/how-to/upgrade/config-references/wire-server-5.27.0.md
index 8eb335c..638d01d 100644
--- a/src/how-to/upgrade/config-references/wire-server-5.27.0.md
+++ b/src/how-to/upgrade/config-references/wire-server-5.27.0.md
@@ -1,17 +1,74 @@
-# Wire-Server 5.27.0 release
+# Wire-Server `5.27.0` release
 
-The following reference was written based on the following [`build.json` charts](https://raw.githubusercontent.com/wireapp/wire-builds/d8bdda07fd4c32937a5482711b6e322a32d0c784/build.json).
+Reference based on these [`build.json` charts](https://raw.githubusercontent.com/wireapp/wire-builds/d8bdda07fd4c32937a5482711b6e322a32d0c784/build.json), and the [release changelog](https://github.com/wireapp/wire-server/releases/tag/v2026-02-04).
 
-For additional details, you can also read our [release changelog](https://github.com/wireapp/wire-server/releases/tag/v2026-02-04).
+Artifact:
+[`wire-server-deploy-static-4b7ec1724ffa60fd86c5ffa697f7b41347f64267.tgz`](https://s3-eu-west-1.amazonaws.com/public.wire.com/artifacts/wire-server-deploy-static-4b7ec1724ffa60fd86c5ffa697f7b41347f64267.tgz)
 
-## Known bugs
+## Heads up
 
-No known bugs
+Coming from `5.26.0`, or from `5.25.0` for deploys that skipped `5.26` because of the federation issues. Either is fine, there are no breaking changes between `5.25` and `5.27`.
 
-## Mandatory (breaking) changes
+No mandatory changes at this release. No known bugs.
 
-No mandatory changes
+## Things to know
 
-## Optional changes
+`webapp`, `team-settings`, and `account-pages` are now their own standalone helm charts. They used to be subcharts of `wire-server`, they aren't anymore. So:
 
-Team features can now be migrated to PostgreSQL. For details, read our [changelog](https://github.com/wireapp/wire-server/releases/tag/v2026-02-04).
\ No newline at end of file
+* They have their own values directories: `values/webapp/`, `values/team-settings/`, `values/account-pages/`.
+* They get their own `helm upgrade --install` invocations, after the `wire-server` upgrade.
+* For anyone used to looking for their config under `values/wire-server/values.yaml`, it's not there anymore.
+
+## Post-upgrade: migrate team features to PostgreSQL (optional)
+
+> **Back up before starting.** Take a backup of the Cassandra `galley` keyspace and of the target PostgreSQL database before running any of the steps below. The migration writes to PostgreSQL from step 1 onwards, and rolling back without a backup is not straightforward.
+
+Same shape as the conversation data and conversation codes migrations. Only do this when conversation data and conversation codes have already been migrated, otherwise skip it.
+
+Step 1, in `values/wire-server/values.yaml`:
+
+```yaml
+galley:
+  config:
+    postgresMigration:
+      teamFeatures: migration-to-postgresql
+background-worker:
+  config:
+    postgresMigration:
+      teamFeatures: migration-to-postgresql
+    migrateTeamFeatures: false
+```
+
+Run the helm upgrade.
+
+Step 2, set `migrateTeamFeatures: true` on `background-worker` and run the helm upgrade again. Wait for `wire_team_features_migration_finished` to hit `1.0`.
+
+Step 3, switch reads to PostgreSQL:
+
+```yaml
+galley:
+  config:
+    postgresMigration:
+      teamFeatures: postgresql
+background-worker:
+  config:
+    postgresMigration:
+      teamFeatures: postgresql
+    migrateTeamFeatures: false
+```
+
+Run the helm upgrade so `galley` and `background-worker` restart and start reading from PostgreSQL.
+
+Step 4 (optional, only once everything is validated): the Cassandra `team_features_dyn` table can be dropped.
+
+## Disk space note
+
+Each upgrade in this series re-runs `setup-offline-sources`, which copies the new release's binaries, container images, and debs into `/opt/assets` on the assethost. After a few versions, the assethost runs out of space and the playbook fails with `no space left on device`.
+
+When that happens, SSH into the **assethost** (not the adminhost) and clear it:
+
+```bash
+sudo rm -rvf /opt/assets
+```
+
+Then re-run `setup-offline-sources` from the adminhost.
diff --git a/src/how-to/upgrade/config-references/wire-server-5.28.0.md b/src/how-to/upgrade/config-references/wire-server-5.28.0.md
index 8e42a2e..6f59a1d 100644
--- a/src/how-to/upgrade/config-references/wire-server-5.28.0.md
+++ b/src/how-to/upgrade/config-references/wire-server-5.28.0.md
@@ -1,31 +1,59 @@
-# Wire-Server 5.28.0 release
+# Wire-Server `5.28.0` release
 
-The following reference was written based on the following [`build.json` charts](https://raw.githubusercontent.com/wireapp/wire-builds/93632dd82237c122c93e0e37e02e5f2a1ba84746/build.json).
+Reference based on these [`build.json` charts](https://raw.githubusercontent.com/wireapp/wire-builds/93632dd82237c122c93e0e37e02e5f2a1ba84746/build.json), and the [release changelog](https://github.com/wireapp/wire-server/releases/tag/v2026-03-03).
 
-For additional details, you can also read our [release changelog](https://github.com/wireapp/wire-server/releases/tag/v2026-03-03).
+Artifact:
+[`wire-server-deploy-static-e16cdbfe2b3b42607bb8cddebad1c23c5e16e343.tgz`](https://s3-eu-west-1.amazonaws.com/public.wire.com/artifacts/wire-server-deploy-static-e16cdbfe2b3b42607bb8cddebad1c23c5e16e343.tgz)
 
-## Known bugs
+## Heads up
 
-No known bugs
+Coming from `5.27.0`. No known bugs at this release.
 
-## Mandatory (breaking) changes
+## What must change
 
-The following Helm charts were changed:
+### 1. Update image overrides for `demo-smtp`, `fake-aws-ses`, `fake-aws-sns`, `legalhold`
 
-- `demo-smtp`
-- `fake-aws-ses`
-- `fake-aws-sns`
-- `legalhold`
+These charts switched from a single `image` string to split `repository` + `tag` fields. The new format:
 
-Image field overrides are now controlled with split values, `repository` + `tag`, unlike a full `image` string like previously, if you were using overrides in these charts, change to this format:
-
-```
+```yaml
 affected-chart:
   image:
     repository: quay.io/wire/...
     tag: some-tag
 ```
 
-## Optional changes
+Only matters for deploys that actually override images for any of these charts. Deploys using the bundled `prod-values.example.yaml` defaults aren't affected. `legalhold` in particular is optional and isn't even installed in standard `wire-server-deploy` setups, so most installs will never see it.
+
+Edit the values for whichever of these charts is overridden, before running the corresponding helm upgrade.
+
+### 2. Remove and re-create existing apps
+
+Cassandra (in `brig.user`) now tracks user types per-user, but only for **newly created** users. For existing users and bots, the type is inferred. That works fine for users and bots, but it can't reliably distinguish apps from regular users. So any app created before `5.28` will show up as a regular user in API responses and search results.
+
+To get correct app information, the affected apps must be removed from their team and re-created after the upgrade. Only relevant for deploys that created apps before their official support.
+
+### 3. Run the wire-server helm upgrade
+
+```bash
+d helm upgrade --install wire-server ./charts/wire-server --timeout=15m0s \
+  --values ./values/wire-server/values.yaml \
+  --values ./values/wire-server/secrets.yaml
+```
+
+## Recommendations
+
+### Upgrade Cassandra to `4.1.x` when convenient
+
+From this release on, wire-server is only tested against Cassandra `4.1.x`. The codebase still works on `3.11`, `4.0`, and `4.1`, but only `4.1` and newer get testing going forward. A Cassandra upgrade should be planned at some point.
+
+## Disk space note
+
+Each upgrade in this series re-runs `setup-offline-sources`, which copies the new release's binaries, container images, and debs into `/opt/assets` on the assethost. After a few versions, the assethost runs out of space and the playbook fails with `no space left on device`.
+
+When that happens, SSH into the **assethost** (not the adminhost) and clear it:
+
+```bash
+sudo rm -rvf /opt/assets
+```
 
-No optional changes
\ No newline at end of file
+Then re-run `setup-offline-sources` from the adminhost.
diff --git a/src/how-to/upgrade/config-references/wire-server-5.29.0.md b/src/how-to/upgrade/config-references/wire-server-5.29.0.md
index 18d1d95..aebbfa2 100644
--- a/src/how-to/upgrade/config-references/wire-server-5.29.0.md
+++ b/src/how-to/upgrade/config-references/wire-server-5.29.0.md
@@ -1,24 +1,59 @@
-# Wire-Server 5.29.0 release
+# Wire-Server `5.29.0` release
 
-The following reference was written based on the following [`build.json` charts](https://raw.githubusercontent.com/wireapp/wire-builds/eaaec058bd49e392ab8727a02c568782f709c81a/build.json).
+> **This release is broken. Skip it. Upgrade from `5.28` directly to `5.30`.**
+>
+> The `5.29` charts have known issues that prevent reliable deployment. The wire-server release notes themselves recommend skipping this version. The changes documented below are still in effect at `5.30` (some of them tweaked further), and this page exists for reference. Real upgrade instructions are on the `5.30` page.
 
-For additional details, you can also read our [release changelog](https://github.com/wireapp/wire-server/releases/tag/v5.29.0).
+Reference based on these [`build.json` charts](https://raw.githubusercontent.com/wireapp/wire-builds/eaaec058bd49e392ab8727a02c568782f709c81a/build.json), and the [release changelog](https://github.com/wireapp/wire-server/releases/tag/v5.29.0).
 
-## Known bugs
+Artifact:
+[`wire-server-deploy-static-d5295d63b08c43a4983c27e33e5fff75acdb6663.tgz`](https://s3-eu-west-1.amazonaws.com/public.wire.com/artifacts/wire-server-deploy-static-d5295d63b08c43a4983c27e33e5fff75acdb6663.tgz)
 
-No known bugs
+## Heads up
 
-## Mandatory (breaking) changes
+Skip this version. The content below is reference material for what shipped in `5.29`. The changes are mostly carried into `5.30`, see the `5.30` page for the actual upgrade.
 
-Wire-server core services were migrated from subcharts into the umbrella chart templates. As a result, dependency tags for these services are now obsolete. Out of these, `proxy` service might be the only breaking change if it was not used previously and is unconfigured.
+For reference purposes, the prior version is treated as `5.28.0`.
 
-### `proxy`
+## What was supposed to change at this release
 
-If `proxy` was used previously and is already configured, you have no breaking changes.
+### Core services moved into the `wire-server` umbrella chart
 
-Since proxy can no longer be "toggled off" the following configuration with dummy secrets is sufficient for deploy.
+A bunch of services moved from their own subcharts into the umbrella chart templates at `charts/wire-server/templates`:
 
-```
+* `background-worker`
+* `brig`
+* `cannon`
+* `cargohold`
+* `galley`
+* `gundeck`
+* `proxy`
+* `spar`
+
+So the corresponding dependency tags become obsolete and can be removed from `values/wire-server/values.yaml`:
+
+* `tags.brig`
+* `tags.galley`
+* `tags.cannon`
+* `tags.cargohold`
+* `tags.gundeck`
+* `tags.proxy`
+* `tags.spar`
+* `tags.background-worker`
+
+For standard deploys this isn't a breaking change, the bundled environments don't toggle any of these off. It **is** a breaking change for custom deploys that had `tags.<service>: false` for any of the moved services.
+
+When the upgrade actually runs, rendered manifests will show metadata and source-path diffs (chart labels, template source paths). That's expected, and it may trigger a one-time pod rollout because of checksum annotation changes.
+
+> Note: this is partially reverted at `5.30`. At `5.30` `tags.proxy` becomes required again. See the `5.30` page.
+
+### `proxy` can no longer be toggled off
+
+Side effect of the consolidation. `proxy` doesn't have a way to be disabled anymore. Deploys that previously set `tags.proxy: false` now have to provide at least a minimal `proxy` config so the chart renders.
+
+Placeholder secrets are enough. In `values/wire-server/secrets.yaml`:
+
+```yaml
 proxy:
   secrets:
     proxy_config: |-
@@ -31,22 +66,19 @@ proxy:
       }
 ```
 
-## Optional changes
+Deploys that already had `proxy` configured at `5.28` don't need to do anything.
 
-### `wire-server`
+### `metallb` wrapper chart removed
 
-This value in `wire-server` charts is now obsolete and can be removed if used:
+The `metallb` wrapper chart is gone. It had been unmaintained for a while and the upstream Docker images aren't available anymore. Deploys that depended on this need to switch to a different load balancer setup before upgrading.
 
-```
-tags:
-  proxy: false # or true
-```
+## Optional changes
 
-### `proxy`
+### `proxy` full configuration reference
 
-The following is full config options for the `proxy` chart and are shown as defaults as they come set in charts. They are not required to be set in your `values.yaml`. Do not change unless necessary.
+Full set of `proxy` chart options at their defaults. These shouldn't be set in a local `values.yaml` unless there's a reason to override them. The `secrets` block was covered above for deploys that previously had `proxy` off.
 
-```
+```yaml
 proxy:
   replicaCount: 3
   image:
@@ -70,7 +102,7 @@ proxy:
     logFormat: StructuredJSON
     logNetStrings: false
     proxy: {}
-    # Disable one ore more API versions. Please make sure the configuration value is the same in all these charts:
+    # Disable one or more API versions. Make sure the configuration value matches in all charts:
     # brig, cannon, cargohold, galley, gundeck, proxy, spar.
     disabledAPIVersions: [development]
 
@@ -83,4 +115,20 @@ proxy:
     seccompProfile:
       type: RuntimeDefault
   secrets: {}
-```
\ No newline at end of file
+```
+
+### Rate-limit status code is configurable
+
+The status code returned by `nginz` and `cannon` for rate-limit responses can now be configured in helm values. The default remains `420`, so no action is required unless a different code is desired.
+
+## Disk space note
+
+Each upgrade in this series re-runs `setup-offline-sources`, which copies the new release's binaries, container images, and debs into `/opt/assets` on the assethost. After a few versions, the assethost runs out of space and the playbook fails with `no space left on device`.
+
+When that happens, SSH into the **assethost** (not the adminhost) and clear it:
+
+```bash
+sudo rm -rvf /opt/assets
+```
+
+Then re-run `setup-offline-sources` from the adminhost.
diff --git a/src/how-to/upgrade/config-references/wire-server-5.30.0.md b/src/how-to/upgrade/config-references/wire-server-5.30.0.md
new file mode 100644
index 0000000..eb34062
--- /dev/null
+++ b/src/how-to/upgrade/config-references/wire-server-5.30.0.md
@@ -0,0 +1,69 @@
+# Wire-Server `5.30.0` release
+
+For details, see the [release changelog](https://github.com/wireapp/wire-server/releases) on the wire-server repo.
+
+Artifact:
+[`wire-server-deploy-static-1349f499ee83c3c2a940dd017f71aeb184e3090c.tgz`](https://s3-eu-west-1.amazonaws.com/public.wire.com/artifacts/wire-server-deploy-static-1349f499ee83c3c2a940dd017f71aeb184e3090c.tgz)
+
+## Heads up
+
+Coming from `5.29.0`. In practice most deploys will be coming from `5.28` because `5.29` is broken and gets skipped (see the `5.29` page). The changes below cover both paths.
+
+For deploys that skipped `5.29`, the `5.29` changes are still in effect at `5.30`, so the `5.29` page is worth a look too. The most important one to know about: at `5.29` `tags.proxy` was marked obsolete and a bunch of services were moved into the umbrella chart. The `tags.proxy` part has been undone for this release, see below.
+
+No known bugs at this release.
+
+## What must change
+
+### 1. Set `tags.proxy` explicitly
+
+At `5.29` `tags.proxy` was marked obsolete because `proxy` got moved into the umbrella chart. At `5.30` it's required again. So for deploys that removed it as part of the `5.29` upgrade, or that never had it (because they came straight from `5.28`), it has to go back into `values/wire-server/values.yaml` before this upgrade:
+
+```yaml
+tags:
+  proxy: true   # deploy the proxy chart
+```
+
+Or to keep proxy off:
+
+```yaml
+tags:
+  proxy: false  # don't deploy the proxy chart
+```
+
+### 2. Migrate off Restund (if not already done)
+
+The `restund` helm chart and the underlying code stopped being shipped. Deploys still on Restund have to migrate to `coturn` before this upgrade. Coturn keeps being supported.
+
+This is a planning step, not a values edit.
+
+### 3. Run the wire-server helm upgrade
+
+```bash
+d helm upgrade --install wire-server ./charts/wire-server --timeout=15m0s \
+  --values ./values/wire-server/values.yaml \
+  --values ./values/wire-server/secrets.yaml
+```
+
+## Recommended cleanup (not strictly required)
+
+`background-worker` now reuses `galley`'s configmap and secrets for the Cassandra, PostgreSQL, and federation domain settings. So a few `background-worker` overrides in the values files are now duplicated. Removing them is not required, but it's cleaner, and it keeps the two services aligned going forward.
+
+The duplicates to drop:
+
+* `background-worker.config.cassandraGalley`
+* `background-worker.config.postgresql`
+* `background-worker.config.federationDomain`
+* `background-worker.secrets.pgPassword` (this one's in `secrets.yaml`)
+
+## Disk space note
+
+Each upgrade in this series re-runs `setup-offline-sources`, which copies the new release's binaries, container images, and debs into `/opt/assets` on the assethost. After a few versions, the assethost runs out of space and the playbook fails with `no space left on device`.
+
+When that happens, SSH into the **assethost** (not the adminhost) and clear it:
+
+```bash
+sudo rm -rvf /opt/assets
+```
+
+Then re-run `setup-offline-sources` from the adminhost.