## Why is this backport needed (background and context) **Top-level group Duo settings** have not been available for self-hosted DAP since **18.8**, and this was fixed in **18.11** and in the latest patch releases. These settings are necessary for configuring flows, which these users have not been able to do since 18.8. This backport is needed so the upgrade notice is visible in the affected versioned docs, not only in the latest docs. ### Which documentation versions are changing: * **18.8** * **18.9** * **18.10** ### How the documentation will change Adding a note to [Control GitLab Duo Agent Platform availability](https://docs.gitlab.com/user/duo_agent_platform/turn_on_off/) in **18.8**, **18.9**, and **18.10** recommending that customers upgrade to **18.8.9**, **18.9.5**, **18.10.3**, or **18.11**, because those versions contain fixes for the known critical bugs affecting self-hosted DAP. (Exact wording TBD with PM and EM) ``` > [!note] > For GitLab Duo Agent Platform self-hosted users, due to a known issue, configuration settings > are only available in GitLab 18.11 and later. If you do not see the **GitLab Duo features** > section under **Settings** > **General**, upgrade your instance to 18.11 or later. ``` Supporting issues / MRs * [Release post](https://about.gitlab.com/releases/2026/04/08/patch-release-gitlab-18-10-3-released/) * [RFH: DAP Self Hosted SKU Trial: Cannot configure Duo settings at top group level/Foundational Flows blocked](https://gitlab.com/gitlab-com/request-for-help/-/work_items/4433) * [Main fix MR](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/228595) * [18.10 backport MR](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/228974) * [18.9 backport MR](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/228970) * [18.8 backport MR](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/228968) - Merge request to backport: * [18.10 docs backport MR](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/231082) * [18.9 docs backport MR](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/231083) * [18.8 docs backport MR](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/231084) ## Get the approval of TW Leadership > The person requesting the backport does this step. If the backport is for a version older than the latest stable branch, ask Technical Writing Leadership for approval: - [ ] Mention TW Leadership in a comment in this issue and wait for their approval: ```md @gitlab-org/tw-leadership could I get your approval for this documentation backport? ``` ## Create the merge request to backport the change > The person requesting the backport does this step. Requires at least the Developer role on the project that needs the backport. To backport a change, you will merge your changes into the stable branch of the version where you want the change to occur. 1. [x] Open a merge request with the backport. The MR should target the stable release branch, for example: `16-11-stable-ee` or `17-0-stable-ee`. Link the MR to this issue. 2. [x] If the backport targets the current stable branch, assign to a Technical Writer for review and merge. Usually, the Technical Writer of the [relevant group](https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments). 3. [x] If the backport targets any branch other than the latest stable branch, assign the MR to a Technical Writer for review. After the TW approves, ask a [release manager](https://about.gitlab.com/community/release-managers/) to review and merge the change. Mention this issue to them and give them all the context they need. For the change to appear in docs.gitlab.com, merging to the stable branch is all you need. For the change to appear under `/help`, the change needs to be part of a GitLab release. The next time a release manager creates a release, they will include the change in the release. ## Deploy the backport change > A member of the Technical Writing team does this step. Usually, the same Technical Writer who created the merge request. After the change is backported to a stable branch, the Docker image that holds that version's docs needs to be updated: - GitLab 17.9 and later: \[ \] Run a [new pipeline](https://gitlab.com/gitlab-org/technical-writing/docs-gitlab-com/-/pipelines/new) in `docs-gitlab-com`. Choose the branch name that matches the stable version, for example `15.11` or `16.0`. - GitLab 17.8 and earlier: \[ \] Run a [new pipeline](https://gitlab.com/gitlab-org/gitlab-docs/-/pipelines/new) in `gitlab-docs`. Choose the branch name that matches the stable version, for example `15.11` or `16.0`. If the backport change was also made to a version other than the last three stable branches, you need to update the docs archives site: 1. [ ] Make sure the Docker images from the previous instructions are built. 2. [ ] Run a [new pipeline](https://gitlab.com/gitlab-org/gitlab-docs-archives/-/pipelines/new) in `gitlab-docs-archives`. Choose the branch name that matches the stable version, for example `15.11` or `16.0`. 3. [ ] After the pipeline finishes, go to https://archives.docs.gitlab.com and verify that the changes are available for the respective version.