docs: fix broken images, cross-links, and layout overflow after docs-experimental migration (#37418)

* docs: restore missing e2e/mobile push-notification images These developer-docs images existed in mattermost-developer-documentation's static assets but were never copied into the monorepo during the docs migration, leaving broken image links in e2e-cheatsheets.md and the mobile push-notification pages. Also fixes e2e-cheatsheets.md's image paths, which used Hugo-style relative paths that don't resolve under Docusaurus. * docs: fix broken outgoing webhooks screenshot path The image reference used an absolute path left over from the old Hugo site (/integrate/faq/images/...), which doesn't resolve under Docusaurus since no matching file exists under site/static. The image already lives co-located in docs/develop/integrate/faq/images/, so point to it with a relative path instead. * docs: delete Azure AKS deployment guide page The page's screenshots never made it into the monorepo during migration and don't exist under any known source (docs, docs-experimental, or mattermost-developer-documentation). Remove the page rather than ship broken images; drop it from the PDF book manifest and repoint its legacy redirect to the general Kubernetes deployment guide accordingly. * docs: fix heading levels on Kubernetes deploy guides deploy-k8s.mdx and deploy-k8s-oke.mdx used H1 (#) for their top-level in-page sections (Installation steps, Common Errors, etc.) instead of H2. Docusaurus' contentTitle extraction grabs the first H1 it finds anywhere in the doc, which stole the page title slot from the actual frontmatter title, so no title rendered at the top of the page. The flat H1/H2 mix also meant TOC entries for install steps rendered as a flat list at the page's TOC root instead of nested under their section, which made the TOC sidebar overflow/misrender on narrower/zoomed viewports. Bump every heading in both files one level (H1->H2->H3->H4) so the page title renders and the TOC nests correctly. * docs: fix TOC/layout horizontal overflow on wide code blocks The Kubernetes prerequisites page's TOC sidebar overflowed off-screen at higher browser zoom levels. Root cause: `.docMainContainer` has `max-width: none !important` (intentional, so OpenAPI's 2-column layout gets full width), but that removes the container's only width ceiling. Combined with the default flexbox `min-width: auto` on both the main container (in its outer flex row with the left sidebar) and the doc content column (in the inner content/TOC row), a sufficiently wide code block's intrinsic min-content size could drag the whole row wider than the viewport instead of scrolling within itself. Add `min-width: 0` at both flex levels so `overflow-x: auto` on code blocks and tables actually contains overflow locally, and make the responsive table-scroll CSS apply unconditionally instead of only under the 996px breakpoint (zoom shrinks effective layout width without re-triggering the media query). Also shorten the illustrative base64 example values in the AWS Aurora Postgres secret example, which were long enough on their own to be a secondary contributor to the same overflow. * docs: restore additional missing images found via full static-resolution scan Docusaurus's build-time image validator doesn't reliably warn on every broken absolute-path reference, so npm run build alone missed these. A direct scan of every image reference in docs/develop and docs/main against the filesystem turned up 38 more genuinely missing images (desktop architecture, VPN/Pritunl setup, docker dev environment, i18n-extract tooling, MVP program, onboarding, schema migration guide, plugin best-practices, and interactive-message screenshots) that were never copied over from mattermost-developer-documentation during migration. Two references (interactive-dialog-date.png and interactive-dialog-datetime.png) remain unresolved because no source image exists anywhere in the legacy repo. * docs: fix broken cross-links after .md to .mdx migration Several Calls admin guide pages and the air-gapped quick-start runbook were renamed from .md to .mdx during migration, but their internal cross-links still pointed at the old .md filenames (and, for setup-tls, the old flattened path), so Docusaurus couldn't resolve them. Found via a full scan of every relative markdown link under docs/main and docs/develop against the filesystem, since the build's own "couldn't be resolved" warnings don't reliably surface every broken link. * docs: remove broken date/datetime element screenshots These screenshots were never captured before migration (broken on the currently live docs.mattermost.com too), and no source image exists anywhere in the legacy repos to restore. Remove the broken references rather than leave a dead image link. * docs: move newly-restored desktop architecture images to static/ These 4 images were restored co-located next to their content files, matching an existing (if inconsistent) convention elsewhere in docs/develop. Since these are new additions rather than pre-existing working references, move them to docs/site/static/ instead of perpetuating the co-located pattern. Repo-wide normalization of the other ~70 existing co-located image references is left for a separate follow-up PR. * docs: remove deleted AKS page from sidebar generator's manual grouping master (#37402) fixed the sidebar generator's SRC path but this branch's deletion of deploy-k8s-aks.mdx still left a dangling reference in the Deployment Guide's manual Kubernetes grouping, which fails Docusaurus's sidebar-doc-id validation at build time. --------- Co-authored-by: Hanzo Dev <[email protected]>
2026-09-30 01:57:35 +00:00 · 2026-07-09 18:13:08 +03:00
parent 0533f3d11d
commit 611f31f6c2
75 changed files with 101 additions and 182 deletions
@@ -13,7 +13,7 @@ These are the internally-managed windows acting as the main user interface point

 #### Main window

-![Main Window screenshot](main-window.png)
+![Main Window screenshot](/img/desktop-architecture/main-window.png)

 This is the primary view that encapsulates the core of the Desktop App interface. Most `BrowserView` objects are rendered using this window as their parent, and are affected by the behavior of this window. Most other controls, including the tray icon and taskbar/dock icon, interact with this window, and most of their functionality is tied to it as well.

@@ -27,7 +27,7 @@ This window is managed by the `MainWindow` module located at [main/windows/mainW

 #### Settings window

-![Settings Window screenshot](settings-window.png)
+![Settings Window screenshot](/img/desktop-architecture/settings-window.png)

 This window is created when the user opens **Preferences** from the **File** menu. It contains an interface where the user can change settings specific to the Desktop App client that do not affect their Mattermost servers. This window is a child window of the Main Window and will close/hide when the Main Window is closed/hidden.

@@ -45,7 +45,7 @@ Most of these views exist as they act as augments to the existing interface and

 #### Loading screen

-![Loading Screen screenshot](loading-screen.png)
+![Loading Screen screenshot](/img/desktop-architecture/loading-screen.png)

 This is a `BrowserView` that renders over top of external Mattermost views that are loading. It is a cosmetic view that avoids the user having a white screen while the application is loading. The view is ephemeral should only be visible while the current external Mattermost view is loading.

@@ -7,7 +7,7 @@ The Desktop App exercises relatively strict control over the user's ability to n
 - **Security:** Since we expose certain Electron (and therefore NodeJS) APIs to the front-end application, we want to be in control of what scripts are run in the front-end. We make a concerted effort to lock down the exposed APIs to only what is necessary; however, to avoid any privacy or security breaches, it's best to avoid allowing the user to navigate to any page that isn't explicitly trusted.
 - **User Experience:** Our application is ONLY designed to work with the Mattermost Web App and thus allowing the user to navigate to other places that are not the Web App is not a supported use case, and could create some undesirable effects.

-![Navigation diagram](navigation-diagram.png)
+![Navigation diagram](/img/desktop-architecture/navigation-diagram.png)

 ### Internal navigation
  
@@ -44,7 +44,7 @@ Note that `cy.findBy*` are shown but other variants are `cy.findAllBy*`, `cy.que
 Please do not use any `Xpath` selectors such as the descendant selector. Do not use the `ul > li` and order selectors either, like `ul > li:nth-child(2)`. If an element can only be queried with this approach, then you may modify the application codebase, improve it, and make it "accessible to everyone".
 _____
 ### Settings Modal
-![settings modal image](../../../../img/e2e/settings-modal.png)
+![settings modal image](/img/e2e/settings-modal.png)

 #### Opening the settings modal
 The function `cy.uiOpenSettingsModal(section)` opens the settings modal when viewing a channel. `section` is of the 
@@ -119,7 +119,7 @@ Use the function `cy.findByRole(role, {name})`. `role` is of the < <a target="_b
    ```
 _____
 ### Channel Menu
-![channel menu image](../../../../img/e2e/channel-menu.png)
+![channel menu image](/img/e2e/channel-menu.png)

 #### Opening the channel menu
 Use the function `cy.uiOpenChannelMenu(item)`. This will open the channel menu by clicking the channel header title or dropdown icon when viewing a channel. `item` is of the type < <a target="_blank" href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Data_structures#String_type">string</a> >. Possible values for `item` are: `'View Info'`, `'Move to...'`,`'Notification Preferences'`, `'Mute Channel'`, `'Add Members'`, `'Manage Members'`,`'Edit Channel Header'`, `'Edit Channel Purpose'`, `'Rename Channel'`, and `'Convert to Private Channel'`, `'Archive Channel'`, and `'Leave Channel'`.
@@ -141,7 +141,7 @@ Use the function `cy.uiCloseChannelMenu()`. This will close the channel menu by
 Use the function `cy.uiGetChannelMenu()`.
 _____
 ### Product Menu
-![product menu image](../../../../img/e2e/product-menu.png)
+![product menu image](/img/e2e/product-menu.png)

 #### Opening the product menu
 Use the function `cy.uiOpenProductMenu(item)`. `item` is of the type < <a target="_blank" href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Data_structures#String_type">string</a> >. Possible values for `item` are: `'Channels'`, `'Boards'`, `'Playbooks'`, `'System Console'`, `'Integrations'`, `'Marketplace'`, `'Download Apps'`, and `'About Mattermost'`.
@@ -408,8 +408,6 @@ The full list of supported fields are included below:

 Date elements provide native date picker functionality for selecting dates without time information. Below is an example of a `date` element for event scheduling.

-![image](interactive-dialog-date.png)
-
 ```json
 {
    "display_name": "Event Date",
@@ -478,8 +476,6 @@ The full list of supported fields for `date` elements is included below:

 DateTime elements provide combined date and time picker functionality with timezone support. Below is an example of a `datetime` element for meeting scheduling.

-![image](interactive-dialog-datetime.png)
-
 ```json
 {
    "display_name": "Meeting Time",
@@ -33,7 +33,7 @@ If you leave the channel field blank, the webhook will respond to trigger words

 7. On the next page, copy the **Token** value. This will be used in a later step.

-    ![Dialog box showing `Setup Successful` message and `Token` in the description message](/integrate/faq/images/outgoing_webhooks_token.png)
+    ![Dialog box showing `Setup Successful` message and `Token` in the description message](../../faq/images/outgoing_webhooks_token.png)

 ## Use an outgoing webhook

@@ -111,7 +111,7 @@ Use this checklist to confirm you have the infrastructure, skills, and access re

 - [ ] You know how to open a [request](https://support.mattermost.com) with Mattermost support if you encounter issues.

-  _Please include the exact **step number** (e.g. 2A.2.1) that failed, along with your [Mattermost support packet](/../../administration-guide/manage/admin/generating-support-packet) and [Calls logs](calls-logging.md)._
+  _Please include the exact **step number** (e.g. 2A.2.1) that failed, along with your [Mattermost support packet](/../../administration-guide/manage/admin/generating-support-packet) and [Calls logs](calls-logging.mdx)._

 <Note>

@@ -302,7 +302,7 @@ Since the Mattermost server is handling all media processing, you can skip this

 **RTCD**

-You will need to provision a new server for RTCD. Use the [performance baselines](calls-metrics-monitoring.md#performance-baselines) for benchmark examples of hardware sizing. The RTCD service supports [horizontal scaling](calls-rtcd-setup.md#horizontal-scaling), but we recommend starting with one server and then scaling out if your expected workload requires it.
+You will need to provision a new server for RTCD. Use the [performance baselines](calls-metrics-monitoring.mdx#performance-baselines) for benchmark examples of hardware sizing. The RTCD service supports [horizontal scaling](calls-rtcd-setup.mdx#horizontal-scaling), but we recommend starting with one server and then scaling out if your expected workload requires it.

 **Recording**

@@ -619,7 +619,7 @@ Now smoke test your Calls deployment with your test accounts:

 #### 2B.2 Install RTCD

-Follow the [RTCD Setup and Configuration](calls-rtcd-setup.md) guide for the actual installation. The guide covers:
+Follow the [RTCD Setup and Configuration](calls-rtcd-setup.mdx) guide for the actual installation. The guide covers:

 - Binary installation
 - `rtcd.toml` configuration
@@ -628,7 +628,7 @@ Follow the [RTCD Setup and Configuration](calls-rtcd-setup.md) guide for the act

 <Note>

-If you are deploying on Kubernetes, also use the [Calls Deployment on Kubernetes](calls-kubernetes.md) guide for cluster-specific installation and Helm-based configuration.
+If you are deploying on Kubernetes, also use the [Calls Deployment on Kubernetes](calls-kubernetes.mdx) guide for cluster-specific installation and Helm-based configuration.

 </Note>

@@ -668,7 +668,7 @@ Calls monitoring uses Prometheus (a tool that collects metrics from your servers
 - **Calls plugin metrics**: `http://YOUR_MATTERMOST_SERVER:8067/plugins/com.mattermost.calls/metrics`
 - **Grafana dashboard**: Import dashboard ID `23225`

-See [Calls Metrics and Monitoring](calls-metrics-monitoring.md) for full configuration details.
+See [Calls Metrics and Monitoring](calls-metrics-monitoring.mdx) for full configuration details.

 #### 2B.5 Verification Checks

@@ -717,7 +717,7 @@ Now we will install and configure the `calls-offloader` job service that handles

 ### 3.2 Install calls-offloader

-Follow the [Calls Offloader Setup and Configuration](calls-offloader-setup.md) guide for installation. The guide covers:
+Follow the [Calls Offloader Setup and Configuration](calls-offloader-setup.mdx) guide for installation. The guide covers:

 - Binary installation
 - `config.toml` configuration
@@ -17,9 +17,9 @@ This diagram shows how the RTCD standalone service can be deployed in a Kubernet

 1. Calls traffic is handled by dedicated RTCD pods
 2. Scaling is managed through Kubernetes deployment configurations
-3. Call recording and transcription is handled by the calls-offloader service (see [Calls Offloader Setup and Configuration](calls-offloader-setup.md))
+3. Call recording and transcription is handled by the calls-offloader service (see [Calls Offloader Setup and Configuration](calls-offloader-setup.mdx))

-If Mattermost isn't already deployed in your Kubernetes cluster and you want to use this deployment type, visit the [Kubernetes operator guide](/install/mattermost-kubernetes-operator.md).
+If Mattermost isn't already deployed in your Kubernetes cluster and you want to use this deployment type, visit the [Kubernetes operator guide](/deployment-guide/server/deploy-kubernetes).

 ## Helm Chart Deployment

@@ -65,7 +65,7 @@ For Kubernetes deployments, you need to ensure specific connectivity paths:

 Resource requirements for RTCD pods depend heavily on the expected call volume, participant count, and whether screen sharing is used. 

-We strongly recommend reviewing the [Performance Baselines](calls-metrics-monitoring.md#performance-baselines) to determine the appropriate CPU, memory, and network requests and limits for your specific deployment needs rather than relying on generic defaults.
+We strongly recommend reviewing the [Performance Baselines](calls-metrics-monitoring.mdx#performance-baselines) to determine the appropriate CPU, memory, and network requests and limits for your specific deployment needs rather than relying on generic defaults.

 ### Scaling Considerations

@@ -86,7 +86,7 @@ The general recommendation is to expose one external IP address per `rtcd` insta

 ## Monitoring and Metrics

-For detailed information on metrics collection and monitoring, see the [Calls Metrics and Monitoring](calls-metrics-monitoring.md) guide.
+For detailed information on metrics collection and monitoring, see the [Calls Metrics and Monitoring](calls-metrics-monitoring.mdx) guide.

 ## Troubleshooting

@@ -97,12 +97,12 @@ For Kubernetes-specific troubleshooting:
 3. Ensure UDP and TCP traffic is properly routed through your load balancer
 4. Verify network policies allow required communication paths

-For detailed logging guidance, see the [Calls Logging](calls-logging.md) guide.
+For detailed logging guidance, see the [Calls Logging](calls-logging.mdx) guide.

 ## Other Calls Documentation

- [Calls Deployment Guide](calls-deployment-guide.md): Overview of deployment options and architecture
- [RTCD Setup and Configuration](calls-rtcd-setup.md): Comprehensive guide for setting up the dedicated RTCD service
- [Calls Offloader Setup and Configuration](calls-offloader-setup.md): Setup guide for call recording and transcription
- [Calls Metrics and Monitoring](calls-metrics-monitoring.md): Guide to monitoring Calls performance using metrics and observability
- [Calls Logging](calls-logging.md): Detailed guidance for collecting Calls logs and client diagnostics
+- [Calls Deployment Guide](calls-deployment-guide.mdx): Overview of deployment options and architecture
+- [RTCD Setup and Configuration](calls-rtcd-setup.mdx): Comprehensive guide for setting up the dedicated RTCD service
+- [Calls Offloader Setup and Configuration](calls-offloader-setup.mdx): Setup guide for call recording and transcription
+- [Calls Metrics and Monitoring](calls-metrics-monitoring.mdx): Guide to monitoring Calls performance using metrics and observability
+- [Calls Logging](calls-logging.mdx): Detailed guidance for collecting Calls logs and client diagnostics
@@ -407,11 +407,11 @@ Each target should show status "UP" in green. If a target shows "DOWN" or errors

 ## Other Calls Documentation

- [Calls Deployment Guide](calls-deployment-guide.md): Overview of deployment options and architecture
- [RTCD Setup and Configuration](calls-rtcd-setup.md): Comprehensive guide for setting up the dedicated RTCD service
- [Calls Offloader Setup and Configuration](calls-offloader-setup.md): Setup guide for call recording and transcription
- [Calls Deployment on Kubernetes](calls-kubernetes.md): Detailed guide for deploying Calls in Kubernetes environments
- [Calls Logging](calls-logging.md): Detailed guidance for collecting Calls logs and client diagnostics
+- [Calls Deployment Guide](calls-deployment-guide.mdx): Overview of deployment options and architecture
+- [RTCD Setup and Configuration](calls-rtcd-setup.mdx): Comprehensive guide for setting up the dedicated RTCD service
+- [Calls Offloader Setup and Configuration](calls-offloader-setup.mdx): Setup guide for call recording and transcription
+- [Calls Deployment on Kubernetes](calls-kubernetes.mdx): Detailed guide for deploying Calls in Kubernetes environments
+- [Calls Logging](calls-logging.mdx): Detailed guidance for collecting Calls logs and client diagnostics

 **Note:**
 Configure Prometheus storage accordingly to balance disk usage with retention needs. If you need to be tight on storage, you can use a short retention period. If you have lots of storage you can keep the retention length longer.
@@ -371,7 +371,7 @@ tail -f /opt/calls-offloader/calls-offloader.log

 ### Performance Monitoring

-Monitor calls-offloader performance and resource usage to ensure optimal operation. See [Calls Metrics and Monitoring](calls-metrics-monitoring.md) for details on setting up metrics and observability.
+Monitor calls-offloader performance and resource usage to ensure optimal operation. See [Calls Metrics and Monitoring](calls-metrics-monitoring.mdx) for details on setting up metrics and observability.

 ## Air-Gapped Installation of `calls-offloader`

@@ -496,9 +496,9 @@ The `--image-registry` flag sets the registry prefix used when the offloader pul

 ## Other Calls Documentation

- [Calls Deployment Guide](calls-deployment-guide.md): Overview of deployment options and architecture
- [RTCD Setup and Configuration](calls-rtcd-setup.md): Comprehensive guide for setting up the dedicated RTCD service
- [Calls Metrics and Monitoring](calls-metrics-monitoring.md): Guide to monitoring Calls performance using metrics and observability
- [Calls Deployment on Kubernetes](calls-kubernetes.md): Detailed guide for deploying Calls in Kubernetes environments
- [Calls Logging](calls-logging.md): Detailed guidance for collecting Calls logs and client diagnostics
+- [Calls Deployment Guide](calls-deployment-guide.mdx): Overview of deployment options and architecture
+- [RTCD Setup and Configuration](calls-rtcd-setup.mdx): Comprehensive guide for setting up the dedicated RTCD service
+- [Calls Metrics and Monitoring](calls-metrics-monitoring.mdx): Guide to monitoring Calls performance using metrics and observability
+- [Calls Deployment on Kubernetes](calls-kubernetes.mdx): Detailed guide for deploying Calls in Kubernetes environments
+- [Calls Logging](calls-logging.mdx): Detailed guidance for collecting Calls logs and client diagnostics
 - [calls-offloader performance documentation](https://github.com/mattermost/calls-offloader/blob/master/docs/performance.md): Detailed performance tuning and monitoring recommendations
@@ -11,7 +11,7 @@ This guide provides detailed instructions for setting up, configuring, and valid
 Before deploying RTCD, ensure you have:

 - A Mattermost Enterprise license
- A server or VM with sufficient CPU and network capacity (see the [Performance baselines](calls-metrics-monitoring.md#performance-baselines) section for sizing guidance)
+- A server or VM with sufficient CPU and network capacity (see the [Performance baselines](calls-metrics-monitoring.mdx#performance-baselines) section for sizing guidance)

 ## Network Requirements

@@ -106,7 +106,7 @@ There are multiple ways to deploy RTCD, depending on your environment. We recomm

 ### Bare Metal or VM Deployment (Recommended)

-This is the recommended deployment method for non-Kubernetes production environments, as it provides the best performance and operational control. For Kubernetes deployments, see the [Calls Deployment on Kubernetes](calls-kubernetes.md) guide.
+This is the recommended deployment method for non-Kubernetes production environments, as it provides the best performance and operational control. For Kubernetes deployments, see the [Calls Deployment on Kubernetes](calls-kubernetes.mdx) guide.

 <Tip>

@@ -238,7 +238,7 @@ For a complete sample configuration file, see the [RTCD config.sample.toml](http

 ### Kubernetes Deployment

-For detailed information on deploying RTCD in Kubernetes environments, including Helm chart configurations, resource requirements, and scaling considerations, see the [Calls Deployment on Kubernetes](calls-kubernetes.md) guide.
+For detailed information on deploying RTCD in Kubernetes environments, including Helm chart configurations, resource requirements, and scaling considerations, see the [Calls Deployment on Kubernetes](calls-kubernetes.mdx) guide.

 ## Configuration

@@ -338,7 +338,7 @@ After deploying RTCD, validate the installation:

 4. **Monitor metrics**:

-   Refer to [Calls Metrics and Monitoring](calls-metrics-monitoring.md) for setting up Calls metrics and monitoring.
+   Refer to [Calls Metrics and Monitoring](calls-metrics-monitoring.mdx) for setting up Calls metrics and monitoring.

 ## Horizontal Scaling

@@ -384,10 +384,10 @@ Once RTCD is properly set up and validated, configure Mattermost to use it:

 ## Other Calls Documentation

- [Calls Deployment Guide](calls-deployment-guide.md): Overview of deployment options and architecture
- [Calls Offloader Setup and Configuration](calls-offloader-setup.md): Setup guide for call recording and transcription
- [Calls Metrics and Monitoring](calls-metrics-monitoring.md): Guide to monitoring Calls performance using metrics and observability
- [Calls Deployment on Kubernetes](calls-kubernetes.md): Detailed guide for deploying Calls in Kubernetes environments
- [Calls Logging](calls-logging.md): Detailed guidance for collecting Calls logs and client diagnostics
+- [Calls Deployment Guide](calls-deployment-guide.mdx): Overview of deployment options and architecture
+- [Calls Offloader Setup and Configuration](calls-offloader-setup.mdx): Setup guide for call recording and transcription
+- [Calls Metrics and Monitoring](calls-metrics-monitoring.mdx): Guide to monitoring Calls performance using metrics and observability
+- [Calls Deployment on Kubernetes](calls-kubernetes.mdx): Detailed guide for deploying Calls in Kubernetes environments
+- [Calls Logging](calls-logging.mdx): Detailed guidance for collecting Calls logs and client diagnostics

 For detailed Mattermost Calls configuration options, see the [Calls Plugin Configuration Settings](plugins-configuration-settings.rst#calls) documentation.
@@ -25,7 +25,7 @@ This runbook brings a Mattermost cluster online inside a network-isolated enclav
 2. **Transfer artifacts across the air gap.** Use the enclave's approved transfer mechanism (one-way diode, manual media, or cross-domain solution). Re-verify checksums on the enclave side before staging in the internal mirror.
 3. **Publish artifacts to the internal package mirror and container registry.** Mirror the Linux package repos (Ubuntu, RHEL, SLES — whichever your hosts use) and push container images (e.g., `mattermost/mattermost-enterprise-edition`, `mattermost/mattermost-mobile-push-proxy`) to the internal registry. Tag images with the same version strings published upstream.
 4. **Provision PostgreSQL.** Provision the database inside the enclave per [Reference Architecture](../reference-architecture/). Set `max_connections`, `shared_buffers`, and `effective_cache_size` per the [scale tier](../reference-architecture/) you're targeting.
-5. **Configure DNS and TLS inside the enclave.** Create an internal DNS A record for the Mattermost host (e.g., `mattermost.enclave.example`). Issue a TLS certificate from your internal CA. Configure NGINX or your reverse proxy with [TLS](../setup-tls.mdx).
+5. **Configure DNS and TLS inside the enclave.** Create an internal DNS A record for the Mattermost host (e.g., `mattermost.enclave.example`). Issue a TLS certificate from your internal CA. Configure NGINX or your reverse proxy with [TLS](../server/setup-tls.mdx).
 6. **Install the Mattermost binary.** Install on Linux ([deploy-linux](../server/deploy-linux.mdx)), Kubernetes via the Mattermost Operator ([deploy-kubernetes](../server/deploy-kubernetes.mdx)), or containers ([deploy-containers](../server/deploy-containers.mdx)). Point image references at your internal registry, not Docker Hub.
 7. **Apply the air-gapped configuration profile.** See [Disable Phone-Home Features](./disable-phone-home-features) for the complete list. At minimum, disable: `EnableDiagnostics`, `EnableSecurityFixAlert`, `EnableMarketplace`, automated license utilization reporting, image proxy, and the in-product version check.
 8. **Activate the license.** Apply the offline license file produced by the Customer Account team — see [Offline License Activation](./offline-license-activation).
@@ -1,97 +0,0 @@
---
-title: "Deploy Mattermost on Azure Kubernetes Service (AKS)"
-sidebar_label: "Deploy on AKS (Azure)"
---
-You can use a supported [Azure Marketplace Container Offer](https://azuremarketplace.microsoft.com/en-us/marketplace/apps/mattermost.mattermost-operator) to install Mattermost on your existing Azure infrastructure.
-
-Before deploying, make sure you have the following:
-
- **An AKS cluster**: with the [Application Gateway Ingress Controller (AGIC) add-on](https://learn.microsoft.com/en-us/azure/application-gateway/tutorial-ingress-controller-add-on-new) enabled or another Ingress controller deployed.
- **PostgreSQL v13.0+ database**: [Azure Database for PostgreSQL - Flexible Server with Private Access](https://learn.microsoft.com/en-us/azure/postgresql/) is recommended. Deploy one by following [this Microsoft quick start guide](https://learn.microsoft.com/en-us/azure/postgresql/flexible-server/quickstart-create-server-portal).
- **Private Network Connectivity**: Verify that there is network connectivity between your AKS cluster and the PostgreSQL database.
- **Valid DNS name and TLS certificate**: You must have access to a DNS zone and provide a valid TLS key and certificate for the Ingress Controller.
- **Node Capacity**: At least 2 AKS nodes for high availability when deploying for 100 users or more.
- **License Key**: Trial or Enterprise license to test high availability and other Enterprise features.
-
-# Installation steps
-
-The installation process includes deploying Mattermost and updating the server.
-
-## Step 1: Deploy Mattermost
-
-1.  Deploy Mattermost from the [Azure Marketplace Container Offer](https://azuremarketplace.microsoft.com/en-us/marketplace/apps/mattermost.mattermost-operator) and select **Get it now**.
-
-> Alternatively, you can go to the `Extensions + Applications` section of your AKS cluster and install the Mattermost offering from there. Visit the [Microsoft cluster extensions documentation](https://learn.microsoft.com/en-gb/azure/aks/cluster-extensions?tabs=azure-cli) to learn more.
-
-2.  Choose the **Resource Group** and the **Region** of your installed AKS and PostgreSQL database.
-
-> ![An example of the Azure AKS Project details screen.](/_static/images/azure/basics.png)
-
-3.  Choose your AKS cluster.
-
-> ![An example of the Azure AKS cluster setup screen.](/_static/images/azure/aks-cluster.png)
-
-4.  Fill in the details for your PostgreSQL database. Ensure the user specified has full access.
-
-> ![An example of the Azure AKS Database setup screen.](/_static/images/azure/postgreSQL.png)
-
-5.  Specify Deployment Details including Deployment Name and Deployment Size. You will need to configure file storage for your Mattermost instance. We recommend using an S3-compatible storage service or an NFS-compatible server.
-
-> ![An example of the Azure AKS Deployment Details setup screen.](/_static/images/azure/deployment-details.png)
-
-6.  Configure Mattermost installation hostname and Ingress details. The AGIC add-on is used in the following example to show the ingress annotations required.
-
-> You can use any pre-installed Ingress Controller in your cluster as long as it supports Kubernetes Ingress and TLS termination.
->
-> ``` yaml
-> kubernetes.io/ingress.class: azure/application-gateway
-> appgw.ingress.kubernetes.io/ssl-redirect: "true"
-> ```
-
-7.  Additionally, we recommend considering:
-
-> 1.  Enforcing a minimum TLS version (e.g., TLS 1.2).
-> 2.  Deploying a Web Application Firewall (WAF) for additional protection, if supported by your ingress controller.
-> 3.  Limiting access using Kubernetes Network Policies.
->
-> ![An example of the Azure AKS Networking Details setup screen.](/_static/images/azure/networking-details.png)
-
-8.  Ensure that everything is running. You should be able to check the installed plugin from the **AKS Extensions + Applications** page under the **Settings** menu.
-
-> When the deployment is complete, obtain the hostname or IP address of your Mattermost deployment using the following command:
->
-> ``` sh
-> kubectl -n mattermost-operator get ingress
-> ```
-
-9.  Use your IP address from the `ADDRESS` column, and create a DNS record in your domain registration service.
-10. Access your working Mattermost installation at the URL you’ve determined in your DNS record.
-
-Learn more about administrating your Mattermost server by visiting the [Administration Guide](/administration-guide/administration-guide-index).
-
-## Step 2: Upgrade Mattermost via your AKS cluster
-
-1.  Visit the `Extensions + Applications` section of your AKS cluster where your Mattermost installation is deployed.
-2.  You can enable minor version auto upgrades since these are not updating Mattermost version
-3.  Expand the `Configuration Settings` table and add the below configuration and the version you want to install as a value.
-
-> ``` 
-> global.azure.mattermost.version
->
-> .. image:: /_static/images/global-azure-mattermost-version.png
-> :alt: An example of using custom Mattermost version.
-> ```
-
-4.  Select **Save** and wait for the upgrade.
-
-# Looking for a sovereign deployment on Azure Local?
-
-For organizations requiring on-premises deployments with data sovereignty, **Azure Local** (formerly Azure Stack HCI) provides a hybrid cloud platform that enables you to run Mattermost on-premises while maintaining integration with Microsoft Teams and M365.
-
-We recommend engaging **Mattermost Professional Services** for Azure Local deployments to ensure optimal configuration and compliance with your security requirements. [Talk to an Expert](https://mattermost.com/contact-sales/) to discuss your Azure Local deployment needs.
-
-<Important>
-
-You are responsible for Azure costs associated with any infrastructure you spin up to host a Mattermost server, and Azure credits cannot be applied towards the purchase of a Mattermost license.
-
-</Important>
@@ -13,27 +13,27 @@ Before deploying, make sure you have the following:
 - **Mattermost License Key** (Trial or Enterprise)
 - **Node Capacity**: At least 2 OKE nodes for high availability when deploying for 100 users or more

-# Installation steps
+## Installation steps

 The installation process includes deploying Mattermost and configuring the necessary components.

-## Step 1: Start from Oracle Cloud Marketplace
+### Step 1: Start from Oracle Cloud Marketplace

 Go to the Mattermost listing and select **Launch Stack**.

 ![Oracle Cloud Marketplace listing for Mattermost](/images/oracle/marketplace-listing.png)

-## Step 2: Stack Information
+### Step 2: Stack Information

 On the **Create stack** page, review the information, and then set the name, compartment, and Terraform version.

 ![Stack information page](/images/oracle/stack-info.png)

-## Step 3: Configure Variables
+### Step 3: Configure Variables

 Set all the details for your Mattermost deployment. Each section is important for a successful and secure installation.

-### OKE Cluster Configuration
+#### OKE Cluster Configuration

 - **Create new OKE Cluster:**
  - Check this if you want to create a new Kubernetes cluster.
@@ -47,7 +47,7 @@ Set all the details for your Mattermost deployment. Each section is important fo
 - **Operating System:**
  - Oracle Linux 8 is recommended for best compatibility.

-### OKE Network Configuration
+#### OKE Network Configuration

 - **Worker Node Visibility:**
  - Private is more secure for production. Public is easier for testing. For production environments, use private nodes and restrict access to the API endpoint.
@@ -58,7 +58,7 @@ Set all the details for your Mattermost deployment. Each section is important fo
 - **VCN CIDR Block:**
  - Set a unique network range (e.g., `10.20.0.0/16`). Avoid overlap with other networks.

-### OKE Worker Nodes
+#### OKE Worker Nodes

 - **Enable Cluster Autoscaler:**
  - Allows the cluster to automatically add or remove nodes based on usage.
@@ -71,7 +71,7 @@ Set all the details for your Mattermost deployment. Each section is important fo
 - **Image OS and Version:**
  - Oracle Linux 8 is recommended.

-### PostgreSQL Configuration
+#### PostgreSQL Configuration

 - **Admin Username:**
  - The main user for your PostgreSQL database (e.g., `admin1`).
@@ -82,7 +82,7 @@ Set all the details for your Mattermost deployment. Each section is important fo
 - **Database Password:**
  - Required if not using a secret.

-### General Configuration
+#### General Configuration

 - **Cluster Name Prefix:**
  - Used to identify all resources (e.g., `mm-oke`).
@@ -101,13 +101,13 @@ Set all the details for your Mattermost deployment. Each section is important fo
 - **Helm Repository:**
  - Default is `https://helm.mattermost.com`.

-## Step 4: Review and Apply
+### Step 4: Review and Apply

 Check all your settings and select **Create** to start the deployment. Monitor the Resource Manager job and logs.

 ![Resource Manager job monitor](/images/oracle/job-monitor.png)

-## Step 5: After Deployment
+### Step 5: After Deployment

 When the job is finished, your OKE cluster, PostgreSQL database, and Mattermost will be ready. To find the Mattermost web address, run:

@@ -117,7 +117,7 @@ kubectl -n mattermost-operator get ingress

 Copy the address and create a DNS record for your domain. Open your browser and go to your Mattermost URL.

-## Step 6: Upgrade Mattermost
+### Step 6: Upgrade Mattermost

 To upgrade your Mattermost installation:

@@ -138,7 +138,7 @@ To upgrade your Mattermost installation:

 </Tip>

-# Common Errors and How to Avoid Them
+## Common Errors and How to Avoid Them

 - **Error: Kubernetes API not reachable**
  - *Cause:* API endpoint is private and you're not connected to the VCN via VPN or Bastion.
@@ -11,15 +11,15 @@ Before you begin, ensure you have the following:
 - A fundamental understanding of Kubernetes concepts, such as deployments, pods, and applying manifests.
 - Sufficient Kubernetes resources allocated based on your expected user load. Consult the [scaling for Enterprise](/administration-guide/scale/scaling-for-enterprise#available-reference-architectures) documentation for resource requirements at different scales.

-# Installation steps
+## Installation steps

 The installation process involves setting up necessary operators and then deploying Mattermost itself.

-## Step 1: Install the NGINX Ingress Controller
+### Step 1: Install the NGINX Ingress Controller

 Follow the instructions in the [Kubernetes deployment documentation](https://kubernetes.github.io/ingress-nginx/deploy/) to install the NGINX ingress controller on your Kubernetes cluster. Mattermost recommends installing the Nginx Operator via helm, regardless of platform you are installing to.

-## Step 2: Install the Mattermost Operator
+### Step 2: Install the Mattermost Operator

 The Mattermost Kubernetes Operator can be installed using Helm.

@@ -55,7 +55,7 @@ The Mattermost Kubernetes Operator can be installed using Helm.
 > helm install mattermost-operator mattermost/mattermost-operator -n mattermost-operator -f config.yaml
 > ```

-## Step 3: Deploy Mattermost
+### Step 3: Deploy Mattermost

 <Note>

@@ -118,21 +118,21 @@ The Mattermost Kubernetes Operator can be installed using Helm.
 > type: Opaque
 > ```
 >
-> Example for AWS Aurora with PostgreSQL:
+> Example for AWS Aurora with PostgreSQL (`DB_CONNECTION_CHECK_URL`, `DB_CONNECTION_STRING`, and `MM_SQLSETTINGS_DATASOURCEREPLICAS` are the base64-encoded form of your Aurora connection URL, e.g. `postgres://user:password@host:5432/mattermost`):
 >
 > ``` yaml
 > apiVersion: v1
 > data:
->   DB_CONNECTION_CHECK_URL: cG9zdGdyZXM6Ly91c2VyOnN1cGVyX3NlY3JldF9wYXNzd29yZEBteS1kYXRhYmFzZS5jbHVzdGVyLWFiY2QudXMtZWFzdC0xLnJkcy5hbWF6b25hd3MuY29tOjU0MzIvbWF0dGVybW9zdD9jb25uZWN0X3RpbWVvdXQ9MTA=
->   DB_CONNECTION_STRING: cG9zdGdyZXM6Ly91c2VyOnN1cGVyX3NlY3JldF9wYXNzd29yZEBteS1kYXRhYmFzZS5jbHVzdGVyLWFiY2QudXMtZWFzdC0xLnJkcy5hbWF6b25hd3MuY29tOjU0MzIvbWF0dGVybW9zdD9jb25uZWN0X3RpbWVvdXQ9MTA=
->   MM_SQLSETTINGS_DATASOURCEREPLICAS: cG9zdGdyZXM6Ly91c2VyOnN1cGVyX3NlY3JldF9wYXNzd29yZEBteS1kYXRhYmFzZS5jbHVzdGVyLXJvLWFiY2QudXMtZWFzdC0xLnJkcy5hbWF6b25hd3MuY29tOjU0MzIvbWF0dGVybW9zdD9jb25uZWN0X3RpbWVvdXQ9MTA=
+>   DB_CONNECTION_CHECK_URL: cG9zdGdyZXM6Ly91c2Vy...  # base64-encoded connection URL
+>   DB_CONNECTION_STRING: cG9zdGdyZXM6Ly91c2Vy...     # base64-encoded connection URL
+>   MM_SQLSETTINGS_DATASOURCEREPLICAS: cG9zdGdyZXM6...  # base64-encoded replica URL
 > kind: Secret
 > metadata:
 >   name: my-postgres-connection
 > type: Opaque
 > ```

-## Step 4: Create the Filestore Secret
+### Step 4: Create the Filestore Secret

 Create a file named `mattermost-filestore-secret.yaml` to store the credentials for your object storage service (e.g., AWS S3 or any S3-compatible service). This secret must be created in the same namespace where you intend to install Mattermost. The file should contain the following YAML structure:

@@ -193,7 +193,7 @@ data:

 </Important>

-## Step 5: Configure the Mattermost Installation Manifest
+### Step 5: Configure the Mattermost Installation Manifest

 1.  Modify the `mattermost-installation.yaml` file (created in step 2) to connect Mattermost to your external database and object storage. Refer to the supported fields for guidance on where to add these configurations within the YAML structure.
 2.  Connect to the database:
@@ -229,7 +229,7 @@ data:
 >     MM_FILESETTINGS_AMAZONS3SSE: true
 > ```

-# Review Mattermost Resource Status
+## Review Mattermost Resource Status

 After a Mattermost installation has been created with the Operator, you can review its status with the following:

@@ -265,8 +265,8 @@ This command can be used to review the Mattermost Operator or Mattermost server

 </Note>

-# Frequently Asked Questions
+## Frequently Asked Questions

-## What is the Operator's version compatibility with Mattermost Server?
+### What is the Operator's version compatibility with Mattermost Server?

 While generally speaking, the Operator should be compatible with most, or all versions of Mattermost Server, we recommend always using the latest version of the Operator in conjunction with a [supported version](/product-overview/release-policy) of Mattermost Server.
@@ -23,7 +23,6 @@
    "/deployment-guide/server/linux/deploy-tar",
    "/deployment-guide/server/deploy-kubernetes",
    "/deployment-guide/server/kubernetes/deploy-k8s",
-    "/deployment-guide/server/kubernetes/deploy-k8s-aks",
    "/deployment-guide/server/kubernetes/deploy-k8s-oke",
    "/deployment-guide/server/deploy-containers",
    "/deployment-guide/server/containers/install-docker",
@@ -287,7 +287,6 @@ const DEPLOYMENT_GROUPS = {
      ]},
      {label: 'Install on Kubernetes', landing: 'server/deploy-kubernetes', items: [
        'server/kubernetes/deploy-k8s',
-        'server/kubernetes/deploy-k8s-aks',
        'server/kubernetes/deploy-k8s-oke',
      ]},
      {label: 'Install with Containers', landing: 'server/deploy-containers', items: [
@@ -1025,7 +1025,7 @@
    },
    {
      "from": "/deploy/server/kubernetes/deploy-k8s-aks",
-      "to": "/deployment-guide/server/kubernetes/deploy-k8s-aks"
+      "to": "/deployment-guide/server/deploy-kubernetes"
    },
    {
      "from": "/deploy/server/kubernetes/deploy-k8s-oke",
@@ -426,6 +426,11 @@ blockquote {
 .docMainContainer_TBSr,
 [class*='docMainContainer'] {
  max-width: none !important;
+  /* Sits in an outer flex row alongside the left sidebar; without
+   * min-width: 0 its default `min-width: auto` lets wide content (long
+   * code block lines, etc.) force it — and the whole row — wider than
+   * the viewport instead of scrolling within its own content. */
+  min-width: 0;
 }
 .docMainContainer_TBSr > .container,
 [class*='docMainContainer'] > .container {
@@ -434,6 +439,18 @@ blockquote {
  padding-right: clamp(1rem, 2vw, 2rem);
 }

+/* Without max-width, the doc content flex column no longer has an upper
+ * bound to shrink against, so a wide code block (long lines, e.g. inline
+ * YAML comments) inflates its own intrinsic min-content size and drags the
+ * whole row — including the TOC column — wider than the viewport, instead
+ * of just scrolling horizontally within the code block itself. `min-width:
+ * 0` restores the standard flexbox shrink behavior so `overflow-x: auto` on
+ * code blocks can do its job. */
+.docMainContainer_TBSr > .container > .row > [class*='col'],
+[class*='docMainContainer'] > .container > .row > [class*='col'] {
+  min-width: 0;
+}
+
 /* TOC right column (per-page) */
 .table-of-contents {
  border-left: 1px solid var(--mm-border-subtle);
@@ -470,16 +487,21 @@ blockquote {
  text-decoration: none;
 }

+/* Tables: scroll horizontally within themselves instead of overflowing the
+ * viewport. Applied unconditionally (not just under the mobile breakpoint
+ * below) since a wide table can force the same horizontal-overflow problem
+ * at any viewport width — e.g. at higher browser zoom levels, where the
+ * effective layout width shrinks but the media query doesn't re-trigger. */
+.markdown table {
+  display: block;
+  width: 100%;
+  overflow-x: auto;
+  -webkit-overflow-scrolling: touch;
+}
+
 /* === Mobile / responsive === */

@media (max-width: 996px) {
-  /* Tables: scroll horizontally instead of overflowing the viewport. */
-  .markdown table {
-    display: block;
-    width: 100%;
-    overflow-x: auto;
-    -webkit-overflow-scrolling: touch;
-  }

  /* Tighter heading scale on small screens. */
  .markdown h1 { font-size: 1.85rem; line-height: 1.15; }